From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 6/3] xfs: make largest supported offset less shouty
Date: Mon, 30 Apr 2012 13:03:30 +1000 [thread overview]
Message-ID: <20120430030330.GF7015@dastard> (raw)
In-Reply-To: <20120430011124.GD3283@dastard>
On Mon, Apr 30, 2012 at 11:11:24AM +1000, Dave Chinner wrote:
> On Sun, Apr 29, 2012 at 05:58:30PM -0400, Christoph Hellwig wrote:
> > On Sun, Apr 29, 2012 at 10:57:29PM +1000, Dave Chinner wrote:
> > > From: Dave Chinner <dchinner@redhat.com>
> > >
> > > XFS_MAXIOFFSET() is just a simple macro that resolves to
> > > mp->m_maxioffset. It doesn't need to exist, and it just makes the
> > > code unnecessarily loud and shouty.
> > >
> > > Make it quiet and easy to read.
> >
> > Do we actually need to keep around a value in our superblock?
> > s_maxbytes in the VFS superblock already does this, and it seems like
> > at least our checks in the read path are superflous.
Actually, I can't find where the read path checks against
s_maxbytes. It's not in generic_segment_check(), and there appears
to be no other range checks in the VFS. So I think that the check we
have in xfs_file_aio_read needs to remain....
> Ah, we do indeed keep the same value in s_maxbytes - that's one step
> removed from m_maxioffset because it uses the same function to
> calculate it, and they are done a long way apart. Ok, it looks like
> I've got a couple more patches to write to finish off this cleanup.
Still, we can now replace the copy-n-paste code in
xfs_file_aio_read() with a call to generic_segment_check() seeing as
it returns a sum of the iovec length now, and still kill
m_maxioffset....
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:[~2012-04-30 3:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 9:45 [PATCH 0/3] xfs: failed writes and stale delalloc blocks Dave Chinner
2012-04-27 9:45 ` [PATCH 1/3] xfs: punch all delalloc blocks beyond EOF on write failure Dave Chinner
2012-04-30 13:49 ` Christoph Hellwig
2012-04-27 9:45 ` [PATCH 2/3] xfs: punch new delalloc blocks out of failed writes inside EOF Dave Chinner
2012-05-07 22:00 ` Ben Myers
2012-04-27 9:45 ` [PATCH 3/3] xfs: prevent needless mount warning causing test failures Dave Chinner
2012-05-08 16:29 ` Ben Myers
2012-05-08 22:42 ` Dave Chinner
2012-04-29 11:16 ` [PATCH 4/3] xfs: don't assert on delalloc regions beyond EOF Dave Chinner
2012-05-08 17:26 ` Ben Myers
2012-04-29 12:43 ` [PATCH 5/3] xfs: limit specualtive delalloc to maxioffset Dave Chinner
2012-05-08 18:02 ` Ben Myers
2012-04-29 12:57 ` [PATCH 6/3] xfs: make largest supported offset less shouty Dave Chinner
2012-04-29 21:58 ` Christoph Hellwig
2012-04-30 1:11 ` Dave Chinner
2012-04-30 3:03 ` Dave Chinner [this message]
2012-05-08 18:15 ` Ben Myers
2012-05-08 22:43 ` Dave Chinner
2012-05-09 19:14 ` Ben Myers
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=20120430030330.GF7015@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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.