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.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
The specific set of extent sizes allocated to a file is not always
deterministic. In particular, sometimes a range of unwritten blocks
is covered by a single extent, while in other cases it might be
represented by multiple consecutive unwritten extents. This can
result in spurious errors being reported in tests that check file
extent maps.
Add a filter that finds adjacent extents in what gets produced for
fiemap and bmap output and coalesces them as if all consective
extents of the same time were really just one extent. (Note that
as implemented here this applies to all extent types, not just
unwritten extents.)
Update the golden output for test 242 to reflect the change.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
By convention all of the tests in the xfstests suite have mode 0755.
A few have recently committed without the execute bit set.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Bill Kendall's latest update to xfsdump dropped a line of output
that served no real purpose. This change updates the golden output
for the two tests that included that line of output.
Updated to filter out that line from dump output also, so old
versions of the code will still produce the same output (suggested
by Dave Chinner).
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Eliminate build warnings reported on files located under
dmapi/src/suite2/src/.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Eliminate build warnings reported on files located under
dmapi/src/suite1/cmd/ (third of three).
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Eliminate build warnings reported on files located under
dmapi/src/suite1/cmd/ (second of three).
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Eliminate build warnings reported on files located under
dmapi/src/suite1/cmd/ (first of three).
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Eliminate build warnings reported on files located under these
subdirectories:
dmapi/src/common/cmd/
dmapi/src/common/lib/
dmapi/src/sample_hsm/
dmapi/src/simple/
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Move the major test meat of 242 into common.punch, and reuse it for
a new testcase the exercises the new fallocate implementation
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Once we get one short write, we know the test has failed. We don't
ened to keep writing and getting more short writes and spewing
thousands of errors to the console.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Recent kernels allow more than 40 nested symlinks, so up the limit
to still reproduce a failure.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
219 and 235 were failing on ext3 with selinux, because the extra
xattrs upped the quota usage.
Do the same trick we've used in the past to mount with an selinux
global context when doing quota tests.
Note the gross hack for remount,ro, though.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Test 249 was appearing to pass on ext4, but it wasn't really
exercising the test due to lack of "-F" in the xfs_io arguments.
Without -F the files were created (oddly enough); neither pwrite
nor sendfile were executed, and the diff of the two (empty)
files passed, resulting in a passed test without testing anything.
So add the -F, capture the output, and test the result of each
xfs_io invocation.
Also, when it fails, the diff output is huge. Make diff silent,
but describe the diff failure and exit.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
The "dmapi" subtree was developed separate from and sort of wedged
into the rest of the "xfstests" code. As a result, it has a lot of
build infrastructure that's just different from the unified way used
for everything else.
This patch changes all that, making the "dmapi" subtree be a more
normal component of "xfstests" with respect to its build process.
This involves removing all the cruft needed and used by the dmapi
"configure" script, and replacing each "Makefile.am" file with a
proper "Makefile" that includes a simple set of rules that are
compatible with the broader "xfstests" build.
The result is a much cleaner, consistent build. It also deletes
a considerable amount of code.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Make it so "make depend" is a generic target, like "make clean".
Each Makefile has a "depend" target that indicates whether making
dependencies means creating ".dep" or creating ".ltdep" (or, I
suppose, both, though none do that right now). Both files get
created even if there are no CFILES to scan (to ensure the target
up-to-date). The "default" target now depends on "depend" (there is
no "ltdepend" any more).
Remove the "depend" and "ltdepend" definitions from the "buildrules"
file; only the actual generated files (".dep" and ".ltdep") remain
as generic targets. The "depend' target is still defined as phony.
Do a shell trick when expanding the value of CFILES, to avoid a
problem that occurs if it is created by "make" by concatentating two
empty strings. The problem was that in that case CFILES will
contain a space, and that wasn't getting treated as empty as
desired.
Make the rule for tool/lib dependencies more generic, to reflect the
general desire that "lib" subdirectories need to be built before
things in the "tool" subdirectories.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Change the top-level Makefile, to make it clearer just what makes
what, and what depends on what:
- Separate the rules for "configure" and "include/builddefs" into
two parts, each of which generate one of the files
- Get rid of the rule for include/config.h, and group it with the
one for include/builddefs (the same command creates both files)
Having done this, we find that having both "include/builddefs" and
"include/config.h" as dependencies for the default target results in
a parallel invocation of "make" spawning two concurrent attempts to
do the configure step--and that doesn't work.
Creating one of those two will result in the other getting created,
so just list one of them as a dependency for the default rule.
A couple of other small fixes:
- Get rid of the "new", "remake" and "check" dependencies for the
default rule, which serv no purpose
- Use the $(Q) convention in a few missed spots
- Stop a DMAPI-only comment from getting echoed on default build
- Delete the "
This updated version pulls in the content of a patch previously
posted separately to fix the problem with parallel builds.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
This patch fixes a few build warnings. I have built the code using
i386, x86_64, and ia64 architectures and each has ends up with
complaints of one sort or anther. This gets rid of all of them
*except* those reported by files under the "ltp" (Linux Test
Project) sub-tree.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Tests 127 and 134 leave temp files around when they complete.
Fix (or enable) their cleanup functions to remedy this.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Nfs tries to umount $testdir in _cleanup_testdir function. Tests 126
and 135 call the function from directory $SCRATCH_MNT that is equal
to $testdir (at least for nfs). The umount will therefore fail,
causing the test to fail due to the output mismatch.
Test 126 also does double a umount thanks to the call to _cleanup
before exit and the trap command. So remove the unnecessary call of
the _cleanup function before exit.
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Add random runtime fallocate calls to fsx (vs. the existing
preallocate file at start of run).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Running the fiemap-tester with a unique random seed each time
may uncover some things missed by always using the default.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Chris Mason pointed out that some filesystems were not doing
the right thing on fiemap, in the face of delalloc extents.
Because test 225 ran with FIEMAP_FLAG_SYNC only, this didn't
get caught. Add a runtime option, and run it both ways.
Note that this changes defaults for fiemap-tester, so that
it no longer calls with FIEMAP_FLAG_SYNC by default, and
a new option -S is added to do so.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
If the fiemap call returns fewer extents than asked for,
the fiemap tester gets confused. If this happens, advance,
and call fiemap again for the next offset.
XFS exposed this because if a file is all-delalloc, it was
only returning 1 mapped extent (this is probably also a buglet).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Just a hint for those perusing logs that the ensuing shutdown is
intentional...
Feb 16 17:06:17 hostname godown: xfstests-induced forced shutdown of /mnt/scratch
Feb 16 17:06:17 hostname kernel: Filesystem "sdb3": xfs_log_force: error 5 returned.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Alex Elder
Josef Bacik
Dave Chinner
Christoph Hellwig
Eric Sandeen
Boris Ranto