Re: which PC

rfischer@xxxxxxxxx (Ray Fischer) wrote:
Floyd L. Davidson <floyd@xxxxxxxxxx> wrote:
Ron Hunter <rphunter@xxxxxxxxxxx> wrote:

Modern drives are fast enough to mask
this action until the drive becomes full enough that it
can no longer perform adequately. A freshly
defragmented disk will operate faster, and more
efficiently than one in which the data is spread all
over the disk, period.

That is not true, period. On a modern disk (i.e., one
that has sufficient buffering and which reorders i/o to
be sequential) there is little significance at all to
file fragmentation. That is all the more true if the OS
and the filesystem also do i/o reordering.

Sorry to say this, but your statement reveals considerable ignorance
of modern computer systems. It is wrong in most regards.

Your first error is in confusing the physical layout of the file with
the sequence of I/O commands needed to access the file.

Your error is not knowing what has been going on with
filesystem and disk technology in the past two decades.

By far (several orders of magnitude) the slowest controllable disk
I/O operation is the seek - moving the read/write heads from one
track to another. Fragmented files - those that are unnecessarily
spread across different areas of the disk - take much longer to access
because seek time takes a long time. When a file is contiguous it can
typically be read with only a single seek. If the file is fragmented
it will require additional seeks to access each chunk.

And no, disk buffers are not relevant. Not even a little bit.
Reordering I/O is similarly irrelevant. Disk drives don't reorder
I/O and operating systems do so only in a significantly
multiprocessing environment, which your desktop PC is not.

That is absolutely false.

Buffers are relevant, both in the OS and in the hard
disk itself. The OS buffers allow avoiding physical
reads all together. The hard disk buffer is what allows
re-ordered i/o request. Reordering is relevant, both
for avoiding unnecessary seeks but also to avoid
unnecessary sector reads on the same cylinders.

And yes the disk drives themselves can and do reorder
physical writes to the disk. Any modern fileysystems
will also re-order i/o, and *all* of them are in fact a
"multiprocessing environment" in the sense of using DMA
from multiple tasking OS's.

*Unless* perhaps you use Windows, which I don't. In
fact my desktops, as well as my laptop, have two CPU's
and are not just doing virtual multiprocessing, but
physical multiprocessing.

As an aside, recent versions of Mac OS X do ongoing file
defragmentation as a part of normal operation.

You are attempting to misguide a reader. OSX does *not*
do defragmentation. The filesystem is designed to avoid
fragmentation itself, and what is more important it
specifically attempts to avoid fragmentation that would
affect performance (for example, putting fragments on
the same cylinder, to avoid seeks).

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@xxxxxxxxxx
.

Relevant Pages

  • Re: Caching control
    ... |> | invalidate/unmap them in order to discard the data from memory. ... |> writing out to disk. ... | easy to discard as clean disk cache. ... stating that a specific amount of RAM can be used only for I/O ...
    (comp.os.linux.development.system)
  • Re: Dynamic configure max_cstate
    ... fio is a disk I/O workload ... which doesn't spend much time with cpu, ... I also thought it's related to timer. ...
    (Linux-Kernel)
  • Re: Dynamic configure max_cstate
    ... fio is a disk I/O workload ... I also thought it's related to timer. ... But oprofile data shows acpi_pm has more cpu utilization. ...
    (Linux-Kernel)
  • Re: Dynamic configure max_cstate
    ... fio is a disk I/O workload ... are we actually taking ACPI Cx exit latency into account, ... I also thought it's related to timer. ...
    (Linux-Kernel)
  • Re: Short SMART check causes disk op timeouts
    ... Second, your short offline test runs at 0300, but the errors you're ... 0301 in the morning, and many of those are I/O bound. ... perform a lot of disk I/O, so it's possible that on Sunday specifically ... taking too long when internally suspending the SMART test. ...
    (freebsd-stable)