[Sussex] Why Linux doesn't need defrag

[Steven Dobson]

Hi

On Thu, 2006-08-17 at 13:59 +0100, Alan Pope wrote:
> On Thu, Aug 17, 2006 at 05:29:01AM -0600, linux at oneandoneis2.org wrote:
> > http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
> > 
> > I *think* I got the basic details right, but I'm not absolutely sure,  
> > so any feedback would be appreciated.
> > 
> 
> I don't agree with:-
> 
> "Linux pays attention to the hard drive's actual geometry, and would not
> split this file so badly."
> 
> I was under the impression that Linux has no clue about the real physical
> geometry of the disk because that's abstracted by the circuitry on the
> drive/controller. As far as Linux is concerned it's a large number of
> sectors, it has no clue *really* how they're arranged.
> 
> That's my understanding anyway.

I believe that you are both right!

I was told in the old days there was code in UFS (and may still be) to
try and work out which sectors where going to be approaching the heads
when the data got to the drive's buffer.  This was to minimise the time
lag between data being send to the device and it actually being written
to the magnetic media.  Remember in those days memory was very expensive
and so drives would have only a few sectors worth of memory.

These days disks have more buffer memory and computing power than the
Unix systems of old.  As a result they will re-order the write sequence
and will even take care of bad sectors automaticlly, remapping them to
spare areas of the magnetic surface.  It make no sense today for the
kernel to work out where data should be phsically placed.  The drives
themselves are much better at this.

However some file system code is there for "layout".  FreeBSD's FFS
works out the best location for the super blocks and ext2/3 does
something simular.

Also when writting a file the cylinders are checked to see how full they
are and how much data needs to be written for that file.  There is a
comprise to be made between fill cylinders with data from the same file
(which make big file access quicker) and placing multiple files accessed
at the same time with in the same cylinder (general responsiveness).  If
files are scatered all over the disk then moving the heads constantly is
going to kill file I/O.

Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20060817/bac01c87/attachment.pgp