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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.