All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Nathan Scott <nscott@aconex.com>
Cc: David Chinner <dgc@sgi.com>, Vlad Apostolov <vapo@sgi.com>,
	xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Review: factor extracting extent size hints from the inode
Date: Tue, 12 Jun 2007 19:49:22 +1000	[thread overview]
Message-ID: <20070612094922.GW86004887@sgi.com> (raw)
In-Reply-To: <1181630386.3758.90.camel@edge.yarra.acx>

On Tue, Jun 12, 2007 at 04:39:46PM +1000, Nathan Scott wrote:
> On Tue, 2007-06-12 at 16:08 +1000, David Chinner wrote:
> > 
> > If you use this method of setting the extent size hint, then you will
> > *always* get the XFS_DIFLAG_EXTSIZE flag set when you have an extent
> > size hint, regardless of whether it is a realtime file or not. 
> 
> The extsize flag is relatively recent though, and traditionally
> realtime files could have had their extsize explicitly set with
> no associated extsize flag (thats just how it was implemented,
> originally, in realtime).

*nod*

We've got recent bugs reported because of this assumption and lack
of checking of the extent size hint flag where it needs to be
checked.

Either we have a flag to indicate the di_extsize field is valid or
we don't - it's too confusing to have different interfaces just
because an inode has a different, unrelated flag set on it.
Now that we have a flag, we can't remove support for it.....

> But, not many people use realtime, even fewer would be using the
> extent size option with realtime (like, none?, on Linux anyway)
> ... so, you could pretty much make whatever rule you like.

I sorta left that unsaid, but that is yet another reason I think
the change should stand.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

      reply	other threads:[~2007-06-12  9:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-04  5:23 Review: factor extracting extent size hints from the inode David Chinner
2007-06-04 15:10 ` Christoph Hellwig
2007-06-12  5:13 ` Vlad Apostolov
2007-06-12  6:08   ` David Chinner
2007-06-12  6:39     ` Nathan Scott
2007-06-12  9:49       ` David Chinner [this message]

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=20070612094922.GW86004887@sgi.com \
    --to=dgc@sgi.com \
    --cc=nscott@aconex.com \
    --cc=vapo@sgi.com \
    --cc=xfs-dev@sgi.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.