Prev: sock.c: potential null dereference
Next: [PATCH] ARCH: x86: fix coding style issues in video-vesa.c
From: Jeff Garzik on 7 Mar 2010 19:00
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(a)de.ibm.com>
> CCed: Akira Fujita<a-fujita(a)rs.jp.nec.com>

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! ;-)

Looking at Fedora rawhide, I do not see anything resembling e4defrag in
any of the RPM packages like e2fsprogs.

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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: sock.c: potential null dereference
Next: [PATCH] ARCH: x86: fix coding style issues in video-vesa.c