Disk defragmenter in Linux

[David L. Gehrt]

<snip>

> >>However, still the question remains. If Linux ext3 doesn't need
> >>defragmenter, and able to defrag itself, what is the process name?
> >>And when does it run?  Can I see it in action? Is there an utility
> >>to see on what percentage my current defragmentation? I tried fschk
> >>but no luck

Linux does NOT need a defrager.  There is an argument to be me  that on a
LINUX system with many processes accessing a pretty dynamic file system
a bit of fragmentation can help throughput.  Take squint at:

http://www.salmar.com/pipermail/wftl-lug/2002-March/000603.html

I have run large active servers with dynamic file systems that ran Linux
for years rebooting  just to up date the OS, with  never doing more file
system  maintenance  beyond  removing  file  or  moving  them  to  other
partitions.  In  my early UNIX  days the BSD  Fast File System  used 10%
free space on  its file systems.  I note that  modern Linux file systems
are created  with 5% of free  space.  I think  that is a bit  tight even
with improvements in design. You can check free space in the values from
a df of your file systems.  The file system free space is

free space = total blocks - (used + available)

That is why you can see a file system at more than a 100% utilization.

> > The opinion that EXT2 doesn't need defragmenting is based on only a
> > filesystem-level view of the problem, and doesn't consider data read and
> > write performance.  EXT2 does make an effort to keep data only a short seek
> > away ("clustered").  With this clustering, the filesystem operations of
> > adding, removing, extending, and shortening files are not much affected by
> > fragmentation.

I do not understand this comment  as disk I/O is largely about what file
system  designs are  about.   Integrity, and  reliability are  important
considerations true enough, but if  a Linux system is servicing numerous
client processes it is receiving requests to read or write data randomly
around the disk.   With disk read-ahead,and disk address  sorting a well
designed  driver accessing  a Linux  file  system does  not notice  file
fragmentation. The fragmentation is really an issue higher up in the OS.
That part  of the file system  code which deals with  the allocations of
inodes  and data blocks  (and in  file systems  that support  them, file
system  fragments). Things can  get really  ugly here  while at  a lower
lever things tend to perk along.

File systems that support "file system fragments" use large "file system
blocks" say  4K which is the basic  disk I/O size, but  allocate data by
the fragment 1K  or 2k.  These are design issues one  of the benefits of
this design  is an aid to clustering  of data with in  a single physical
disk I/O operation and makes an accommodation to file systems with large
files measured in file system blocks and smaller files for which a small
number of fragments is appropriate.   It does complicate the file system
code, some.

Actually the Linux EXT[23] file system structures contain a fragment
size, but the fragment size is the same as the block size.

<snip>\

> > When you have only 2% free, it's just about certain that the free space is
> > a long way away from the rest of the data in a file.  Just deleting to get
> > 20% free would probably have fixed your problem.
> 
> Absolutely. Running with just that much free on a Linux system is
> insanity, anyway. I'd be afraid of a system lockup.

As I said above  I am not sure that even 5% is  enough free space, 2% is
clearly too little.

dlg