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

[James Asherman]

On Wednesday, December 31, 2003, at 12:53  PM, James Asherman wrote:

>
> 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
>
>

By the way I do in fact assume that the map shown by Speed disk for OSX 
is accurate.