> Actually, the fact that Linux drives don't need regular defragging has > nothing to do with the file system. Well, what is that reason? I know that ext4 offers 'extents' and that reduces fragmentation, but I don't see any other reason why the ext* family of filesystems are more immune to fragmentation than other filesystems. It should still be possible to fragment a large file if, for example, you opened a file that covered more than 3 segments and appended data to the middle of it. The effect should be that another block is allocated and added to the inode-list for that file to hold the new data that you've added, with that block chaining to block 3. N.B. Before change was made: [file-> [BLOCK1]->[BLOCK2]->[BLOCK3]] The file is contiguous on disk. After change was made: [file-> [BLOCK1]->[BLOCK2]->[BLOCK242]->[BLOCK3]] The file is fragmented. Depending on the size of the file, the size of the blocks, and the location of the edit, almost all files can become fragmented. Another example: Creating a file of initial size 0. [file-> [BLOCKN]] Before any changes are written to the file, some other files are modified. This is a typical scenario on a multiprocessing system. These other files allocate blocks N+1 up to block N+10 for their own use according to scenario 1. Make a change to the file: [file-> [BLOCKN]->[BLOCKN+11]] The nearest free block was block N+11, which is still 10 blocks away. Now these differences are small. However, suppose that a block was 256KiB in size. This means that each block pair can be read in one cycle of the hard-drive reader (they typically read 512 KiB at a time) It would take more time to read the file if the hard-drive must read the first block pair [512 KiB], seek (256 * 10) bytes forward, and read the next block, but only get 1 block out of that read. (Unoptimal read for hard-drive block size) Here is how extents work to reduce the risk of fragmentation: Allocation of a file: [file-> [BLOCKN]->...->[BLOCKN+M]] The file allocates all blocks contiguously on the disk from N to M. This is great for large files, because you can then use those blocks freely to grow your file (i.e. append) as needed. As long as you reserved the correct size, appending does not lead to fragmentation. However, the 'fragmentation due to appending in the middle of a file' problem still exists. I am by no means an expert in filesystems, but I know a little bit about their inner workings. I hope that you found my explanation informative. sea -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
