All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: Eric Sandeen <sandeen@redhat.com>, Theodore Ts'o <tytso@mit.edu>,
	xfs-oss <xfs@oss.sgi.com>,
	linux-ext4@vger.kernel.org, Eric Whitney <enwlinux@gmail.com>
Subject: Re: possible dev branch regression - xfstest 285/1k
Date: Tue, 19 Mar 2013 12:47:18 +1100	[thread overview]
Message-ID: <20130319014718.GV6369@dastard> (raw)
In-Reply-To: <20130318231233.GQ6369@dastard>

On Tue, Mar 19, 2013 at 10:12:33AM +1100, Dave Chinner wrote:
> On Mon, Mar 18, 2013 at 03:41:33PM -0500, Ben Myers wrote:
> > Hi Eric,
> > 
> > On Mon, Mar 18, 2013 at 12:34:59PM -0500, Eric Sandeen wrote:
> > > On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> > > > On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:
> > still run with default settings.
> 
> And when the default settings change, or some other bug fix comes
> along?
> 
> So, let's step back a moment and ask ourselves what the test is
> actaully trying to test. zero-out is not what it is trying to test,
> nor is it trying to test specific file layouts. This is a basic
> *defragmenter* sanity test. SO, we're testing 2 things:

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: Eric Whitney <enwlinux@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	xfs-oss <xfs@oss.sgi.com>
Subject: Re: possible dev branch regression - xfstest 285/1k
Date: Tue, 19 Mar 2013 12:47:18 +1100	[thread overview]
Message-ID: <20130319014718.GV6369@dastard> (raw)
In-Reply-To: <20130318231233.GQ6369@dastard>

On Tue, Mar 19, 2013 at 10:12:33AM +1100, Dave Chinner wrote:
> On Mon, Mar 18, 2013 at 03:41:33PM -0500, Ben Myers wrote:
> > Hi Eric,
> > 
> > On Mon, Mar 18, 2013 at 12:34:59PM -0500, Eric Sandeen wrote:
> > > On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> > > > On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:
> > still run with default settings.
> 
> And when the default settings change, or some other bug fix comes
> along?
> 
> So, let's step back a moment and ask ourselves what the test is
> actaully trying to test. zero-out is not what it is trying to test,
> nor is it trying to test specific file layouts. This is a basic
> *defragmenter* sanity test. SO, we're testing 2 things:

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-03-19  1:47 UTC|newest]

Thread overview: 25+ 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 17:34           ` Eric Sandeen
2013-03-18 20:41           ` Ben Myers
2013-03-18 23:12             ` Dave Chinner
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  2:07                   ` Dave Chinner
2013-03-19  1:47               ` Dave Chinner [this message]
2013-03-19  1:47                 ` Dave Chinner
2013-03-19  2:00                 ` Theodore Ts'o
2013-03-19  2:22                   ` Dave Chinner
2013-03-19  2:22                     ` Dave Chinner
2013-03-19  2:28                   ` Eric Sandeen
2013-03-19  8:50                     ` Lukáš Czerner
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=20130319014718.GV6369@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=enwlinux@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.