From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Boris Ranto <ranto.boris@gmail.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH v2] xfstests: Add test case to test xfs projid32bit functionality a bit more extensively.
Date: Wed, 05 Sep 2012 19:40:38 -0500 [thread overview]
Message-ID: <5047F106.4050905@sandeen.net> (raw)
In-Reply-To: <20120906003150.GM15292@dastard>
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-09-06 0:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 12:59 [PATCH v2] xfstests: Add test case to test xfs projid32bit functionality a bit more extensively Boris Ranto
2012-09-06 0:31 ` Dave Chinner
2012-09-06 0:40 ` Eric Sandeen [this message]
2012-09-06 12:58 ` Boris Ranto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5047F106.4050905@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.com \
--cc=ranto.boris@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox