Optimizing files to create the large open expanses shown on disk maps that many folks THINK is de-fragmentation (but is nothing of the sort) will actually short circuit this process and ensure file appends trip the reposition switch. And of course the forced extra disk activity will VERY quickly re-shred the disk map. This is actually a false optimization for most folks as the forced rewrites of <20MB files will be slower than the contiguous appends in the unjustly accused of fragmentation disk map.
This is a very important point, and it's something that was addressed in UNIX: If you want to optimize a file system for frequent updating of existing files, you do not want to mash all the files as close together as possible. You do want to spread them out enough that adding another paragraph to your web page doesn't fragment the file or force the filesystem to go looking for a space that can accommodate 8K instead of 7.5K. The result is going to look messy on one of those hard drive maps that defraggers are so fond of, but in terms of actual use it handles the problem of frequently accessed and updated files very well over time, particularly if they're small files. This is an optimum arrangment for, say, a file server - not coincidentally, one of the primary duties that UNIXen have been set to over the years. But it makes sense for any system that does a lot of interacting with files. Like, say, the average PC.
At any rate, the take-away message is that between Apple's own efforts and the firmware in the hard drives themselves, fragmentation is a (continuously) solved problem for the vast bulk of the computing population. The need for low-level disk management went away along with MacOS' need for low-level memory management, and good riddance.
Comments
Originally posted by AirSluf
Optimizing files to create the large open expanses shown on disk maps that many folks THINK is de-fragmentation (but is nothing of the sort) will actually short circuit this process and ensure file appends trip the reposition switch. And of course the forced extra disk activity will VERY quickly re-shred the disk map. This is actually a false optimization for most folks as the forced rewrites of <20MB files will be slower than the contiguous appends in the unjustly accused of fragmentation disk map.
This is a very important point, and it's something that was addressed in UNIX: If you want to optimize a file system for frequent updating of existing files, you do not want to mash all the files as close together as possible. You do want to spread them out enough that adding another paragraph to your web page doesn't fragment the file or force the filesystem to go looking for a space that can accommodate 8K instead of 7.5K. The result is going to look messy on one of those hard drive maps that defraggers are so fond of, but in terms of actual use it handles the problem of frequently accessed and updated files very well over time, particularly if they're small files. This is an optimum arrangment for, say, a file server - not coincidentally, one of the primary duties that UNIXen have been set to over the years. But it makes sense for any system that does a lot of interacting with files. Like, say, the average PC.
At any rate, the take-away message is that between Apple's own efforts and the firmware in the hard drives themselves, fragmentation is a (continuously) solved problem for the vast bulk of the computing population. The need for low-level disk management went away along with MacOS' need for low-level memory management, and good riddance.