Jan Kara was testing filesystem freeze, and was consistently locking
up, although my tests of 068 were passing. He pointed out that
he was running in read/write mode, and it was atime updates causing
the trouble. Sure enough, dropping "-w" from fsstress locked me up
too. Change this so we get better (and more realistic) coverage.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
cc: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
I was running 068 to test freeze changes, and realized that
"sync" is not in the op list when "-w" (write ops) is specified,
although fsync & fdatasync are. It seems to me that sync should
be a default write op as well.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Distros(eg. RHEL5) with older version of coreutils have no truncate(1)
command. Use xfs_io instead to avoid "command not found" failures.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
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>
Test 062 was made "generic" a while back, but it fails on any filesystem
which returns getfattr -R results (aka readdir results) in something
other than inode-order.
With a little awk-fu we can sort the records from getfattr -R so that
the output is the same for xfs as well as ext4, etc.
Also filter out lost+found which extN creates at mkfs time, but
some other filesystems do not.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
For some reason, non-xfs filesystems weren't getting mounted with
the selinux context; perhaps because none of the xattr tests used
to work on anything but xfs?
Anyway, 062 fails for extN unless we mount with the fs-wide
context.
So export SELINUX_MOUNT_OPTIONS for all filesystems.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We failed to get fsck program to check the btrfs file system, it is
because btrfs uses its independent check tool which is named btrfsck
to check the file system, so the common checker -- fsck -- could not
find it, and reported there is no checker.
This patch fix it by using btrfsck directly.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This commit fixes bd8ee45c. Changes:
- added a _require_btrfs helper function
- check for filefrag with _require_command
- always use _fail in case of errors
- added some comments
- removed $fresh code
- don't set FSTYP
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>
Recent coreutils packages have changed the failure output of ln(1)
(again!) to be more verbose, breaking the filter in test 103:
-ln: creating symbolic link `SCRATCH_MNT/nosymlink/target' to `SCRATCH_MNT/nosymlink/source': Operation not permitted
+ln: failed to create symbolic link `SCRATCH_MNT/nosymlink/target' to `SCRATCH_MNT/nosymlink/source': Operation not permitted
Fix it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
It runs a bunch of rm processes inteh background, tehn immediately
calls _check_scratch_fs without waiting for them to complete, hence
the unmount can fail with abusy filesystem error.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
_require_user only checks if the qa user exists in /etc/passwd. It may exist
though still not be able to execute anything (e.g. with a /bin/false shell).
_user_do cannot determine failure to execute the given command, as it uses
_user_do_filter for post-processing which succeeds even if the command
fails. Thus, the check should be performed by _require_user.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This is a simple modification to the test 259. The script test 4TB
Filesystem but state that it is testing 2TB filesystem. This
modification simply change the the output message.
Signed-off-by: Alain Renaud <arenaud@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
For 198, 239 and 240, use _require_aiodio to fail gracefully if
required program was not built.
For 207-212, use _run_aiodio that includes _require_aiodio and
kicks specified aio-dio program, to make code expressly simple.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This reverts commit a0c92a5871 (disable
space cache), as option nospace_cache was newly introduced in linux-3.2,
so we'll fail to mount btrfs in older kernels.
As an alternative fix, we just list subvolme names, don't assume
what ID numbers those subvolumes will have.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
I can't pass 254, and below is the output:
254 3s ... - output mismatch (see 254.out.bad)
...
ID 256 top level 5 path snap
-ID 257 top level 5 path subvol
+ID 258 top level 5 path subvol
When space cache is enabled (and now mkfs.btrfs always enables it),
there will be some space cache inodes in the root tree, and they
consume some IDs, and that's why "subvol" has the ID 258 but not 257.
Just disable space cache for this test case.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The usage is 'btrfs subvolume set-default <id> <path>', not
'<path> <path>'.
The code happens to work because strotoull(path) returns 0, but it
will fail if in the future we check the argument more strict in
btrfs-progs.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Debian unstable has move the location of the gdbm libraries as part
of it's multi-arch conversion. The libraries are now only found by
the configured library search path in /etc/ld.conf.d, so change the
autoconf macros to test and find the libraries by link tests rather
than hard coding library paths when a header is found.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
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>
The first argument of _scratch_mkfs_sized() should be file system size
in bytes, so '100m' is not a valid number, and the 'expr' expression in
_scratch_mkfs_sized() complains 'non-numeric argument' about it.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Make the logging of operations in test 205 to the 205.full file work
correctly. This prevents the overwrite of mkfs status, and leaves
the 205.full file around for later analysis even on successful test
runs.
Signed-off-by: Dave Chinner <dchinner@redhat.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>