Check to make sure the VM system provided 0's beyond the true end of
the file mapping (as required by mmap def in 1996 posix 1003.1)
This check was taken from the FreeBSD version of fsx.c.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
The bcmp() function comes from BSD 4.3, and was deprecated in
POSIX.1-2001. It was removed entirely in POSIX.1-2008.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
The bzero() function comes from BSD 4.3, and was deprecated in
POSIX.1-2001. It was removed entirely in POSIX.1-2008.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
The ISO C approved way of printing long long variables is %ll. The %q
length modifier was used in BSD 4.4 and Linux libc5, and its use is
discouraged as non-standards compliant.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Test 205 wasn't marked executable, and had the wrong test
number in the comments.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
Somehow 042 as it stands isn't actually defragging the fragmented
file we created (see 042.full post-run)
Probably need to look into that as well, but for now this should
make the call to fsr actually _do_ something.
This has let 2 fsr bugs slip through qa in the past few months. :(
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Due to the new quantum/holographic storage I'm testing, my
disks go infinitely fast, thereby breaking some filters:
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+3 KiB, 1 ops; 0.0000 sec (inf EiB/sec and inf ops/sec)
I'm no regexp expert but I think the below change will fix it.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Similar to the xfsdump-related patch; gracefully fail
if no xfs_fsr is found.
I'll probably send another for the acl & attr userspace,
it's actually not always installed on minimal boxes.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
I was running xfstests on a NAS box which had no xfsdump,
and any tests which required xfsdump were failing in not-so-nice
ways:
+ xfsdump not found
038 [failed, exit status 1] - output mismatch (see 038.out.bad)
I think using _notrun is a lot better:
038 [not run] xfsdump not found
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
The result of async io returned in the event.res in addition
to the number of bytes read/written provides negated error
number. The broken libaio defines event.res as unsigned
while the same structure in the kernel defines it as signed.
The kernel indeed treats it as signed, and returns the
negated error number. Till libaio is fixed we provide
the signed long temp var.
Also set errno for each error condition in aio_rw, as the
caller is not aio aware and expects ret(-1)+errno by the
traditional libc convention.
Signed-off-by: Felix Blyakher <felixb@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Use larger files and different writing styles to fill a 100MB filesystem
to being full. In each case we should get very close to the filesystem
being full before getting ENOSPC. This tests different types of ENOSPC
failures to test 203 and requires more changes to pass.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Using a small (100MB) filesystem and writing lots of single block files
can result in spurious ENOSPCs being reported. Reproduce this test case
so we can confirm that it gets fixed.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
One of the big cpu time consumers when running xfsqa on UML
is forking of new processes. when looping lots of times,
using 'expr' to calculate the loop counter increment means
we fork at least once every loop. using shell builtins means
that we don't fork and many tests run substantially faster.
Some tests are even runnable with this modification. e.g. 110
went from taking 4500s to run down to 9s with the loop iterators
changed to avoid forking.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test that we can get all extent/hole information for files with more
than 16 extents and 15 holes which require a reallocation based on
XFS_IOC_FSGETXATTR.
Based on a testcase from Tomasz Majkowski <moosh009@gmail.com>.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Christoph Hellwig
Christoph Hellwig
Felix Blyakher
Theodore Ts'o
Eric Sandeen
Eric Sandeen
Dave Chinner
Josef 'Jeff' Sipek