On Wed, 30 Oct 2013 09:24:41 -0700
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Oct 30, 2013 at 09:19:55AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 28, 2013 at 11:43:28AM -0400, Dwight Engen wrote:
> > > Hi Cristoph, on my system (where fsgqa is id 501) the one liner
> > > the test is running is:
> > >
> > > # ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
> > > Usage: lstat64 [-t] filename ...
> >
> > The id here is 1000 and the following works just fine:
> >
> > /src/nsexec -s -U -M "0 1000 1000" -G "0 1000 1000" ./src/lstat64
> > Usage: lstat64 [-t] filename ...
>
> But:
>
> ./src/nsexec -s -U -M "0 1000 1000" -G "0 501
> 1000" /root/xfstests/src/lstat64 execvp: Permission denied
>
>
> Which is probably due to:
> root@vm:~/xfstests# ls -ld ~
> drwx------ 6 root root 4096 Oct 30 16:24 /root
>
>
> Guess we need a relative path here?
Yep, that makes sense. I modeled this on 219 which was using
$here/src/lstat64 but didn't think about the fact that in my test fsgqa
might have traversal problems. I see plenty of other tests are using
relative paths so the following patch should (hopefully) fix 317 for you.
Thanks for tracking it down.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
generic/317 and 318 need /proc/<pid>/[uid_map|gid_map], test fail on
older kernels without that support.
Add a _require_ugid_map() function and called by 317 and 318.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The content of /proc/cpuinfo file is platform-dependent.
So we can not use it reliably to check a number of available cpus.
It would be better to use sysfs interface, as _no_of_online_cpus() does.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Btrfs will default to mixed block groups for 1 gigabyte file systems and
smaller, which means data and metadata share the same area. This makes
generic/274 fail for us because we cannot reserve enough metadata space to do
our writes. Bumping the scratch fs up to 2 gigabytes allows us to do our normal
metadata/data separation and allows us to pass this test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test is motivated by an issue found by a btrfs user, addressed
and described by the following Linux kernel patch:
https://patchwork.kernel.org/patch/3046931/
The steps to reproduce the issue on btrfs are the following:
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt
$ mkdir /mnt/acl
$ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl
$ getfacl /mnt/acl
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::---
$ mkdir /mnt/acl/dir1
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
After unmounting and mounting again the filesystem, getfacl returned the
expected default ACL for the subdirectory:
$ umount /mnt/acl
$ mount /dev/loop0 /mnt
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
This means that the underlying ACL xattr was persisted correctly but
the in memory representation of the inode had (incorrectly) a NULL ACL.
[rjohnston: renumbered test to 319]
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
test 294 is using the scratch device w/o mkfs-ing it first,
this runs the risk of following a test which completely
fills the fs, causing 294 to fail.
add "rm -f $seqres.full" as well, it was growing on every run.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Starting from util-linux v2.23 fstrim(1) reports trimmed bytes
differently, e.g.
new fstrim: /mnt/ext4: 9.7 GiB (10411118592 bytes) trimmed
old fstrim: /mnt/ext4: 10411118592 bytes were trimmed
generic/260 reports syntax error
+./tests/generic/260: line 111: [: 9.7: integer expression expected
+./tests/generic/260: line 121: [: 9.7: integer expression expected
+./tests/generic/260: line 183: [: 9.7: integer expression expected
Add a new filter called _filter_fstrim in common/filter and get the
correct trimmed bytes in generic/260, so the test passes with both old
and new fstrim.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
With coreutils v8.16 the style of apostrophes changed from `word' to
'word'. This is breaking some tests which use the older form.
This commit introduces function changes the golden output of the
affected tests and introduces a filter for the older style output.
[dchinner: modified to use a global filter in check rather than
per-test filters]
[rjohnston: minor comment change]
Signed-off-by: Tomas Racek <tracek@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Otherwise it fails with ENOSPC on CRC enabled filesystems because
of the larger inode size.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The XFS implementation of _scratch_mkfs_sized ignores MKFS_OPTIONS
when a custom block size is set and so isn't testing things like
CRCs on such sized filesytsems. Fix this by ensuring we don't try to
override the block size is it is set in MKFS_OPTIONS. xfs/204 shows
this problem.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Because if it corrupts the filesystem it currently goes undetected.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
After applied this commit (864688d3), xfstests #255 will not test a
file system that cannot support fallocate(2), such as a indirect-based
file in ext4. So we need to add a new generic test case to test it.
The difference between #255 and this test case is only to use pwrite to
allocate blocks. Other filesystems should survive in this test case.
In the mean time, a new argument '-u' is added into _test_generic_punch
not to run unwritten tests.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: xfstests: make the scratch device for generic/256 slightly larger
Date: Tue, 02 Jul 2013 19:17:18 -0000
From: Josef Bacik <jbacik@fusionio.com>
X-Patchwork-Id: 5816
Message-Id: <1372792638-23957-1-git-send-email-jbacik@fusionio.com>
To: <linux-btrfs@vger.kernel.org>, <xfs@oss.sgi.com>
This is similar to a previous fix I sent. 1 gig makes us do mixed file block
groups for btrfs, so these enospc tests will usually fail because we don't have
space for metadata, which is the case for this test. So jack the size up to
1.5gig so that btrfs can do its normal thing and pass the test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
So df in btrfs is tricky at best, and relying on it for accurate information is
not great, but it's the best way to verify this test. To get around btrfs being
inconsistent sometimes just use _within_tolerance to check our new df value to
make sure that our truncate did something. With this patch I no longer see
transient failures of this test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
ls -l will show the nblocks for the directory, and this made it into the golden
output for 314. The problem is nblocks is 0 for btrfs directories because we're
awesome, which makes us fail this test. So filter out the "total blah" line of
ls -l so btrfs can pass this test too. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Introduce generic test 315 to verify if the disk space is
released after truncating a preallocated file back to the
old smaller size. Before Linux-3.10, Btrfs/OCFS2 test
failed in this case.
The test file is fallocated with FALLOC_FL_KEEP_SIZE option.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Test generic/192 fails if noatime is set
generic/192
-delta1 - access time after sleep in-core: 40
-delta2 - access time after sleep on-disk: 40
+delta1 - access time after sleep in-core: 0
+delta2 - access time after sleep on-disk: 0
but it's pointless to test atime effects with noatime.
Signed-off-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Tests if subdirectories created on the filesystem will properly inherit sgid bit
when this is set on the parent directory, once the process has the properly
permissions to create a subdirectory, this, should inherit parent's sgid bit if
this is set and irix_sgid_inherit sysctl is disabled.
V2: add missing source of "attr" file for _require_acls
V3: use _ls_l to filter out the selinux "."
renumber to 314 to make the merge easier
V4: fix 314.out to the correct output
Thanks to Sandeen who have written this patch
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Regression test for commit:
3972f26 btrfs: update timestamps on truncate()
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
generic/193 runs the test in $here - the root of the xfstests source
tree/installation. IOWs, it doesn't test the filesystem on either
the TEST_DIR or SCRATCH_MNT, and so it not testing the filesystem
we think it is testing. Bad. Fixing this is the majority of the
change - introducing $test_root and $test_user for the files with
different owners, and then redirecting error output and filtering
the output appropriately.
And then add checks that truncate clears the suid/sgid bits
appropriately, something that has never been tested on XFS (and
likely other filesystems) so will cause kernels between 3.1 and 3.9
to assert fail as Dave Jones has recently reported.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
In some configurations (e.g. 1 KB block size), ext4 can decide it is
better to zero out several blocks rather than splitting unwritten
extent. This changes results SEEK_HOLE / SEEK_DATA returns and thus the
test fails. Fix the problem by disabling the feature for this test.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The generic/286 test tests SEEK_HOLE and SEEK_DATA, and is reasonably
fast. We should just run the test by default.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Dwight Engen
Eryu Guan
Stanislav Kholmanskikh
Josef Bacik
Filipe David Borba Manana
Eric Sandeen
Tomas Racek
Dave Chinner
Zheng Liu
Jie Liu
David Sterba
Carlos Maiolino
Jan Kara
Theodore Ts'o