Jeff Garzik wrote:
> On 03/07/2010 03:32 PM, Christian Borntraeger wrote:
>> I have an x86_64 kernel with i386 userspace. e4defrag fails on the
>> EXT4_IOC_MOVE_EXT ioctl because it is not wired up for the compat
>> case. It seems that struct move_extent is compat save, only types
>> with fixed widths are used:
>> {
>> __u32 reserved; /* should be zero */
>> __u32 donor_fd; /* donor file descriptor */
>> __u64 orig_start; /* logical start offset in block for
>> orig */
>> __u64 donor_start; /* logical start offset in block for
>> donor */
>> __u64 len; /* block length to be moved */
>> __u64 moved_len; /* moved block length */
>> };
>>
>> Lets just wire up EXT4_IOC_MOVE_EXT for the compat case.
>>
>> Signed-off-by: Christian Borntraeger<borntraeger@xxxxxxxxxx>
>> CCed: Akira Fujita<a-fujita@xxxxxxxxxxxxx>
>
> I'm curious, what is the overall deployment status of ext4 defragging? I
> actually worked on this problem years ago[1], and am hopeful that I will
> see defragging in a Linux distribution sometime in my lifetime! ;-)
on ext4 you mean, I guess - you could use XFS if defragging is a high priority,
see xfs_fsr(8)
> Looking at Fedora rawhide, I do not see anything resembling e4defrag in
> any of the RPM packages like e2fsprogs.
I had it for a while, but with the various problems and general uneasiness
with the code so far, I took it back out lest people lose data to it.
-Eric
> Thanks to everyone working on this,
>
> Jeff
>
>
>
>
> [1] http://linux.yyz.us/misc/ext2meta.c
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
