To get reproducible results when testing incremental backups, files
contained in a backup should not have the same timestamp (at second
resolution) as the backup itself. If they do, those files will also
be included in the incremental backup, and this will likely cause
issues in the expected output of the test. This patch adds a sleep
to test 024 prior to doing the level 0 backup. The other incremental
tests already include similar delays.
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>
It is very hard to predict runtime for fsstress. In many cases it
is useful to give test to run a reasonable time, and then kill it.
But currently there is no reliable way to kill test without leaving
running children.
This patch add sanity cleanup logic which looks follow:
- On sigterm received by parent, it resend signal to it's children
- Wait for each child to terminates
- EXTRA_SANITY: Even if parent was killed by other signal, children
will be terminated with SIGKILL to preven staled children.
So now one can simply run fsstress like this:
./fsstress -p 1000 -n999999999 -d $TEST_DIR &
PID=$!
sleep 300
kill $PID
wait $PID
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Currently the only way to log fsstress's output is to redirect it's shared
stdout to pipe which is very painfull because:
1) Pipe writers are serialized via i_mutex so we waste cpu-cores power on stupid
sinchronization for loging purpose, instead of hunting real race conditions,
and bugs inside file system.
2) Usually output is corrupted due to luck of sychronization on shared stdout.
Since fsstress's children operate on independend paths, let's just open didicated
log file for each child and simply avoid useless sycnhronization.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Fsstress exec behaviour is not completely determinated in case of
low resources mode due to ENOMEM, ENOSPC, etc. In some places we
call stat(2). This information may be halpfull for future
investigations purposes. Let's dump stat info where possible.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
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>
SCRATCH_DEV takes single disk as the scratch place for testing. New
SCRATCH_DEV_POOL can used to specify multiple disks for the scratch
btrfs filesystem.
Using SCRATCH_DEV and or SCRATCH_DEV_POOL will follow the following logic.
btrfs FS OR any FS
SCRATCH_DEV_POOL is unset and SCRATCH_DEV is set
. test-case with _require_scratch_dev_pool will not run
. test-case without _require_scratch_dev_pool will run
SCRATCH_DEV_POOL is set and SCRATCH_DEV is unset
. test-case with _require_scratch_dev_pool
- runs only if FSTYP=btrfs
. test-case without _require_scratch_dev_pool will run using first
dev in the SCRATCH_DEV_POOL as a SCRATCH_DEV
- if FSTYP=btrfs it includes SCRATCH_DEV_POOL disks to the FS
- if FSTYP=non-btrfs SCRATCH_DEV_POOL is ignored
SCRATCH_DEV_POOL is set and SCRATCH_DEV is set
. reports error in the config
SCRATCH_DEV_POOL is unset and SCRATCH_DEV is unset
. no change
Signed-off-by: Anand Jain <Anand.Jain@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
snapshot data integrity test-case needs filesystem with random data.
Signed-off-by: Anand Jain <Anand.Jain@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
A clean checkout of xfstests followed by a build resulted in a long list
of untracked files. The current .gitignore ignores most binaries, but
the "dmapi" subdir was missed as were some binaries from the "src"
subdir.
Also ".libs" and ".ltdep" appear under a "dmapi" subdir, not just under
the top-level "libs" directory, so ignore those regardless of the
directory they are in.
Signed-off-by: Bill Kendall <wkendall@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add the release script used in the other XFS user space packages.
The version is set to 1.1.0, to differentiate it from the 1.0.0
version that was recorded in the VERSION file.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Before punching a hole in a file, TRIM_OFF_LEN() calls
TRIM_OFF_LEN() in order to make sure the offset and size
used are in a reasonable range. But currently the range
it's limited to is maxfilelen, which allows the offset
(and therefore offset + len) to be beyond EOF.
Later, do_punch_hole() ignores any request that starts beyond
EOF, so we might as well limit requests to the file size.
It appears that a hole punch request that starts within a
file but whose length extends beyond it is treated simply
as a hole punch up to EOF. So there's no harm in limiting
the end of a hole punch request to the file size either.
Therefore, use TRIM_OFF_LEN() to put both the the offset
and length of a request within the file size for hole
punch requests.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
A recent commit added a TRIM_OFF_LEN() macro in "ltp/fsx.c":
5843147e xfstests: fsx fallocate support is b0rked
A later commit fixed a problem with that macro:
c47d7a51 xfstests: fix modulo-by-zero error in fsx
There is an extra flag parameter in that macro that I didn't like
in either version. When looking at it the second time around I
concluded that there was no need for the flag after all.
Going back to the first commit, the code that TRIM_OFF_LEN()
replaced had one of two forms:
- For OP_READ and OP_MAP_READ:
if (file_size)
offset %= file_size;
else
offset = 0;
if (offset + size > file_size)
size = file_size - offset;
- For all other cases (except OP_TRUNCATE):
offset %= maxfilelen;
if (offset + size > maxfilelen)
size = maxfilelen - offset;
There's no harm in ensuring maxfilelen is non-zero (and doing so
is safer than what's done above). So both of the above can be
generalized this way:
if (SIZE_LIMIT)
offset %= SIZE_LIMIT;
else
offset = 0;
if (offset + size > SIZE_LIMIT)
size = SIZE_LIMIT - offset;
In other words, there is no need for the extra flag in the macro.
The following patch just does away with it. It uses the value of
the "size" parameter directly in avoiding a divide-by-zero, and in
the process avoids referencing the global "file_size" within the
macro expansion.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
xfs_io uses the filesystem block size as the default write buffer
size. 165 does not filter the ops counts out of the golden output,
and hnce causes failures because the ops count doesn't match for a
given sized write. Fix this by changing the filter to the generic
xfs_io no-numbers filter.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
The tests in 091 are entirely generic and pass e.g. on ext4 and jfs.
btrfs fails it, but that looks a like a btrfs-specific issue to me.
Also use _supported_os properly instead of erroring out manually on
IRIX.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
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>
- filter out xfs_alloctype_t, this was an internal emum that got removed
- filter out xfs_bmbt_rec_32_t, this is a variant of the xfs_bmbt_rec_t
that had almost no users and was removed
- filter out xfs_dinode_core_t, the separate dinode core is gone, and just
checking the size of the full dinode is enough
- accept xfs_bmbt_rec_t as the new canonical name for xfs_bmbt_rec_64_t,
and replace the old name with the new one in the output stream.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
The xfs_bmap output in the golden image is filesystem block size
dependent. Make all writes 64k to ensure that the allocation/hole
pattern is consistent across all supported filesystem block sizes.
Also, use the SCRATCH_DEV instead of the TEST_DEV so that we test
according to MKFS_OPTIONS rather than test on whatever setup the
TEST_DEV was created with.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
Use the scratch device for test 225 so that both custom mkfs and
mount options impact the test (e.g. filesystem block size). This
exposes test failures when using 512 byte block sizes, which
currently not tested unless the test device is specifically created
with a 512 byte block size.
Also clean up the file names to include the test number, and don't
remove the test files after the test has finished so that it leaves
behind a corpse that can be dissected when the test fails.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
Make test 259 a bit more readable by using the new _math() function.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Rather than testing for an exact timestamp, which could vary
due to rounding, just check that it is not positive,
which is the failure case we're looking for.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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>
Bill Kendall
Dmitry Monakhov
Anand Jain
Eryu Guan
Alex Elder
Dave Chinner
Christoph Hellwig
Eric Sandeen