Re: [PATCH] xfstests: kill lib/random.c
Hey Gents, On Mon, Jan 06, 2014 at 03:46:58PM -0600, Eric Sandeen wrote: On 1/6/14, 3:42 PM, Josef Bacik wrote: On 01/06/2014 04:32 PM, Eric Sandeen wrote: On 1/6/14, 1:58 PM, Josef Bacik wrote: I was trying to reproduce something with fsx and I noticed that no matter what seed I set I was getting the same file. Come to find out we are overloading random() with our own custom horribleness for some unknown reason. So nuke the damn thing from orbit and rely on glibc's random(). With this fix the -S option actually does something with fsx. Thanks, Hm, old comments seem to indicate that this was done handwave to make random behave the same on different architectures (i.e. same result from same seed, I guess?) I . . . don't know if that is true of glibc's random(), is it? I'd like to dig into the history just a bit before we yank this, just to be sure. I think that if we need the output to match based on a predictable random() output then we've lost already. We shouldn't be checking for specific output (like inode numbers or sizes etc) that are dependant on random()'s behaviour, and if we are we need to fix those tests. So even if that is why it was put in place originally I'd say it is high time we ripped it out and fixed up any tests that rely on this behaviour. Thanks, Yeah, you're probably right. And the ancient xfstests history seems to be lost in the mists of time, at least as far as I can see. So I'm ok with this but let's let Dave SGI chime in too just to be certain. I did not have success locating the history prior to what we have posted on oss. I agree that it was likely added so that tests that expose output from random into golden output files will have the same results across arches. Maybe this is still of concern for folks who use a different c library with the kernel. Looks there are quite a few callers. IMO if we're going to remove this we should fix the tests first. -Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: kill lib/random.c
On Tue, Jan 07, 2014 at 02:10:15PM -0600, Eric Sandeen wrote: On 1/7/14, 2:01 PM, Ben Myers wrote: Hey Gents, On Mon, Jan 06, 2014 at 03:46:58PM -0600, Eric Sandeen wrote: On 1/6/14, 3:42 PM, Josef Bacik wrote: On 01/06/2014 04:32 PM, Eric Sandeen wrote: On 1/6/14, 1:58 PM, Josef Bacik wrote: I was trying to reproduce something with fsx and I noticed that no matter what seed I set I was getting the same file. Come to find out we are overloading random() with our own custom horribleness for some unknown reason. So nuke the damn thing from orbit and rely on glibc's random(). With this fix the -S option actually does something with fsx. Thanks, Hm, old comments seem to indicate that this was done handwave to make random behave the same on different architectures (i.e. same result from same seed, I guess?) I . . . don't know if that is true of glibc's random(), is it? I'd like to dig into the history just a bit before we yank this, just to be sure. I think that if we need the output to match based on a predictable random() output then we've lost already. We shouldn't be checking for specific output (like inode numbers or sizes etc) that are dependant on random()'s behaviour, and if we are we need to fix those tests. So even if that is why it was put in place originally I'd say it is high time we ripped it out and fixed up any tests that rely on this behaviour. Thanks, Yeah, you're probably right. And the ancient xfstests history seems to be lost in the mists of time, at least as far as I can see. So I'm ok with this but let's let Dave SGI chime in too just to be certain. I did not have success locating the history prior to what we have posted on oss. I agree that it was likely added so that tests that expose output from random into golden output files will have the same results across arches. Maybe this is still of concern for folks who use a different c library with the kernel. Looks there are quite a few callers. IMO if we're going to remove this we should fix the tests first. Or first, determine if they really need fixing. Did you find tests which actually contain the random results in the golden output? At one point random.c was modified because it was returning different test results on i386 and ia64 with test 007. Looks like nametest.c is a good candidate. -Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: generic/315: allow a little tolerance for our used check
On Tue, Jul 30, 2013 at 11:48:10AM +0800, Jeff Liu wrote:
On 07/30/2013 02:55 AM, Josef Bacik wrote:
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 jba...@fusionio.com
---
tests/generic/315 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tests/generic/315 b/tests/generic/315
index 7cfc40d..9c01b5e 100644
--- a/tests/generic/315
+++ b/tests/generic/315
@@ -73,7 +73,8 @@ sync
# Preallocated disk space should be released
avail_done=`df -P $TEST_DIR | awk 'END {print $4}'`
-[ $avail_done -eq $avail_begin ] || _fail Available disk space
($avail_done KiB)
+_within_tolerance df $avail_done $avail_begin 1%
+[ $? -eq 0 ] || _fail Available disk space ($avail_done KiB) wanted
($avail_begin KiB)
Looks good to me.
Reviewed-by: Jie Liu jeff@oracle.com
Applied.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: make the scratch device for generic/256 slightly larger
On Tue, Jul 02, 2013 at 03:17:18PM -0400, Josef Bacik wrote: 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 jba...@fusionio.com Looks fine to me. Reviewed-by: Ben Myers b...@sgi.com -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Xfstests/btrfs/308: add snapshot-aware defrag for partial extents testcases
On Wed, Jul 03, 2013 at 05:46:20PM +0800, Liu Bo wrote:
This is to test whether snapshot-aware defrag can work well on partial
extents.
Signed-off-by: Liu Bo bo.li@oracle.com
---
tests/btrfs/308 | 93
+++
tests/btrfs/308.out |2 +
tests/btrfs/group |1 +
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100755 tests/btrfs/308
create mode 100644 tests/btrfs/308.out
diff --git a/tests/btrfs/308 b/tests/btrfs/308
new file mode 100755
index 000..b3dd39c
--- /dev/null
+++ b/tests/btrfs/308
@@ -0,0 +1,93 @@
+#! /bin/bash
+# BTRFS QA Test No. 308
+#
+# Test if snapshot-aware defrag can work well on partial extents, ie.
+# extent_offset is not zero.
+#
+#---
+# Copyright (c) 2013 Oracle. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap _cleanup; exit \$status 0 1 2 3 15
+
+_cleanup()
+{
+cd /
+rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+
+# Modify as appropriate.
+_supported_fs generic
_supported_fs btrfs
Since this is btrfs specific, I think _supported_fs should be btrfs.
I didn't see anything obviously wrong with the rest of this, but I'd rather see
a review from a btrfs expert.
Reviewed-by: Ben Myers b...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xattr performance
Hey Christian, On Fri, May 17, 2013 at 05:02:21AM -0700, Christian Kujau wrote: a while ago I was setting reading extended attributes to ~25000 files in a directory structure on an XFS filesystem. The files were usually a few MB in size, but some where up to 2GB in size. Anyway, I *felt* that setting or reading these xattrs was going very slowly. While the storage may be not the fastest, stat()'ing these files was fine, but getfattr/setfattr took very long. I got curious and while it turned out that the slowness was related to the wrapper script I used to read/set those values, I created a little test suite to 1) create a few thousand files and 2) do xattr operations on them and see if xattr performance was filesystem specific: http://nerdbynature.de/bits/xattr/ Not very sophisticated, true. But it was interesting to see that ext3/ext4/xfs behaved kinda well for all these tests; btrfs/jfs/reiserfs sometimes took way longer than the others. Very interesting results! One wrinkle that you might want to consider with XFS is the overall size of the attributes versus the size of the inode. You can choose inode sizes between 256 bytes and 2k in powers of two, and we always allocate them in chunks of 64. The 'literal' area is the space after the inode core and before the next one... it's best described here: http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/On-disk_Inode.html The short version: inode core (96 bytes) + literal area == inode size The data and attribute forks share the literal area. If the attributes get too big to fit inside the literal area with the data fork they will go out of line and be stored elsewhere in the filesystem. The performance characteristics of inline vs out-of-line attributes are significantly different. That might be what you experienced when you felt that setting/reading xattrs was taking a long time. Anyway... If you're a heavy user of EAs you might benefit from using larger inodes. Just something to consider. Cool tests! ;) Regards, Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce re-factor all current xfstests patches request
Hey, On Wed, Mar 27, 2013 at 01:42:17PM -0700, Zach Brown wrote: On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote: What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) It does seem like a good idea to help people map from descriptive names to their previous numeric file names. But do we want to bake it in to the file names forevermore? Would it be good enough to start the old tests with something like _was_test_nr 45 that spits out the old test number in the log? Just thinking out loud over here. Maybe a text file containing the mapping would be sufficient. It's not as if it's going to grow. -Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [btrfs-progs] Btrfs quotas testing
Hey Hemanth, On Fri, Feb 15, 2013 at 06:15:24PM +0530, Hemanth Kumar wrote: Signed-off-by: Hemanth Kumar hemanthkuma...@gmail.com Looks like this is btrfs specific. You probably don't need to cross post to x...@oss.sgi.com, unless you're interested in adding a test to xfstests. If so, you might want to check out the existing quota group of tests to see if one could be modified to your purpose. ~/xfstests$ grep quota group ... Regards, Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: fix 284 ENOENT error
Hey Liu, On Sun, Jan 06, 2013 at 10:30:38PM +0800, Liu Bo wrote: 284 misses a 'mkdir' operation. Signed-off-by: Liu Bo liub.li...@gmail.com Reviewed-by: Ben Myers b...@sgi.com Applied to git://oss.sgi.com/xfs/cmds/xfstests.git Regards, Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] xfstests 265: add a prealloc and reserve test
Hi Wu Bo, On Thu, Nov 03, 2011 at 11:09:00AM +0800, WuBo wrote: 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...@cn.fujitsu.com This test is failing for me because I don't have fallocate installed. I suggest the test could to be changed to check for binaries it uses, possibly the version of those binaries, and then not run unless the right ones are installed. But the best I can do right now is make a note of it. Just a heads up. ;) Regards, Ben -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
