Why don't ext2/3/4 need to be defragmented? Is there no fragmentation at all?
2 Answers
Modern filesystems, particularly those designed to be efficient in multi-user and/or multi-tasking use cases, do a good fairly job of not fragmenting data until filesystems become near to full (there is no exact figure for where the "near to full" mark is as it depends on how large the filesystem is, the distribution of file sizes and what your access patterns are - figures between 85% and 95% are commonly quoted) or the pattern of file creations and writes is unusual or the filesystem is very old so has seen a lot of "action". This includes ext2/3/4, reiser, btrfs, NTFS, ZFS, and others.
There is currently no kernel-/filesystem- level way to defragment ext3 or 4 at the moment (see http://en.wikipedia.org/wiki/Ext3#Defragmentation for a little more info) though ext4 is planned to soon gain online defragmentation.
There are user-land tools (such as http://vleu.net/shake/ and others listed in that wikipedia article) that try defragment individual files or sets of files by copying/rewriting them - if there is a large enough block of free space this generally results in the file being given a contiguous block. This in no way guarantees files are near each other though so if you run shake over a pair of large files you migth find is results in the two files being defragmented themselves but not anywhere near each other on the disk. In a multi-user filesystem the locality of files to each other isn't often important (it is certainly less important then fragmentation of the files themselves) as the drive heads are flipping all over the place to serve different user's needs anyway and this drowns out the latency bonus that locality of reference between otherwise unfragmented files would give but on a mostly single user system it can give measurable benefits.
If you have a filesystem that has become badly fragmented over time and currently has a fair amount of free space then running something like shake over all its files could have the effet you are looking for. Another method would be to copy all the data to a new filesystem, remove the original, and then copy it back on again. This helps in much the same way shake does but may be quicker for larger amounts of data.
For small amounts of fragmentation, just don't worry about it. I know people who spend more time sat watching defragmentation progress bars than they'll ever save (due to more efficient disk access) in several lifetimes of normal operation!
- 1,414
- 9
- 10
-
is there any mechanism such as: files that often be used while booting is placed near each other to gain benefit of locality? so faster boot? – uray Sep 06 '10 at 17:00
-
1Not that I know of. You could use `ureadahead`, as recent Ubuntu builds do by default (see http://ubuntuforums.org/showthread.php?t=1434502 for more info), to achieve a similar effect. Some of the delay in the Linux boot sequence can be reduced by asking it to start services more concurrently where possible if your disro's boot setup supports this (set CONCURRENCY=shell in /etc/defaults/rc on Debian) and similar tweaks. To check you are making any difference with changes that you make use http://www.bootchart.org/ to show what happens before you tweak things compared to afterwards. – David Spillett Sep 06 '10 at 18:15
-
@uray, I have revived the long abandoned `e2defrag` and experimented with it to achieve such packing. You can find it at http://launchpad.net/e2defrag. – psusi Apr 03 '12 at 13:48
-
@David: I have no `/etc/defaults/rc` but do have `/etc/default/rcS` on debian 6 – ctrl-alt-delor Aug 15 '12 at 13:10
-
@psusi - Does this `e2defrag` now better support Ext3, better than `shake`? – Alex S Apr 14 '17 at 07:09
-
@AlexS, not sure what you could mean by that. It does support both ext3 and ext4. – psusi Apr 17 '17 at 15:02
-
@psusi - There's e4defrag for ext4, e2defrag for ext2, what would be the best option to defrag Ext3? There's http://vleu.net/shake/ and do e4 or e2 also do Ext3 better than Shake? – Alex S Apr 17 '17 at 16:22
There is not much fragmentation as long as the disk isn't filled too much (so don't fill a disk up too much if you can avoid it).
- 1,389
- 7
- 8