migration to selinux + xfs_fsr oddity....

[Eric Sandeen <sandeen@sandeen.net>]

This came up in RH Bugzilla #498860, "xfs_fsr fails to complete"

The reporter had an existing xfs filesystem from another Linux OS, and
was using it under Fedora now.  He had some files for which xfs_fsr
bails out with EINVAL:

XFS_IOC_SWAPEXT failed: fragfile: Invalid argument

It's failing this check in xfs_swap_extents():

        /*
         * If the target has extended attributes, the tmp file
         * must also in order to ensure the correct data fork
         * format.
         */
        if ( XFS_IFORK_Q(ip) != XFS_IFORK_Q(tip) ) {
                error = XFS_ERROR(EINVAL);
                goto error0;
        }

because the original filesystem had no selinux xattrs, but the new/temp
file created during xfs_fsr got the selinux xattr, so failed this test.

It can be demonstrated like this on a machine w/ selinux:

# mkfs.xfs -dfile,name=fsfile,size=32m
# mkdir test
# mount -o loop,context="unconfined_u:object_r:user_tmp_t:s0" fsfile test
# for I in `seq 10 -1 0`; do  dd if=/dev/zero of=test/fragfile bs=4k count=1
seek=$I conv=notrunc oflag=sync; done
# umount test
# mount -o loop fsfile test
# xfs_fsr test/fragfile
XFS_IOC_SWAPEXT failed: fragfile: Invalid argument

I'm not sure if this is the sort of thing to maybe just caveat &
document, or try to work around ... somehow?  Maybe detect this case a
bit better and print something more helpful about what has gone wrong?

(As an aside ... looking at the above test and others related, and
thinking about a few random reports that xfs_fsr corrupted a file, I
can't help but think that maybe we are winding up with incompatible
formats for the original and donor inodes in some cases...)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs