Re: which PC

Floyd L. Davidson wrote:
rfischer@xxxxxxxxx (Ray Fischer) wrote:
Floyd L. Davidson <floyd@xxxxxxxxxx> wrote:
rfischer@xxxxxxxxx (Ray Fischer) wrote:
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.
Nah.

Below you cited an Apple webpage,

http://docs.info.apple.com/article.html?artnum=25668

which you apparently did not read. It says, among other
things,

Mac OS X 10.2 and later includes delayed allocation
for Mac OS X Extended-formatted volumes. This allows a
number of small allocations to be combined into a
single large allocation in one area of the disk.

How do you supposed "delayed allocation" relates to the
discusssion above where you claim it doesn't happen, and
is never used on a desktop?

Fragmentation was often caused by continually
appending data to existing files, especially with
resource forks. With faster hard drives and better
caching, as well as the new application packaging
format, many applications simply rewrite the entire
file each time. Mac OS X 10.3 Panther can also
automatically defragment such slow-growing files. This
process is sometimes known as
"Hot-File-Adaptive-Clustering."

When the filesystem does that, it amounts to reordering
i/o. "Better caching", is what Apple says is important,
and you say is irrelevant.

Aggressive read-ahead and write-behind caching means
that minor fragmentation has less effect on perceived
system performance.

You say irrelevant? Apple doesn't agree with you, and
says so on the web page you cite!

Buffers are relevant, both in the OS and in the hard
disk itself.
But not to fragmentation.

They make it a non-issue. As Apple states on the
webpage you cited.

The OS buffers allow avoiding physical
reads all together.
Only occasionally. Track buffers reduce or elliminate latency in
track-local reads.

The most likely to be buffered data is the most likely to be
used data, hence occasionally is not correct.

Let me repeat,

"The OS buffers allow avoiding physical reads all
together."

Read it until you get the point. Track buffers are one
thing, disk caching is another. And regardless the
whole point is to eliminate physical reads all together.
Not just occasionally, but often. And every desktop
personal computer either uses a filesystem/OS that
implements such technology, or it is exceedingly behind
the times. By what? 15 years or so?

And yes the disk drives themselves can and do reorder
physical writes to the disk.
What an excellent way to corrupt a file system. Tell us: How doesn't
the disk drive know which blocks to write first?

Why would that corrupt a filesystem?

The disk drive obviously knows more about which
operations are fastest for it to make, and choses the
order in which to write accordingly.

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.

But in reality, PCs don't do enough multiprocessing to take advantage

What gives you that idea? Mine certainly does! Maybe
Windows can't, but any real OS can.

of reordered I/O. Reordering I/O requires that you have several I/Os
pending that can be reordered. In a desktop PC it is rare that that
happens.

No it actually isn't all that rare.

You are aware, for example, how often such things as the
init files for a shell are read, how often the various
history files and so on for a shell are written, how
often log files are written, and how often a process
that has only been partially paged into RAM generates a
page fault and requests another disk read... right?

Basically file i/o is rather continuous.

Oh, you didn't realize that your little old desktop PC
is *much* more disk intensive than a Big Iron computer
of just a couple decades ago was???

*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.
Non sequitur. The ability to do multiprocessing does not mean that
multiprocessing is actually occurring.

Well, in fact I have a graphic display of the CPU load
on my desktop, and you are wrong. It is banging away at
both CPU's most of the time.

It is hardly a non sequitur, though your evaluation of
it is exactly that.

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.
Yes, it does. I've seen the code and Apple diagrees with you.
http://docs.info.apple.com/article.html?artnum=25668

Why didn't you bother to read it? I does not disagree
with me, it says,

"You probably won't need to optimize at all if you use
Mac OS X. Here's why:

...

Aggressive read-ahead and write-behind caching means
that minor fragmentation has less effect on perceived
system performance.

For these reasons, there is little benefit to
defragmenting."

Hence it does specifically say that your comments above
are not correct.

No defrag utility is supplied with an Apple Mac. There
is no automatic process run every few days to defrag
either.

And that webpage does not say *anywhere" that "Apple
code" does defragging. It says the filesystem avoid
fragmenting files. If you can't read that and get it
right, who cares if you've seen code that you don't
understand.

Of course I suspect that you misread this statement to
mean that the filesystem is defragged,

... Mac OS X 10.3 Panther can also automatically
defragment such slow-growing files. This process is
sometimes known as "Hot-File-Adaptive-Clustering."

But you aren't right there either. They are saying that
when a file is written it will happen in a way that does
not cause fragmentation. That is part of the
filesystem, and is not some defrag process that is run
by a user or the OS either one.

The filesystem is designed to avoid
fragmentation itself,
Which file system is that? Do you even know? Apple has varying
support for at least three different file systems.

Well I doubt that you are even close on that. BSD can
support far more than only three different file systems.

Regardless, the webpage you cited is about the HFS+
journaling filesystem. But virtually all filesystems
designed for unix systems in the past two decades have
had features that make defragmentation unnecessary. I
know of not a single unix based system that is
distributed with a defrag tool.

and what is more important it
specifically attempts to avoid fragmentation that would
affect performance
Like almost every other decent file system. But that too is a
non sequitur.

Ray I fail to see the point in making the type of
foolish statements you've made in this and the other
articles you've just posted in this thread. Half the
time you simply make "No it isn't" type statements and
provide no discussion of why you think something is or
isn't. And the one time you actually cited a valid
reference, it disagree with virtually *everything*
you've been saying.

Please read all of the following URLs, and stop making a fool of yourself.
http://docs.info.apple.com/article.html?artnum=25668
http://docs.info.apple.com/article.html?artnum=106214
http://guides.macrumors.com/Enhancing_Performance_Of_Mac_OS_X
.

Relevant Pages

  • Re: XP Defrager
    ... rendering knows for a fact that fragmentation can cause enough delays to ... drives between each editing/rendering session in order to be sure the ... Video work is extremely disk intensive. ... It's a lot cheaper to just let it defrag in between. ...
    (microsoft.public.windowsxp.general)
  • Re: which PC
    ... multiprocessing environment, which your desktop PC is not. ... single large allocation in one area of the disk. ... When the filesystem does that, ... No defrag utility is supplied with an Apple Mac. ...
    (rec.photo.digital)
  • Re: defrag one TB drives
    ... used internally are in the external drives. ... practices and type of disk usage. ... you will definitely notice the fragmentation; ... You might even have to run defrag multiple times to get a full defrag ...
    (microsoft.public.windowsxp.general)
  • Re: Defragment
    ... That's the reason Defrag is most effective in Safe ... Disk Defragmenter often says there is no need to Defragment. ... fragmentation that is likely slowing things down, IFF you happen to be using ... shumogy wrote: ...
    (microsoft.public.windowsxp.basics)
  • Re: defragmentation issues in XP
    ... An interesting Disk Defragmenter Report. ... The problem could be the fragmented pagefile. ... I have also run defrag in Safe Mode - made no difference - it still ... Volume fragmentation ...
    (microsoft.public.windowsxp.perform_maintain)