xfs_repair was leaving lost+found directory with a wrong link count when a
cleaned inode was re-used to create lost+found. This test case confirm that,
after xfs_repair is executed, the lost+found inode is left in a consistent
state.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
This is a btrfs specific scratch test checking the backref walker. It
creates a file system with compressed and uncompressed data extents, picks
files randomly and uses filefrag to get their extents. It then asks the
btrfs utility (inspect-internal) to do the backref resolving from fs-logical
address (the one filefrag calls "physical") back to the inode number and
file-logical offset, verifying the result.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This test is for write-posix test. If writing a file when the disk is almost
full, the posix wants the call to write as much as possible but not none.
quote the POSIX:
If a write() requests that more bytes be written than there is room for
(for example, [XSI] [Option Start] the process' file size limit or
[Option End] the physical end of a medium), only as many bytes as there
is room for shall be written. For example, suppose there is space for 20
bytes more in a file before reaching a limit. A write of 512 bytes will
return 20. The next write of a non-zero number of bytes would give a
failure return (except as noted below).
Signed-off-by: Wu Bo <Wu.Bo@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This test is for preallocation test. If the disk is full, just with a prealloc
file has some free space that prealloc early. We need to check whether the write
to the free space is success or not.
Signed-off-by: Wu Bo <Wu.Bo@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This test is a stress test. It creates a set of threads for coping small files
into disk. I use a 2G disk for test, the ENOSPC arises usually but the disk is
not full under kenerl 3.0 with intel64.
Signed-off-by: Wu Bo <Wu.Bo@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Implement the multi-stream placeholder tests 059 and 060. The comments
imply that these tests existed on IRIX, but I was unable to find them.
Test 059 does a simple 4-way dump and restore. Test 060 does a 4-way
dump, then restores each dump file individually (in a cumulative
fashion).
The tests are skipped if the installed xfsdump does not support
multi-stream output.
Reviewed-by: Alex Elder <aelder@sgi.com>
Signed-off-by: Bill Kendall <wkendall@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
- Same as 264 but with quota enabled.
- IO performed from $qa_user user
- fsstress granted with CAP_CHOWN capability.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
During stress testing we want to cover as much code paths as possible
fsstress is very good for this purpose. But it has expandable nature
(disk usage almost continually grow). So once it goes in no ENOSPC
condition it will be where till the end. But by running 'dd' writers
in parallel we can regularly trigger ENOSPC but only for a limited
periods of time because each time it opens the same file with O_TRUNC.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch adds a couple of tests for xfsdump when multiple media files
are used. 267 tests the case where a file is split across multiple media
files, and 268 tests the case where a file ends on one media file and
the next media file starts on another file. These tests use a small
media file size (xfsdump -d) so that they don't rely on having to hit
end-of-tape.
Signed-off-by: Bill Kendall <wkendall@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>