[PATCH] xfstests: Add test case to test xfs projid32bit functionality a bit more extensively.

[Boris Ranto]

On Tue, Aug 28, 2012 at 1:51 AM, Eric Sandeen <sandeen at sandeen.net> wrote:
> On 8/27/12 5:04 AM, Boris Ranto wrote:
>>  The test covers several areas including enabling projid32bit functionality dynamically by xfs_admin, dumping, restoring, quota reporting and xfs_db projid values reporting.
>>  At the time of creation, the test hit two bugs: one for broken xfsdump/xfsrestore functionality and one for enabling projid32bit functionality with xfs_admin on a LVM device (SCRATCH_DEV must be an LVM device to hit this).
>
> FWIW, with a bit of investigation I think the lvm behavior may be an lvm bug.  IOW this should never happen;
> somehow buffered IO to the LVM device seems to be getting lost:
>
> # xfs_db -r -c version  /dev/mapper/vg-01-xfscratch
> versionnum [0xb4a4+0x8a] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT
>
> # echo 3 > /proc/sys/vm/drop_caches
>
> # xfs_db -r -c version  /dev/mapper/vg-01-xfscratch
> versionnum [0xb4e4+0xa] = V4,NLINK,QUOTA,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT
>
> But I guess the test itself doesn't explicitly require lvm, so no big deal there.
>
> What is the point of using loopback during dump & restore?  Why not just dump to $tmp
> and restore to $SCRATCH_DEV, either after a fresh mkfs, or to a subdir of the existing
> filesystem?
>
> I get nervous about the loopback handling complexity....
>

I just wanted to keep the original data and compare them with diff.
The subdirectory dump will work fine, as well. I'll post the reworked
version of the patch, soon.

Boris

> -Eric
>
>> Signed-off-by: Boris Ranto <ranto.boris at gmail.com <mailto:ranto.boris at gmail.com>>
>> ---