To Defrag or not to Defrag?

[Gnor]

Dear Contributors!

Since it is unlikely to post here a PDF, I recommend to search for "A Fast
File System for UNIX".

The current file name is most probably "ffs.ps". The older file name
"05fastfs.ps" ten years ago is no longer existent.

GhostView will show it, you can convert it to PDF with this tool as well if
you prefer Adobe Acrobat Reader etc.

I'll refer to this paper in discussing defragging.

Back in old DOS/Win16 days, there may have been an advantage for contiguous
files.

Like on the PDP-11, binaries got slurped into RAM in one chunk, OS/2's and
Windows' DLLs already posing a problem because no longer a single binary
got loaded.

See on page "3" why defragging the "old" 7thED file system was a non-issue
under *NIX then, it involved a dump, rebuild, and restore.

There also an idea published 1976 was mentioned that suggested regularly
reorganising the disk for restoring locality which could be viewed as
defragging.

The VAX introduced a new concept of virtual memory, demand paging. Prior to
this, only swapping of segments, mostly of 64KB size, was common.

Since then, binaries are read only that far to set up the process, the
"call" to main(argc,argv), note an OS *returns* to a process to facilitate
multitasking, involves a page fault.

With some luck, that page is in the buffer cache, but surely the first call
to a function will result in another page fault, where the luck of finding
it in the buffer cache is greatly diminished and the disk block surely have
been rotated away.

Page "7" of the FFS paper mentions a rotationally optimal layout, in DOS
days, there were tuning programs to change the interleave factor which
became obsolete when CPUs got fast enough and DMA disk access became
common, the paper calls this I/O channel, and interleave factor "1" became
standard.

Also, booting becomes less sequential if you extend this term beyond the
loading and starting of the kernel to hardware detection and especially to
loading and starting background processes and initialising the GUI and it's
processes.

Linux is still sequential up to GUI start, which is parallelised
everywhere, but some of the BSDs try to go parallel after hardware
detection, albeit with some provision for interdependencies.

OS/2, Windows, and MacOS_X switch early to parallelised GUI mode, MacOS<=9
never showed a text screen, I don't know if MacOS_X ever shows a text
screen.

Then quite a bazillion of processes contend for the disk arm, you may
separate some of *NIX subtrees to different SCSI disks to limit this,
albeit not too much, IDE disks are only recently capable of detaching after
a command to enable parallelity.

Partitions on the same disk may aggravate the problem because they force a
long seek when the elevator algorithm has to switch partitions.

Especially DLLs, due to their shared nature, shared libraries under *NIX
are not that numerous and pervasive, are never in the vicinity of the
binary calling them.

Thus defragmenting becomes practically irrelevant, at least for
executables.

Buffer underrun protection is now common with any CD/DVD toaster due to
their high speed, but the source of buffer underruns is more a process
madly accessing the disk and/or the GUI than a fragmented disk which is
usually faster than any high speed CD/DVD.

So defragmenting becomes irrelevant for normal files as well.

Traditional defraggers run in batch mode, which may be tolerable on a
workstation after business hours, but intolerable on an Internet server
which is accessed 24/7.

Also batch defraggers which don't need umounting the disk and thus can run
in the background have the problem, that their analysis is likely to be
obsolete at it's end so the defrag is suboptimal.

This is especially true for mail and/or news servers where bazillions of
mostly small files are created and deleted in quick succession.

There would be the option of an incremental defragger which moves any file
closed after writing to the first contiguous free space after and fill the
gap from files below this boundary.

Over time, file shuffling decreases as static files tend to land at the
beginning of the disk and the dynamic ones behind them.

A batch defrag with ascending sort over modification date may shorten this
process significantly.

However, this scheme also gets overwhelmed on mail and/or news servers.

As mentioned on page "3" of the FFS paper, defragging was too costly back
then, thus they decided to implement a controlled fragmentation scheme
described mostly on page "8" with cylinder groups and heuristics to place
files there, large files being deliberately split up.

OS/2's HPFS definitely is modelled after BFFS, Microsoft tries to hide that
this holds also for NTFS.

I verified this both on NTFS 4 and 5.1 by loading a bazillion of files,
including large ones, to the NTFS drive and firing up a defragger with a
fine block display.

A checkerboard pattern will show up, revealing BFFS-like strategies.

Defragging this spoils the scheme and only calls for regular defrag runs.

Thus even under NTFS, defragging becomes a non-issue, this may be different
for FAT.

Note NTFS is still difficult to read with a dead Windows, and practically
impossible to repair.

Bad idea for production systems.

The successor to NTFS is still to be published, so no information about
this is available, it will only be sure that your precious data again are
practically lost with a dead Windows.

So it is reasonable to keep your precious data on FAT, or better on a Samba
server.

They will be accessible for Windows' malware anyway, that is the design
fault of this OS.

Even Vista will not help, the "security" measures are reported to be such a
nuisance that users will switch them off.

And malware will find it's way into even with full "security" enabled.

However, XP runs the built-in defragger during idle time and places the
files recorded in %windir%\Prefetch\ in the middle of free space and leaves
enough gaps for new files.

Boot time is marginally affected by this.

To get rid of this, you must disable the Windows equivalent of the cron
daemon which may be undesirable.

You can disable the use of %windir%\Prefetch\ with X-Setup, then these
files aren't moved, but the defragmentation will still take place.

Thus it is a better idea to leave these setting as they are, file shuffling
settles comparably fast.

Thus defragging becomes an old DOS/Win16 legacy which is still demanded by
the users.

This demand is artificially kept up by the defrag software providers which
want to secure their income, even new companies jump on the bandwagon.

Back in DOS times, Heise's c't magazine closed their conclusion with the
acid comment that defragging is mostly for messies which like to watch
their disks being tidied up, but only these, not their room or house.

Debian Sarge cometh with an ext2fs defragger, unusable with ext3fs,
requiring umounting the disk, thus practically useless.

The mail address was dead, so no discussion possible.

However, ext2fs already follows the ideas of BFFS, so defrag should be a
non-issue there, too.

ReiserFS got somewhat out of focus since the fate of Hans Reiser is quite
unknown with that lawsuit for murdering his wife.

Also tests of Heise's iX magazine revealed that balancing it's trees will
create an intolerable load on mail and/or news servers.

Rumours were that a defragger was thought of.

Note also that internally the CHS scheme is broken by some disk vendors,
Heise's c't magazine once found an IBM drive going over one surface from
rim to spindle and then the next surface from spindle to rim, creating a
HCS scheme.

Also disk platters are now few to one to cope with low height profiles,
even beyond laptops, disks are now 3.5" and 2.5" with heights below a third
of the standard height form factor. 5.25" disks with full height, CD/DVD
are half height, and ten platters as Maxtor built once are unlikely to
reappear.

Also the sector zoning breaks internally the CHS scheme, but BFFS' cylinder
groups are still beneficial in all these cases, it will spread disk access
time and speed evenly anyway.

Conclusion: Defraggers are obsolete now, only an issue for some software
providers, and probably for harddisk vendors.

Kind regards

Norbert Grün (gnor.gpl@googlemail.com)

[Lundholm]

Hi Norbert,

You are absolutely right. I have said something similar, and even Jeroen says that defragging is not that important. Basically, you just replace some files that are placed here and there and everywhere, with some other files that are placed her and there and everywhere - only defragmented.

However, the main feature of JkDefrag is it's ability to optimize the disk, i.e. place all files intelligently. A simple thing like placing the directories at the beginning gives a performance boost.

So, why don't you just test it, and see what happens?

You are trying to prove that the spider has 6 legs. Why don't you just count them?

Cheers

[cquinn]

