From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Whitney <enwlinux@gmail.com>,
Eric Sandeen <sandeen@redhat.com>, Ben Myers <bpm@sgi.com>,
linux-ext4@vger.kernel.org, xfs-oss <xfs@oss.sgi.com>
Subject: Re: possible dev branch regression - xfstest 285/1k
Date: Mon, 18 Mar 2013 22:00:56 -0400 [thread overview]
Message-ID: <20130319020056.GC4660@thunk.org> (raw)
In-Reply-To: <20130319014718.GV6369@dastard>
On Tue, Mar 19, 2013 at 12:47:18PM +1100, Dave Chinner wrote:
> Sorry about this - I've mixed up my threads about ext4 having
> problems with zero-out being re-enabled. I thought this was a
> cross-post of the 218 issue....
>
> However, the same reasoning can be applied to 285 - the file sizes,
> the size of the holes and the size of the data is all completely
> arbitrary. If we make the holes in the files larger, then the
> zero-out problem simply goes away.
Right. That was my observation. We can either make the holes larger,
by changing:
pwrite(fd, buf, bufsize, bufsize*10);
to
pwrite(fd, buf, bufsize, bufsize*42);
... and then changing the expected values returned by
SEEK_HOLE/SEEK_DATA. (By the way; this only matters when we are
testing 1k blocks; if we are using a 4k block size in ext4, the test
currently passes.)
Or we could set some ext4-specific tuning parameters into the #218
shell script, if the file system in question was ext4.
I had assumed that folks would prefer making the holes larger, but
Eric seemed to prefer the second choice as a better one.
Hmm.... Another possibility is to define a directory structure where
each test would look for the existence of some file such as
fscust/<fs>/<test>, and so if fscust/ext4/218 exists, it would get
sourced, and this would define potential hook functions that would get
called after the file system is mounted. This way, the file system
specific stuff is kept out of the way of the test script. Would that
make adding fs-specific tuning/setup for tests more palatable?
Regards,
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-19 2:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 22:28 possible dev branch regression - xfstest 285/1k Eric Whitney
2013-03-16 2:32 ` Zheng Liu
2013-03-16 15:09 ` Zheng Liu
2013-03-17 3:06 ` Theodore Ts'o
2013-03-17 6:13 ` Zheng Liu
2013-03-18 16:10 ` Eric Sandeen
2013-03-18 16:54 ` gnehzuil.liu
2013-03-18 17:09 ` Theodore Ts'o
2013-03-18 17:34 ` Eric Sandeen
2013-03-18 20:41 ` Ben Myers
2013-03-18 23:12 ` Dave Chinner
2013-03-19 1:40 ` Theodore Ts'o
2013-03-19 2:07 ` Dave Chinner
2013-03-19 1:47 ` Dave Chinner
2013-03-19 2:00 ` Theodore Ts'o [this message]
2013-03-19 2:22 ` Dave Chinner
2013-03-19 2:28 ` Eric Sandeen
2013-03-19 8:50 ` Lukáš Czerner
2013-03-17 3:36 ` Eric Whitney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130319020056.GC4660@thunk.org \
--to=tytso@mit.edu \
--cc=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=enwlinux@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).