File Fragmentation 7082

Peter T. Breuer Well some buffering, including read-ahead and write-behind (and therefore, reordering of actual hardware transfers to and from the disk platters) is done in some hardware out there. This is certainly true of my Maxtor Atlas III Ultra-320 SCSI hard drives. But I do not believe Linux file systems can rely on them, since the manufacturers do not disclose their algorithms for doing this. But since there is an 8 Megabyte RAM in each hard drive, they certainly have the opportunity to notice if sequential blocks are being read and to read some extra ones just in case. Furthermore, they know the read size and the blocks requested, and if they are all on the same cylinder, they can read starting at any convenient boundary and get them all in one rotation without waiting for the start of the bunch. E.g., if blocks 0,1,2,3,4,5,6,7 are all on one cylinder and a request for all of them comes in, and the head is just about to get to block 4, it will read 4,5,6,7,0,1,2,3 into the RAM buffer and then send them out in the requested order to the computer. In fact, if the computer requested just block 3, it would probably read the entire track or cylinder into its buffer just in case (low cost) the computer subsequently asked for them. This last would probably be of less use in a fragmented file system than one where files were stored contiguoously if there were only one program doing IO on the computer, but Linux tends not to do things that way as Peter has pointed out.

I can see the performance difference when running the DB2 dbms, where I have the option of using raw file systems where DB2 (pre-)allocates the space contiguously, and Linux file systems, where Linux allocates the space. But this only when the machine is doing essentially no other IO to disk and recall that DB2 is usually doing IO in blocks of 32 * 4096 bytes at a time, where seeking is very small in the raw IO case. This is not typical of general use multiprogramming machines.

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 07:40:00 up 9 days, 18:10, 4 users, load average: 4.10, 4.12, 4.14