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>
Sometimes using bash $(()) math might not be enough due to some
limitation (big numbers), so add helper using 'bc' program. For
now the results are only in perfect numbers (as in bash) since this is
all I need for now.
This commit also adds _require_math() helper which should be called by
every test which uses _math() since it requires "bc" to be installed on
the system.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Move the assignment of testfile after the sourcing of the common.* files to
make sure TEST_DIR is already defined - without this we end up creating
the file on the root filesystem, which may not support large enough files.
Also add a sync after the mkfs.xfs invocation, as losetup -d might fail
the loop device deletion with -EBUSY otherwise.
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>
When we are parsing input arguments we should really use stroull to get
unsigned long long numbers, since this is what we can specify on the
command line. With this fix it should parse long numbers on the 32 bit
architecture correctly.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
The XFS_BLI_CANCEL flag got rename to XFS_BLF_CANCEL, allow loggen compile
with both versions.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
In older Linux kernels, requesting an extended attribute which cannot exist
failed with EPERM. In version 3.0, this was changed to ENODATA so that
programs can distinguish between missing attributes and permission problems
independent of the file type.
For example, lgetxattr("file", "user.name", NULL, 0) will now return ENODATA if
no such attribute exists even if "file" is a symbolic link.
In test 062, to make it work on kernels before and after 3.0, accept either of
the two error results from getfattr.
Signed-off-by: Andreas Gruenbacher <agruen@kernel.org>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Changed the test 079 to be generic for all filesystems and to be executed
for all filesystems. In src/t_immutable.c which is compiled for Linux
only, replace the old style XFS and ext2 specific code for setting the
append-only and immutable flags by generic code that makes use of the
ioctl(FS_IOC_SETFLAGS) and ioctl(FS_IOC_GETFLAGS) and remove the check for
the specific filesystem type. FS_IOC_GETFLAGS/FS_IOC_SETFLAGS is always
used and placed in an '#ifdef FS_IOC_SETFLAGS' block in order to never fail
compilation. Without support for FS_IOC_SETFLAGS, the test completes
with _notrun.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Use _scratch_mkfs / _scratch_mkfs_sized instead of _scratch_mkfs_xfs where
possible. Execute 015, 062, 083, 117, 120 and 192 for all filesystems, these
tests used to be XFS specific.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The libxfs resync brought in a new round_up macro that conflicts with the
round_up function in fsx. Rename the latter to allow building against the
new headers.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
The value of $(LIBDM) may be a linker specification -ldm, and not a
file. So it's not OK to add this to the dependency, since make will
then complain that it doesn't know how to make the target -ldm.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
On Debian/Ubuntu systems, if autoconf version 2.13 is installed,
autoconf will try to automatically figure out whether autoconf 2.13 or
something more modern is required (since the autoconf maintainers,
curses be upon them, didn't bother to maintain compatibility between
autoconf 2.13 and 2.50). Unfortunately, the hueristics aren't
perfect, and although the configure.in file looks superficially like
it will be compatible with autoconf 2.13, it isn't. You will end up
with a number of very subtle compilation failures if you use autoconf
2.13.
So declare a requirement for autoconf 2.50 using AC_PREREQ(2.50).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Different filesystems account different amount of metadata in quota.
Thus it is impractical to check for a particular amount of space
occupied by a file because there is no right value. Change the test
to verify whether the amount of space is between the expected amount
of space and the expected amount +5%. The number of files is
checked exactly as previously.
Signed-off-by: Jan Kara <jack@suse.cz>
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 moves the su routines in test 123 to common.rc so that
they can also be used in the new test 256
Signed-off-by: Allison Henderson <achender@linux.vnet.ibm.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
The fiemap filters used in the punch hole tests parse the extent
flags in the fiemap to determine the extent type. They are
currently parsing them as decimal values, but they should be parsing
hex values.
Signed-off-by: Allison Henderson <achender@linux.vnet.ibm.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
The recent fsx fixes has a logic error in the offset trimming code.
If a read is done when the file size is zero, then the logic error
causes a offset % 0 opertaion to occur. This causes fsx to get a
SIGFPE and die.
This was not discovered during my testing because I was using a
random seed that didn't trip this condition. Changing the seed to
that which test 091 uses (the default of 1) causes such an operation
to occur....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Recent changes to debian unstable user space have caused the
xfstests build to break as certain shell functionality is being
assumed by libtool and friends. The configure scripts test and
select the correct shell, but the input files ignore this and hard
code the shell to use and hence now break.
Fix this by using the shell that the configure scripts decide is the
right one to use.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Test 250 actually runs now that it has golden output defined. The
output the test produces doesn't match the golden output, however.
The main reason seems to be a oversight in the test--the stderr
output of mkfs wasn't being ignored as it should be (likely for
debugging). Remove the comment character so the stderr does get
ignored.
Doing this still leaves some other output, but since it's filtered
there's no reason to leave it out of the golden output. So add
the expected result of filtering into the golden output file.
Finally, this test--unlike almost all of the others--specifies the
value of its "tmp" variable as a relative rather than absolute
path. I'm sure that works in some places, but it produces errors
for me. Follow the "tmp=/tmp/$$" convention used elsewhere.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Lukas Czerner
Christoph Hellwig
Boris Ranto
Eric Sandeen
Gražvydas Ignotas
David Sterba
Eric Sandeen
Stefan Behrens
Theodore Ts'o
Jan Kara
Allison Henderson
Dave Chinner
Alex Elder