<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