fstests only supports Linux, so get rid of this unnecessary predicate.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If we can't create the 60T sparse image for testing repair on a large fs
(such as when running on 32-bit), don't bother running the rest of the
test. This requires the actual truncate(1) command, because it returns
nonzero if the system call fails.
[Eryu: the original bug was introduced by me when committing the
original patch, which was a correct fix. Sorry about that.. ]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If we can't create the 60T sparse image for testing repair on a large fs
(such as when running on 32-bit), don't bother running the rest of the
test.
[Eryu: use xfs_io instead of truncate]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Fully scripted conversion, see script in initial SPDX license commit
message.
tests/xfs/044 was hand massaged to remove duplicate copyright and
divider lines before running the script.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Make sure that we have enough free space on the test fs to create a
60t sparse filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs/020 need -f option, or it'll be fail on 4k sector device.
Add -f option for xfs/032 for safe and better.
There're some cases use _check_xfs_filesystem(), or others
function which call this function to check a regular file.
That's will fail when the regular file on a 4k sector device.
For example xfs/250.
So I change _check_xfs_filesystem(), add -f option to xfs_repair,
when the $device is a file.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I'm getting enospc errors on a 4GB test device after a while of
running. Part of the issue is that many tests can't or don't clean
up previous failed runs when they start or if the run to success.
Hence while we want to slowly age the test filesystem, we don't
really want that aging to unintentionally run the filesystem out of
space. To that end:
$ sudo du -s /mnt/test/* | sort -nr |head -10
1929160 /mnt/test/fsfile
512000 /mnt/test/247.8133
512000 /mnt/test/247.4713
512000 /mnt/test/247.4488
466752 /mnt/test/fstest.9850.2
40000 /mnt/test/resv
29804 /mnt/test/fsstress.12144.1
26208 /mnt/test/populate_root
26208 /mnt/test/mnt
23216 /mnt/test/fsstress.4491.1
We can see that there are a few tests that using most of the space.
These are often left behind due to kernel failures during tests or
reboots while tests are in progress, so make sure that they at least
clean up such mess the next time they run.
Test generic/247, xfs/020 (fsfile) and generic/074 (fstest.$$.n)
are the worst offenders, so just target these to being with.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test segfault issue when repairing large xfs.
Regression test for xfsprogs commit
7f2d6b8 xfs_repair: avoid segfault if reporting progress early in repair
The original test is from the commit log, written by Eric Sandeen.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Darrick J. Wong
Dave Chinner
Zorro Lang
Eryu Guan