On Tue, Aug 28, 2012 at 1:51 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> 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@xxxxxxxxx
>> <mailto:ranto.boris@xxxxxxxxx>>
>> ---
|