Defragging is not that important, if your operating system or file system are capable of seeing
into the future, and accurately predicting the most efficient file layout for all the files
originally installed, all the files that are likely to be added over the life of the disk,
and all the modification, expansion, and deletion of those files... while other file operations
are ongoing or pending on the same space.

What also seems to be overlooked is that file optimzation itself works better when there is low
fragmentation of other files in the layout, providing better access to contiguous spaces to place
files for optimal access. 

A quick search for " A Fast file system for unix  "ffs ps" "  shows no hits on that article that
are newer than August of 1984.   I won't try to argue its merits for points that were probably
valid considering the state of the art in storage hardware and software at the time it was written.     

I will point out that many members of this forum have direct experience with the benefits and
performance increase resulting from file defragmentation and optimization as seperate and combined
solutions... not just as anecdotal reports, but in some cases as measured and comparative differences
in file access for fragmented files and for various methods of defrag and file optimization.   And
there have been a few changes in the way data is handled now (in hardware and software) that may be
significantly different than the assumptions in that original piece.

So, to conclude that defraggers are obsolete, to me, seems to be missing some important empirical
data from the analysis. 

------
 I was going to avoid addressing all of your points,  but there are a few I feel the need to comment on:

*Especially DLLs, due to their shared nature, shared libraries under *NIX
are not that numerous and pervasive, are never in the vicinity of the
binary calling them.

I thought the whole point of DLLs and Shared libraries was to load the common code into memory once;
then the binary calling it would no longer have to rely on disk access at all to use whatever
function was made available in the libary being called.  The exception might be if that particular
section of memory was swapped out to the pagefile, which should ideally still be faster to access
than going back to the original file.

*Buffer underrun protection is now common with any CD/DVD toaster due to
their high speed, but the source of buffer underruns is more a process
madly accessing the disk and/or the GUI than a fragmented disk which is
usually faster than any high speed CD/DVD.

This might be true if one assumes there are no other file operations going on that could affect
the process.  Buffer underun protection, while a more common practice, is usually called upon when
the burning software detects a significant dip in the sustained transfer rate of the files it is
attempting to send on to the more limited internal buffer of the CD/DVD drive.  Depending on the
sensitivity of that burning software, the resulting action can be to slow down the burning process,
to pausing the burn altogether while the software waits for its own buffer to catch up.   
That can be avoided or alleviated by having the files to be burned laid out in a more contiguous
fashion, to assist feeding the file(s) in larger chunks to the managing software. 

*Traditional defraggers run in batch mode, which may be tolerable on a
workstation after business hours, but intolerable on an Internet server
which is accessed 24/7.
Also batch defraggers which don't need umounting the disk and thus can run
in the background have the problem, that their analysis is likely to be
obsolete at it's end so the defrag is suboptimal.
This is especially true for mail and/or news servers where bazillions of
mostly small files are created and deleted in quick succession.

Not all defraggers run in batch mode (contig.exe for example, was designed to work file by file).   
And defraggers like JKDefrag can be run in a "targeted" mode which addresses only specific files or folders as
desired by the user.  (As you sort of describe in the second point, many defraggers can also be run at a lower
priority to work while having less of an impact on the primary purpose of the server or system in question)
(That same arguement would also mean that Backup and data replication programs, Auditing and Data analysis tools,
Anti-Malware utilities, and similar applications should also be discarded for having a potentially degrading effect
on server file performance, since all those functions are likely to benefit from file optimization of the working
data sets, and can have more of an impact on a non-defragged file volume.  In addition server performance as you
describe would also benefit from consolidation of free space, which might be more important in the context of needed
to continually modify and expand on existing data sets.)
Even an analysis that is incomplete at the end of the defrag process is going to be more optimal at the end than
at the start, unless over twice as much content (as was originally there) is being transferred to the disk during
the defrag operation.  Any newer data that is introduced during the process remains a smaller percentage of work
that may need to be completed at a later time.  That is assuming the defrag program itself is incapable of running
a later analysis to check for fragmentation of files over a certain threshold, which it can attempt to correct before
finishing the overall defrag operation. 

