The defragmentation support in ext4 is still a work in progress. The current e4defrag essentially creates a new file that is the same size is the existing file, checks to see if it is less fragmented, and if so, invokes a ioctl which atomically substitutes the blocks from the new file to the new file, while preserving the contents of the file.
It however, doesn't have any concept trying to make the file system better from a global point of view, in terms of (a) making sure the free space is not fragmented so as to avoid the file system becoming fragmented again in the near future, and (b) using a global file system wide strategy to move files aside to "make room" for a large fragmented file. It also hasn't undergone enough testing that it's really a good idea to recommend its use in production settings.
There are kernel patches that will provide more functionality to enable a more intelligent userspace program, but (a) those patches still need to be evaluated, so they are not yet in mainline, (b) the enhancements to improve e4defrag to take advange of these new ioctls have not yet been written, and that work is non-trivial, and (c) there is still work needed to improve ext4's base allocation algorithms to enable the current e4defrag to work more efficiently and to prevent fragmentation of the free space to avoid fragmentation problems on full filesystems in the first place.
I've been working on (c), and there are patches in the ext4 patch queue that address the last point. But quite frankly, e4defrag work is somewhat lower priority compared to another things that that we have been working on as of late, such as, integrating the 64-bit block number support into e2fsrpogs' mainline, fixing direct I/O into preallocated blocks, and so on. Some of these items are less important to Ubuntu, as a desktop distribution but they are important to the enterprise server companies and distributions that have been donating engineering effort to ext4. If Canonical is interested in pushing ext4 defragmentation support and contributing some real kernel and userspace engineering support to accelerate this project, please contact me directly. Otherwise it will keep chugging along, but it will be a while before it is really something I would recommend for end-user use.
The defragmentation support in ext4 is still a work in progress. The current e4defrag essentially creates a new file that is the same size is the existing file, checks to see if it is less fragmented, and if so, invokes a ioctl which atomically substitutes the blocks from the new file to the new file, while preserving the contents of the file.
It however, doesn't have any concept trying to make the file system better from a global point of view, in terms of (a) making sure the free space is not fragmented so as to avoid the file system becoming fragmented again in the near future, and (b) using a global file system wide strategy to move files aside to "make room" for a large fragmented file. It also hasn't undergone enough testing that it's really a good idea to recommend its use in production settings.
There are kernel patches that will provide more functionality to enable a more intelligent userspace program, but (a) those patches still need to be evaluated, so they are not yet in mainline, (b) the enhancements to improve e4defrag to take advange of these new ioctls have not yet been written, and that work is non-trivial, and (c) there is still work needed to improve ext4's base allocation algorithms to enable the current e4defrag to work more efficiently and to prevent fragmentation of the free space to avoid fragmentation problems on full filesystems in the first place.
I've been working on (c), and there are patches in the ext4 patch queue that address the last point. But quite frankly, e4defrag work is somewhat lower priority compared to another things that that we have been working on as of late, such as, integrating the 64-bit block number support into e2fsrpogs' mainline, fixing direct I/O into preallocated blocks, and so on. Some of these items are less important to Ubuntu, as a desktop distribution but they are important to the enterprise server companies and distributions that have been donating engineering effort to ext4. If Canonical is interested in pushing ext4 defragmentation support and contributing some real kernel and userspace engineering support to accelerate this project, please contact me directly. Otherwise it will keep chugging along, but it will be a while before it is really something I would recommend for end-user use.