From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@lst.de>
Cc: jean-noel.cordenner@bull.net, linux-fsdevel@vger.kernel.org
Subject: Re: i_version changes
Date: Wed, 13 Feb 2008 15:26:11 -0500 [thread overview]
Message-ID: <20080213202611.GM13462@fieldses.org> (raw)
In-Reply-To: <20080213125214.GA12362@lst.de>
On Wed, Feb 13, 2008 at 01:52:14PM +0100, Christoph Hellwig wrote:
> On Tue, Feb 12, 2008 at 03:06:25PM -0500, J. Bruce Fields wrote:
> > > First there's a complete lack of documentation on this, which is very
> > > bad. Please document what the new semantics for i_version on regular
> > > files are supposed to be, and how it differes from the existing
> > > semantics for directories.
> > >
> > > Second abusing one of the rather scare superblock mount flags is
> > > a bad idea. It would be much better to set this through ->setattr
> > > and an extension of struct iattr. Especially as we need to convert
> > > file_update_time to update c and mtime through ->setattr anyway.
> >
> > I don't understand that comment. (What is "this" in the second
> > sentence, for example?)
>
> i_version. Instead of hardcoding i_version updates in file_update_time
> it would be better to add an ia_verstion to struct iattr and update it
> that way.
Got it, thanks.
> > > Third using the MS_ flag but then actually having a filesystem
> > > mount option to enable it is more than confusing. After all MS_
> > > options (at least the exported parts) are the mount ABI for common
> > > options. Also this option doesn't show up in ->show_options,
> > > which is something Miklos will beat you up for :)
> > > I'm also not convinced this should be option behaviour, either you
> > > do update i_version for a given filesystem or you don't - having
> > > an obscure mount option will only give you confusion.
> >
> > That does sound likely to be confusing. Any chance we could just make
> > the new behavior mandatory?
> >
> > The one thing we need in nfsd is just an easy (in-kernel) way to check
> > whether a given filesystem supports this, so nfsd can decide whether to
> > use ctime or i_version as the change attribute.
>
> Probably through export_operations somehow. Andreas mentioned in the
> other reply that he wants it only conditionally due to the overhead
> on extN, and enabling this from an export operation called when nfs
> exporting a filesystem.
It's not OK to update it only sometimes. If updates are made while nfsd
isn't running, those needed to be reflected in the change attribute, so
the changes aren't missed when nfsd comes back up.
So I'm inclined to think this should be an option that's permanently
associated with the filesystem, rather than something that's changed on
or off by nfsd (or even on or off with each mount).
--b.
next prev parent reply other threads:[~2008-02-13 20:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-10 7:30 i_version changes Christoph Hellwig
2008-02-12 20:06 ` J. Bruce Fields
2008-02-13 9:25 ` Andreas Dilger
2008-02-13 12:52 ` Christoph Hellwig
2008-02-13 14:07 ` Trond Myklebust
2008-02-13 15:12 ` Andreas Dilger
2008-02-13 20:26 ` J. Bruce Fields [this message]
2008-02-13 21:19 ` NeilBrown
2008-02-13 21:32 ` Peter Staubach
2008-02-13 22:06 ` NeilBrown
2008-02-14 14:34 ` Peter Staubach
2008-02-14 8:40 ` Jean noel Cordenner
2008-02-14 14:38 ` Peter Staubach
2008-02-15 10:31 ` Jean noel Cordenner
2008-02-13 21:36 ` J. Bruce Fields
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=20080213202611.GM13462@fieldses.org \
--to=bfields@fieldses.org \
--cc=hch@lst.de \
--cc=jean-noel.cordenner@bull.net \
--cc=linux-fsdevel@vger.kernel.org \
/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).