Your second and third points here are contradictory.  If bazillions of mostly small files are being created *and deleted*
in quick succession, then their temporary existence has little effect on overall fragmentation of more permanent files,
and would have no effect on the file operation needed to move a previously analyzed file into a more contiguous space. 

Using contig as an example, the program first checks a file for the number of fragments it is in, and if it can find a
block (or blocks) of contiguous space to move the file into, first will allocate that space so no other file operations
can affect the transfer of data to the new block(s) of space, and only requests an update of the file pointers when the
initial data copy operation is completed.  This avoids (tries to avoid) the possibility of other file operations causing
crosslinks or other mixing of data, and can safely run at an idle priority where the file operation can take as long
as neccessary to insure a minimal impact on the rest of the system.   Unless the server is already being run over normal
tolerances for CPU, Memory, and Storage needs, there should be plenty of resources remaining to complete such background
processes. 

*Note NTFS is still difficult to read with a dead Windows, and practically impossible to repair.
Bad idea for production systems.

Windows and Linux live CD abound that have the capability of reading an NTFS volume when the original OS is "dead" or
incapable of accessing the data.   Some data recovery programs even have the ability to locate and repair files on a
disk with a corrupted MFT.  When something is practically impossible, it sometimes helps to have an impractical approach
to solving the issue.  The only cases where an NTFS partition should be completely unreadable by transferring the drive to
another system, or booting another OS to do the analysis, are when the entire partition has been encrypted by the prior
OS, or possibly in the case of accessing a drive that has been converted to a dynamic disk.
Not running a backup solution or some other process to validate and protect data on production systems
is a bad idea regardless of the file system in use.  From personal experience, a properly set up production server is in
far greater risk of hardware failure or damage from user interaction than from file system corruption in and of itself.

Your points seem to be ideas presented in support of a foregone conclusion that defraggers are obsolete, instead of an examination of what
factors cause so many other observers to think that defragmentation still serves a purpose. 

Even Vista will not help, the "security" measures are reported to be such a
nuisance that users will switch them off.

The only security measure that might annoy users is UAC,  even with that turned off there are still at least half a dozen other security features/layers that malware has to get past to be able to significantly affect the file system for the whole computer. 

This demand is artificially kept up by the defrag software providers which
want to secure their income, even new companies jump on the bandwagon.

Then why are free defraggers like JKDefrag in such high demand as well?  I've not seen Jeroen
buying ads on prominent websites proclaiming the effectiveness of his program, but I have
seen a recent post where he was surprised by the bandwidth costs of supporting downloads in recent months.   It would seem the demand is quite high even without artificial aid/hype.

Also disk platters are now few to one to cope with low height profiles,
even beyond laptops, disks are now 3.5" and 2.5" with heights below a third
of the standard height form factor. 5.25" disks with full height, CD/DVD
are half height, and ten platters as Maxtor built once are unlikely to
reappear.

The need for more than 5 disk platters in a single case has been reduced by the massive increases in data density for individual platters, and the lowering of production costs, that have been achieved in more recent years.  Even so, the continually rapid expansion of available data pushes demand for three to five platter drives on the high end to introduce the next generation of multi-terabyte drives, and the idea of multiple platters has long been replaced by the idea of multiple drives in simple RAID, NAS and SAN configurations; where defragmentation becomes less of a direct to hardware tool, and more of an idea to augment data operations and performance for large volume data.   Modern servers (and some workstations) treat individual hard drives in the same way we used to look at the massive disk packs that were once popularized in mainframe design.

[jeroen]

Since then, binaries are read only that far to set up the process

Vista has "Superfetch", which not only pre-caches the entire binary, but also all the other files used to start the program. This is faster because the harddisk heads need to move less. Reading data on demand was a good idea in the past, but has become obsolete by cheap memory, and lot's of it.

