On 9/5/12 7:31 PM, Dave Chinner wrote:
> On Tue, Aug 28, 2012 at 02:59:42PM +0200, 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.
>> This test case hits 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).
>
> The LVM problem is incidental - if there's a problem with LVM
> devices then xfs_db should show the same problem, as should all
> other xfs_admin commands that use xfs_db. Hence I don't think that
> there is any point in mentioning it here.
I agree. And FWIW, though I tried to bisect my way to the root cause,
in the end I realized that upstream it's no longer a problem, so TBH
I stopped looking ...
...
>> +mkdir -p $dir
>> +touch $dir/{16,32}less
>
> "less" is a weird filename suffix. What's it mean? Why not just
> something standard like "test"?
16 or less (fewer) bits, 32 or less bits.
...
>> +# Now, we can examine the file systems with xfs_db
>> +# These two should report the same values
>> +echo "These two values of 16bit project quota ids shall be the same"
>
> No need to output this into the out file. The comment says it all,
> and we don't need the text in the output file to test for test
> failure.
Although the comments don't end up in the output file; if it fails with an out file diff like:
@blah,blah
core.projid_lo = 24853
core.projid_hi = 32401
core.projid_lo = 24853
-core.projid_hi = 32401
+core.projid_hi = 0
core.projid_lo = 24853
core.projid_hi = 32401
it's sometimes tedious to work your way back to where the numbers came from and what was being tested at the time; IOW comment-style landmarks in the output file like this are sometimes helpful, in my experience.
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
