[MacDV] Re: more about the inutility of defragmenting an OS X FS.

[James Asherman]

On Wednesday, December 31, 2003, at 12:23  PM, Peter van der Linden 
wrote:

> On Dec 30, 2003, at 8:45 PM, James Asherman wrote:
>>  There is a graphic map that shows that a significant portion of what 
>> you might think is freee space is actually small useless holes in 
>> otherwise crowded areas. and llarge tracts of frree space have iTunes 
>> hanging around like muggers waiting for some video to screw up.
>> Jim
>
> Let me put this another way, Jim.
> Your view on disk defragmenting (whatever that means in the context of 
> HFS+, which already uses groups of allocation blocks called "clumps" 
> to limit fragmentation at the sector level) relies on at least three 
> false assumptions:
>
> 1.  The HD map shown by programs like is an accurate representation of 
> disk sector layout on disk
> 2.  The disk controller places sectors at the addresses you give it, 
> at the time you give them
> 3.  Adjacent sector addresses given to the disk controller represent 
> adjacent physical addresses on disk
>
> All three of these assumptions are false for today's disk drives.  To 
> give a simple example, multi-platter disks break assumption 3.  
> Read/write coalescing done by the disk controller (buffering and 
> reordering disk commands) breaks assumption 2.   Flaw mapping (which 
> long ago moved from the OS kernel into the disk controller) breaks 
> assumptions 2 and 3.  Logical Block Addressing and the consequent 
> geometry translation inside the controller breaks assumption 1.
>
> As if that isn't enough, Panther automatically coalesces small and 
> medium sized files (smaller than 20MB) on journalled HFS+ disks when 
> they are opened.  Further, MacOSX caches file and directory data 
> extensively.
>
> The bottom line is this: there are multiple levels of translation 
> within the kernel I/O subsystem, PROM, the disk controller, and the 
> hard disk itself.  The cylinder/head/sector numbers that people are 
> trying to optimize with defragmentation long ago stopped having any 
> real relationship to the actual drive characteristics.  MacOS X 
> software that does defragmentation is at worst a fraud (like the 
> Syncronys "RAM doubler" of a few years ago) and at best an unnecessary 
> holdover from the days of MacOS 9 and earlier.
>
> Apple itself says, disk de-fragmentation is "probably not required if 
> you use MacOS X"  and "there is little benefit to defragmenting."
>
> So far no one claiming that defragmentation is useful has actually 
> produced any data to support their position.  They just have 
> "feelings" that they "know".  I invite anyone who believes that disk 
> defragmentation does anything measurable to affect performance, to 
> benchmark a program before and after defragmentation under MacOS 10.3 
> and send me the data and results.  If I can reproduce results showing 
> defragmentation is helpful I will gladly eat these words.  That won't 
> happen because manual defragmenting does nothing measurably useful 
> under MacOS X 10.3 on HFS+.
>
>     Peter
>
>

I am still on 10.2.8   Nevertheless most of what you say is true.
  But experience shows that contiguous free space is optimal for media 
capture.

And absolutely your OS is on one end of the disk and the updates on the 
other and deleted files become empty useless holes that can be 
condensed  and like files placed in adjacent locations for even faster 
location, and more free open space.
  10.3 may change all of that. I don't know.
I have benchmarked with Xbench. It shows improvement.
I could turn journalingg on. Is that a good thing?
Jim