Then quite a bazillion of processes contend for the disk arm

Your basic argument seems to be that fragmentation doesn't matter because the disk arm is moving about all the time anyway, because of multitasking. That may be true on a fully utilized mainframe computer, but not on a desktop PC. It's hurry-up-and-wait for PC's. Just look at the Windows task manager, the CPU spends most of it's time in the "System Idle Process". Harddisk heads don't move so much, and fragmentation therefore causes far more performance loss.

So defragmenting becomes irrelevant for normal files as well.

Have you every played a heavily fragment movie? Or tried to search through a heavily fragmented database? Or tried to copy a heavily fragmented logfile? Just a few examples. I'm sorry, but your statement is simply not true.

So it is reasonable to keep your precious data on FAT, or better on a Samba server.

NTFS has far better recovery features than FAT, and there are now many tools available to access and repair damaged NTFS disks. A Samba server is far slower, not practical for users at home, and dramatically decreases the mean-time-between-failure (because there is more hardware involved).

Defraggers are obsolete now

Needless to say that I totally disagree.

[Myriades]

An other value added in favor of defragmenting :
All brand are trying to design their computers as silent as possible
A fragmented hard drive is most noisy than other one which is not

[majoMo]

It's interesting to see the people to say that defragging is an unnecessary procedure. Sometimes they say this and like to say that it is important to clean the PC from unnecessary files (temp or others and... recycle bin). So the buit-in MS CleanUp utillity is needed and not obsolete; the buit-in MS defrag tool is useless and obsolete.

It seems that it's good to clean PC - but it's not good to organize the PC!

Like a house: maybe it's good to clean a house - but it's far from appropriate to arrange it. So the people can lunch in the bathroom and take a bath in the kitchen. A efficient and fast process. And a very interesting conclusion from an open space theory. Maybe is obsolete to organize a open space. It is organized itself...

I'm not a computer expert - but I like ever to appreciate experts statements and conclusions... Because the human mind is ever a very entertaining package and mysteriousness.

[ABasketOfPups]

Most of what's been said in reply, I agree with: you're saying a lot of things about defragging, but it's not like it's hard for people to actually test and compare results.  There's no reason for a theoretical exercise when you can do a real life experiment, and people do see results in their regular operations when they defrag.

I do disagree about the multitasking: there are plenty of times in a modern machine where the thing IS trying to load from several files, and the end result is thrashing.  However, defragged files are going to cause considerably less head movement overall, with or without the multitasking being thrown in, and to be fair to Jeroen, a server really would have a LOT more of that kind of thing happening than even a fairly busy desktop.

Filesystems have come a long way, including NTFS, since 1984, but they still have to deal with the reality of the physical device, and the repeated writing and deleting of files.  They don't have mystic powers.

I added a comment to the "JKDefrag for Linux?" thread, but I think it bears repeating: Linux and similar OSes got their "we don't need no stinking defrag" reputations, or legends depending on your view, as server OSes with lots of partitions.  You set up a Windows box with a bunch of partitions for temp files, logs, Windows itself, program files and My Documents separated, and NTFS will handle them with little or no defragging.  That's the equivalent of how a server is generally set up.  But who does this for home? It's just tedious and complicated.

RAM really helps, of course, if you have a lot of RAM for your disk cache, that'll reduce your overall access issues... as long as you don't need it for anything else.

[Gnor]

Dear Contributors!

I am pleased to have stung into a wasps' nest by posting here this thread. ;-)

I think, it is a good exercise to throw in an opposing meaning.

I grew up 30 years ago on a machine of the complexity between an IBM-PC/XT and /AT, but shared between 50 users.

It hath segments of 96KB and 768KB core, four-way interleaved and 48 bits wide, thus the odd sizes, clocked at 16kHz, no typo, this is audio band, not VHF video broadcasting or even mobile phone frequencies RAM is now connected at 64 bit.

We were used to count clocks and bytes, which carried over to the 8-bit and 16-bit machines, until those 32-bit machines and OS' came into fashion, all old programming virtues went down the kitchen sink.

OOP loads all ancestor objects up to the root into RAM, also all routine calls will rattle up to the root and down again, and DLL linkage far slower than a hard statically linked call, note there once was a proverb: "Windows maketh programs amble instead of run!" has eaten up all the massive computing power increases since 30 years ago.

Well, Global Heatup will make our old virtues: "Touch as few data as possible, touch data as rarely as possible, don't mess around!" come back into vogue.

Also New Economy will pay even more than the current US housing crisis, still picking every morning the cheapest guy from the street, they will be forced getting us old (50+) hackers for high pay to keep their business alive.

Note the old beast mentioned above was a mainframe, which corresponds to a server today, terminals were Thin Clients, and serial lines created a star-topology network. If you look deep into TCP/IP, you'll find quite a number of ASCII-acronyms there.

I serviced also mission-critical embedded computers, so my credo is: Machines have to have uptimes as long as possible, every downtime has to be avoided.

Thus BFFS of 1984, and the defragging idea almost a decade older (1976), with it's first cylinder group redirection at 40KB and every MB thereafter is still a fine style of controlled fragmentation to keep disk access and throughput times evenly distributed. Note BFFS increases disk bandwidth by 900% over the old 7thED files system at the same block size, the latter being comparable to FAT of any kind.

Aye, I use still Windows for legacy issues, there was no affordable *NIX for 80286 machines at X-mas 1988, otherwise I would never have benn locked into the Billyverse. I do quite a fight converting legagcy files into less legacy formats, Lotus WordPro hath a killer feature by implementing the CSS feature "page-break-before: avoid" which can go into a document template like the "page-break: avoid" of WordPerfect and LaTeX/TeX, the "page-break-after: avoid" cannot do this, if applied seriously to a business letter. I tend to create exactly that much text, that the "Kind regards" and following will land onto the next page. I wrote on a Selectric II clone beforehand, so I was less then satisfacted by the means of DOS-Word, Lotus SmartSuite with AMI-Pro 3.0 for OS/2 2.x offered the CSS feature "page-break-before: avoid" which allowed me to automate letter-writing for the first time. The other alternative was LaTeX/TeX, which came shortly later with Linux. AMI Pro 3.0's format was quite parseable, but WordPro's a binary mess, halfway legible only if you disactivate compression. Lotus' formats are prominently missing in file format listings in the Net.

Note for a 3D legacy search for "sütterlin". The stange quotes or tremas or dieresises on a, o or u take legacy from the strange lowercase "e" in this font, which went up above these letters in writing practice. Note Dutch will distinguish between ä. ö, and ü, and ae, oe, and ue in porper names. In German, there "oi" is a long "o", as in "ow", however "ui", is an "ü".

Sorry, I recommend Billyware as abolutely unprofessional, despite the success reports of them in taking over another professional. Let them take over the whole business world and they can no longer escape any liability as now.

The last few paragraphs just illustrate my professional views, uppercase latin letters were invented in Rome about 2,500 years ago, lowescase latin letters were invented in Aix-la-Chapelle nearby 1,200 years ago, and Arabian numerals were imported by Adam Riese about 500 years ago. There were Gothic letters, in Germany known as "Fraktur" and "Sütterlin" was the scholar version of the "Kurrentschrift" of older German offices, just a bit simplified and made upright to be more easy to learn.

Kind regards

Norbert Grün (gnor.gpl@googlemail.com)

[Donn Edwards]

"Conclusion: Defraggers are obsolete now, only an issue for some software providers, and probably for harddisk vendors."

Yawn.

[cquinn]

The last few paragraphs just illustrate my professional views...

 They may illustrate your professional experience, but they also illustrate your professional bias.
