From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: Eric Sandeen <sandeen@redhat.com>,
xfs@oss.sgi.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 3/3] 285: Test offsets over 4GB
Date: Fri, 31 May 2013 08:34:14 +1000 [thread overview]
Message-ID: <20130530223414.GR29466@dastard> (raw)
In-Reply-To: <20130530204921.GD586@quack.suse.cz>
On Thu, May 30, 2013 at 10:49:21PM +0200, Jan Kara wrote:
> On Thu 30-05-13 15:05:02, Eric Sandeen wrote:
> > On 5/30/13 3:01 PM, Jan Kara wrote:
> > > On Thu 30-05-13 08:48:24, Eric Sandeen wrote:
> > >> On 5/30/13 7:45 AM, Jan Kara wrote:
> > >>> Test whether SEEK_HOLE and SEEK_DATA works correctly with offsets over
> > >>> 4GB.
> > >>
> > >>
> > >> Hm, should we add 2T as well while we're at it?
> > >>
> > >> (and does this cause any new failures?)
> > > Yes, ext4 is broken. I've sent fixes for it yesterday. I'm not sure what
> >
> > Argh, sorry I forgot that. I just want to be careful about more rigorous
> > tests making it look like we have regressions in the code.
> >
> > > exactly would overflow at 2T ... block counts if signed int is used and
> > > blocksize is 1KB?
> >
> > Hum ok, where'd I come up with 2T? :) never mind that maybe, unless
> > there are other potential trouble points we should add (8T? 16T for
> > filesystems that can handle it?)
> Yeah, so 8T + something might be interesting and both ext4 & xfs should
> handle that fine. 16T + something might be interesting for xfs if it
> supports that size. I'll update this patch with these checks.
What boundary traversal are we trying to test at these high
offsets?
I mean, I can understand wanting to confirm they work, but there's
no 32 bit variable boundary in the seek code at 8/16TB that needs to
be specifically test is there? i.e. is it just testing the same case
as the 8GB case?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: Eric Sandeen <sandeen@redhat.com>,
linux-ext4@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] 285: Test offsets over 4GB
Date: Fri, 31 May 2013 08:34:14 +1000 [thread overview]
Message-ID: <20130530223414.GR29466@dastard> (raw)
In-Reply-To: <20130530204921.GD586@quack.suse.cz>
On Thu, May 30, 2013 at 10:49:21PM +0200, Jan Kara wrote:
> On Thu 30-05-13 15:05:02, Eric Sandeen wrote:
> > On 5/30/13 3:01 PM, Jan Kara wrote:
> > > On Thu 30-05-13 08:48:24, Eric Sandeen wrote:
> > >> On 5/30/13 7:45 AM, Jan Kara wrote:
> > >>> Test whether SEEK_HOLE and SEEK_DATA works correctly with offsets over
> > >>> 4GB.
> > >>
> > >>
> > >> Hm, should we add 2T as well while we're at it?
> > >>
> > >> (and does this cause any new failures?)
> > > Yes, ext4 is broken. I've sent fixes for it yesterday. I'm not sure what
> >
> > Argh, sorry I forgot that. I just want to be careful about more rigorous
> > tests making it look like we have regressions in the code.
> >
> > > exactly would overflow at 2T ... block counts if signed int is used and
> > > blocksize is 1KB?
> >
> > Hum ok, where'd I come up with 2T? :) never mind that maybe, unless
> > there are other potential trouble points we should add (8T? 16T for
> > filesystems that can handle it?)
> Yeah, so 8T + something might be interesting and both ext4 & xfs should
> handle that fine. 16T + something might be interesting for xfs if it
> supports that size. I'll update this patch with these checks.
What boundary traversal are we trying to test at these high
offsets?
I mean, I can understand wanting to confirm they work, but there's
no 32 bit variable boundary in the seek code at 8/16TB that needs to
be specifically test is there? i.e. is it just testing the same case
as the 8GB case?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-05-30 22:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 12:45 [PATCH 1/3] 285: Fix test for ext4 in some configurations Jan Kara
2013-05-30 12:45 ` Jan Kara
2013-05-30 12:45 ` [PATCH 2/3] 285: Fix file syncing Jan Kara
2013-05-30 12:45 ` Jan Kara
2013-05-30 13:47 ` Eric Sandeen
2013-05-30 13:47 ` Eric Sandeen
2013-05-30 19:57 ` Jan Kara
2013-05-30 19:57 ` Jan Kara
2013-05-30 12:45 ` [PATCH 3/3] 285: Test offsets over 4GB Jan Kara
2013-05-30 12:45 ` Jan Kara
2013-05-30 13:48 ` Eric Sandeen
2013-05-30 20:01 ` Jan Kara
2013-05-30 20:01 ` Jan Kara
2013-05-30 20:05 ` Eric Sandeen
2013-05-30 20:49 ` Jan Kara
2013-05-30 20:49 ` Jan Kara
2013-05-30 22:34 ` Dave Chinner [this message]
2013-05-30 22:34 ` Dave Chinner
2013-05-31 8:22 ` Jan Kara
2013-05-30 13:45 ` [PATCH 1/3] 285: Fix test for ext4 in some configurations Eric Sandeen
2013-05-30 22:30 ` Dave Chinner
2013-05-30 22:30 ` Dave Chinner
2013-05-31 8:10 ` Jan Kara
2013-05-31 8:10 ` Jan Kara
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=20130530223414.GR29466@dastard \
--to=david@fromorbit.com \
--cc=jack@suse.cz \
--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 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.