Defrag.

[AragonX]

<quote who="Dave Mitchell">
> Fragmentation, in the Windows sense, is where one file is stored as lots
> of small blocks spread all over the disk. Accessing the whole file becomes
> very slow.
>
> Fragmentation, in the UNIX fsck sense, is the percentage of big blocks (eg
> 8k) that have been split into small (eg 1K) subblocks to allow for the
> small
> chunk of data at the end of a file to be stored efficiently. For example,
> a file that is 18K in size will use two 8K blocks plus a 2K chunk of an
> 8K block that has been split. Fragmentation is this sense is harmless,
> and just indicates that the OS isn't wasting disk space. Or to put it
> another way, if you filled your disk with 1k files, fragmentation would
> be reported as 100%.
>
> (Well, that's the case with traditional UNIX filesystems like UFS;
> I should imagine xfs and raiserfs do things differently).

So what if you have the same 18k file that is stored as you said, in 2 8k
blocks and then one 2k chunk.  Now you add more files to the system.  Next
you add another 18k to the first file the next day.  Continue for a month.
 You would have something that looks like this right:


11111111  11111111  11222---  22222222  22222222  3333333-  ->
--------  --------  --------  --------  --------  -------
1 - 18k
2 - 19k
3 - 7k

I'm just guessing this is how the data would be written to disk.  I don't
really know.  So on to day 2 when I add 18k to file 1, the data would be
arranged on the drive platter as so?

11111111  11111111  11222---  22222222  22222222  3333333-  ->
11111111  11111111  11------

So I'm still getting fragmentation, just not nearly as bad as it is on a
FAT or NTFS machine correct?

I'm just trying to understand.  I've heard the argument that "Linux does
not  have any fragmentation to worry about".  I just don't see how that is
possible on a desktop machine where lots of little files are modified
frequently.