Nothing in the last post indicates any personal experience with, or a valid arguement against the practices of file defragmentation
or file optimization (two seperate issues that are often combined in the utilities that manage them).

It is a fact that fragmentation occurs (or can occur) when an Operating System tries to make efficient use of a storage device by
filling in gaps of space that would otherwise go unused if the OS tries too hard to find the "perfect" space for each file it deals with.
This becomes even more true when that OS has to deal with multiple users, I/O threads and read/write requests to different files. 

It is a fact that some file systems are designed to be more resistant to fragmentation that others, but no FS is completely fragment free.   NTFS is more resistant that FAT, but still incurs fragmentation depending on the average size of the files it stores and the cluster size that was initially created when a NTFS partition was formatted.    Linux filesystems (ext2fs, ext3fs) are even more resistant due to a different method used to initiall allocate space for a given file (http://www.itworld.com/Comp/3380/nls_unixfrag040929/index.html), and the practice of partitioning the disk to seperate different categories of files (/boot /(root) /home /swap) to also reduce the chances of fragmentation in mixing system and user files.   Even with that fragmentation will occur as new files are introduced to the storage space, and as different applications (bittorrent, media creation and editing, web surfing, word processing, database management) cause literal "fragments" of a complete file to be saved in the process of generating content.     

This is somewhat evident in the article that I link to above, and in the previous conversation in these forums in
" Requests for new features > Multiplatform! JKdefrag on Linux? " where if became quite evident that not only is Linux subject to
fragmentation, and that there are utililties to manage it on that platform (filefrag), but that it can create fragmentation scenarios that
far exceed what the average Windows user is likely to incur.  I encourage you to read the whole thread, but the relevant point was made there by user lulu135: http://www.kessels.com/forum/index.php?topic=263.msg1498#msg1498  on the highly frag-resistant ext3 filesystem.

You seem to be please to have "poked a wasps' nest" in these posts you have made, but it comes across as if you are more interested
in starting an arguement than in engaging in a serious discussion.    It can be a good idea to take an opposing viewpoint, but only if you have a valid position from which to debate, otherwise it can be a waste of valuable intellectual effort. 

Your argument seems to be that defragmentation utilities are completely unneeded because file systems like BFFS were designed to address that issue long ago (I have to assume you are referring to the Berkeley Fat Fast File System, since you seem reluctant to clarify your statements).  But you don't address how usage patterns that have changed from the systems used in 1984 can affect the potential of fragmentation now.  Nor do you even attempt to address the idea of file optimization, not just placing files where they are less likely to fragment, but also the idea of placing files in a pattern that exemplifies your virtues of minimizing disk access and maximizing bandwidth.

[Donn Edwards]

What's the point of "discussing" whether to defrag or not in the forums of a defrag program? Why not discuss the merits of war in a military forum? DUH.

Fragmentation happens on Windows sytems, both NTFS or FAT. You can measure it and measure its effect on system performance. This is hardly rocket science. Personally I'm bored by the discussion of unix file systems, or any other file system not available on WinXP. Why? Because it doesn't affect me.

If you genuinely think that defragmentation is irrelevant, then run Windows 2000 Small Business Server with Exchange and SQL Server and no defrag for 3 years and don't call me when the hard drive dies or the machine grinds to a halt. I'll just say "I told you so".

Let's discuss the holocaust instead. Sheesh.

[schitzn]

Back in DOS times, Heise's c't magazine closed their conclusion with the
acid comment that defragging is mostly for messies which like to watch
their disks being tidied up, but only these, not their room or house.

Thats me.

But unfortunately in Windows Time, Defragmentation benefits are self provable just as Jeroen has said by playing heavily defragmented Movie, database or copying a large log file.

You seem to be technically savy, your input here as a professional is appreciated, but I seem to have difficulty reading your thread, you seem to write like Shakespeare, and talk a lot about Amiga's and Commodore 64 things.  I don't see any benefit to me or anyone else by posting such things.