From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: 253: test the metadump functionality of xfs_db
Date: Thu, 28 Apr 2011 12:19:48 +1000 [thread overview]
Message-ID: <20110428021948.GO12436@dastard> (raw)
In-Reply-To: <01d934eed0de0a992f3f8d6d609fa32d7e966b04.1303422281.git.aelder@sgi.com>
On Thu, Apr 21, 2011 at 04:44:45PM -0500, Alex Elder wrote:
> This patch creates a test that exercises xfs_metadump, with a focus
> on its obfuscation of names. It was created to verify fixes that
> avoided a hang condition when running "xfs_metadump" on a directory
> containing files having particular bit patterns in their name.
> Arkadiusz Miśkiewicz first reported seeing this while attempting
> to create a metadump for a filesystem containing a file named
> "R\323\257NE".
>
> For now this script checks the following (using only filenames, not
> attributes):
> - that short names (4 characters or less) aren't obfuscated
> - that long names get obfuscated
> - that (long) directory names get obfuscated
> - that names that are known to produce bit patterns that lead
> to invalid path components still generate obfuscated names
> (this could previously lead to a hang)
> - that many names of the same length can still generate new
> obfuscated names (this could previously lead to a hang)
> - that neither "lost+found" nor orphaned files stored in it ge
> obfuscated
>
> Right now there are two sets of "ls" commands executed (one before
> and one after obfuscation). This produces repeatable results for
> me on one filesystem, but on a different filesystem I expect the
> inode numbers to change (and random number generation might change
> the output too). I'm interested in suggestions on how to filter
> the output so the results can be verified. If nothing else, the
> test serves its purpose if I simply comment out those commands,
> and will do that if there's not a better suggstion.
Don't put the listing in the golden output - just put it in
$seq.full. That way if the test fails, the output is still there for
analysis.
Otherwise looks good.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-04-28 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 21:44 [PATCH] xfstests: 253: test the metadump functionality of xfs_db Alex Elder
2011-04-28 2:19 ` Dave Chinner [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-02-18 20:26 Alex Elder
2011-02-22 22:13 ` Alex Elder
2011-03-22 17:35 ` Alex Elder
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=20110428021948.GO12436@dastard \
--to=david@fromorbit.com \
--cc=aelder@sgi.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.