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>> >> --- _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
