Add a test for xfsdump -D, which skips unchanged directories during
an incremental backup. After doing an initial backup, a new file is
added to one directory (to verify that changed directories are
backed up) and several files are appended to. Then an incremental
backup is done with -D set. The test verifies the original and
restored filesystems match after applying the base and incremental
backups, and that the incremental restore output indicates that only
the one changed directory was backed up.
Signed-off-by: Bill Kendall <wkendall@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This will verify the various raid features in btrfs and device
replacement functionality.
Signed-off-by: Anand Jain <Anand.Jain@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Create snapshots in various ways, modify the data around the block and
file boundaries and verify the data integrity.
Signed-off-by: Anand Jain <Anand.Jain@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This effectively reverts
xfstests: add mapped write fsx operations to 091
and adds a new test case for it. It tests something slightly
different, and regressions in existing tests due to new features
are pretty nasty in a test suite.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
This test checks the project quota values reported by the quota "df"
and "report" subcommands to ensure they match what they should be.
There was a bug (fixed by xfsprogs commit 7cb2d41b) where the values
reported were double what they should have been.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
There is code in libxcmd that sets up a table of mount points and
directories that may be subject to quota enforcement. If any entry
in the mount table (/proc/self/mounts) is inaccessible or has any
other problems, libxcmd exits.
We have encountered mtab entries that appear to be artifacts from
autoumount that, when parsed for getmntent(), return paths in the
mnt_fsname field that do not exist. Such entries tend to have the
text " (deleted)" appended to a legitimate pathname (although the
space character is expanded to \040, as documented in getmntent(3)).
The xfs_quota command supports the ability to specify an alternate
mount table file, so this test makes use of that feature to exercise
the problem. The test simply uses xfs_quota to print the current
set of paths, providing an alternate mount table file. First it
does so with a copy of the current mount table (which is assumed
OK), then an extra bogus entry (very much like what has been seen
in the wild) is appended to the mount table, and runs the xfs_quota
command again.
It does this with no mount options, as well as with user, group, and
project quota options enabled. (Given the current state of the code
however, only one of these is required.)
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
This test suppose to validate that file systems are using the fitrim
arguments right. It checks that the fstrim returns EINVAl in case that
the start of the range is beyond the end of the file system, and also
that the fstrim works without an error if the length of the range is
bigger than the file system (it should be truncated to the file system
length automatically within the fitrim implementation).
This test should also catch common problem with overflow of start+len.
Some file systems (ext4,xfs) had overflow problems in the past so there
is a specific test for it (for ext4 and xfs) as well as generic test for
other file systems, but it would be nice if other fs can add their
specific checks if this problem does apply to them as well.
[Added call to _require_math. -Alex]
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
mkfs.xfs failed to create xfs filesystems with 4 TB minus few bytes due
to round up error in mkfs.xfs code.
This test case is a regression test for the fs creation problem.
I've tested the test case with mkfs.xfs patch (in the form posted by
Eric Sandeen) and the test passed (and therefore the patch fixed the
issue for me).
I'm not sure whether bash guarantees at least 64-bit precision
values in its arithmetic operations. Therefore the values are
computed in advance.
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
ext2/3/4 was sign-extending times before the timestamp when read
from disk on 64-bit systems. This was fixed by:
4d7bf11d649c72621ca31b8ea12b9c94af380e63
ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems
Here's a generic regression test.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
The test checks if no duplicate d_off values are returned and that
those values are seekable to the right inodes.
[Fixed typo "histoty" -> "history". -Alex]
Signed-off-by: Gražvydas Ignotas <notasas@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
This patch adds a new test 256 that tests that a hole can be punched
even when the disk is full. Reserved blocks should be used to allow
a punch hole to proceed even when there is not enough blocks to
further fragment the file. To test this, the file system is
fragmented by punching holes in regular intervals and filling the
file system between punches. This will eventually force the file
system to use reserved blocks to proceed with the punch hole
operation.
The work in this patch is a continuation from a previous patch set
that has been partially accepted.
Signed-off-by: Allison Henderson <achender@linux.vnet.ibm.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
This patch adds a new test 255 that tests fallocate punch hole,
but is for use by generic filesystems. It is similar to 252,
but uses a weaker fiemap filter that only displays the location
of the hole, and not the extent types.
Signed-off-by: Allison Henderson <achender@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This test just runs through all of the basic btrfs commands that manipulate our
subvolume stuff. It creates a snapshot, a subvolume, sets the subvolume as a
default, lists the volumes and deletes the snapshot. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>
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>
FITRIM ioctl is used on a mounted filesystem to discard (or "trim")
blocks which are not in use by the filesystem. This is useful for
solid-state drives (SSDs) and thinly-provi-sioned storage. This test
helps to verify filesystem FITRIM implementation to assure that it
does not corrupts data.
This test creates checksums of all files in xfstests directory and
run several processes which clear its working directory on SCRATCH_MNT,
then copy everything from xfstests into its working directory, create
list of files in working directory and its checksums and compare it with the
original list of checksums. Every process works in the loop so it repeat
remove->copy->check, while fstrim tool is running simultaneously.
Fstrim is just a helper tool which uses FITRIM ioctl to actually do the
filesystem discard.
I found this very useful because when the FITRIM is really buggy (thus
data-destroying) the 251 test will notice, because checksums will most
likely change.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
The problem was reprted here:
https://bugzilla.redhat.com/show_bug.cgi?id=626244
With the simple test case:
# mkfs.xfs -f -d agsize=16m,size=50g <dev>
# mount <dev> /mnt
# xfs_io -f -c 'resvsp 0 40G' /mnt/foo
Triggering the problem. Turn this into a new xfsqa test so that we
exercise the problem code and prevent future regressions.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We don't have any coverage of the splice functionality provided by
the kernel in xfstests. Add a simple test that uses the sendfile
operation built into xfs_io to copy a file ensure we at least
execute the code path in xfstests.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
A customer reported a problem:
If a process is using mmap to write to a file on an
ext4 filesystem while another process is using direct
I/O to write to the same file the first thread may
receive a SIGBUS during a page fault.
A SIGBUS occurs if the page fault tries to access a
page that is entirely beyond the end of the file but
in this test case that should not be happening.
Signed-off-by: Lachlan McIlroy <lmcilory@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Per Posix renames over non-empty directories should fail, but hfsplus used to
allow this (and corrupt the filesystem while doing so).
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Test 3 quota project setting id conditions:
- set 16bit project quota id -> should succeed
- set 32bit project quota id -> should succeed (with projid32bit
patch applied; fail otherwise)
- over 32bit project quota id -> should always fail
Updated by <aelder@sgi.com>:
- Shortened some long lines, including failure output
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Alex Elder <aelder@sgi.com>
Apply the prjquota check to the scratch device so that it doesn't fail,
and add the test to the auto and quick groups now that it works.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
As found by Theodore Ts'o:
If a 128K file is falloc'ed using the KEEP_SIZE flag, and then
write exactly 128K, the EOFBLOCK_FL doesn't get cleared correctly.
This is bad since it forces e2fsck to complain about that inode.
If you have a large number of inodes that are written with fallocate
using KEEP_SIZE, and then fill them up to their expected size,
e2fsck will potentially complain about a _huge_ number of inodes.
This would also cause a huge increase in the time taken by e2fsck
to complete its check.
Test scenarios covered:
1. Fallocating X bytes and writing Y (Y<X) (buffered and direct io)
2. Fallocating X bytes and writing Y (Y=X) (buffered and direct io)
3. Fallocating X bytes and writing Y (Y>X) (buffered and direct io)
These test cases exercise the normal and edge case conditions using
falloc (and KEEP_SIZE).
Ref: http://thread.gmane.org/gmane.comp.file-systems.ext4/20682
Signed-off-by: Akshay Lal <alal@google.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Bill Kendall
Anand Jain
Christoph Hellwig
Alex Elder
Lukas Czerner
Boris Ranto
Eric Sandeen
Gražvydas Ignotas
Allison Henderson
Josef Bacik
Dave Chinner
Zhong, Xin
Lachlan McIlroy
Christoph Hellwig
Arkadiusz Mi?kiewicz
Akshay Lal