All of lore.kernel.org
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Andrew Morton <akpm@osdl.org>,
	torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch] BME, noatime and nodiratime
Date: Wed, 7 Apr 2004 13:46:41 +0100	[thread overview]
Message-ID: <20040407124641.GR31500@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20040407101912.GA29900@MAIL.13thfloor.at>

On Wed, Apr 07, 2004 at 12:19:12PM +0200, Herbert Poetzl wrote:

> > Yes, but that's S_NOATIME in inode->i_flags, not MS_NOATIME in sb->s_flags.
> > Actually, I've been wrong here - we *do* need that check, since there are
> > filesystems that force noatime or nodiratime.
> 
> so we keep them?

yes.

> > it on remount.  Most of those are my fault - I've missed the remount side of
> > things in readdir patch.  They should have nodiratime always on to match
> > the original behaviour.  IMO, both (a) and (b) should be handled by a new
> > field - sb->s_forced_flags.  do_remount_sb() would set those in flags before
> > doing anything else.  Note that assignment to ->s_flags in do_remount_sb()
> > is not safe - e.g. ext[23] can get forced r/o by fs error and if that
> > happens after return from ->remount_sb() but before assignement, we are
> > screwed.  IOW, do_remount_sb() will need more work.
> 
> are you going to do this?

Yes - for now I'll do a fix that doesn't change API (IOW, add/update
->remount_fs() to filesystems with forced flags, forced r/o has the
same problems); we'll see what should be done in the long run when
the things clean up a bit.  I'd rather avoid struct super_block changes
that would have to be reverted soon.
 
> >> simple, to match the MS_* counterparts, something which
> >> actually confused me in the first place (in the code)
> 
> so is this okay? actually I'd prefer to use the same
> values for the MNT_NOATIME and MNT_NODIRATIME too ...
> (as in the previous version I did)

Hmm...  Potentially we are breaking ABI for no good reason, since these
defines are visible to out-of-tree code.  I don't think that we should
care about matching MS_... stuff, simply because MS_... encoding is ugly
as hell and there's no reason to use MNT_... and MS_... in the same
context.

  reply	other threads:[~2004-04-07 12:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-06 14:55 [Patch] BME, noatime and nodiratime Herbert Poetzl
2004-04-06 20:48 ` viro
2004-04-06 23:11   ` viro
2004-04-06 23:35     ` Russell King
2004-04-07  6:44       ` viro
2004-04-14 15:14     ` Linus Torvalds
2004-04-14 16:26       ` viro
2004-04-07  6:46   ` Herbert Poetzl
2004-04-07  8:47     ` viro
2004-04-07 10:19       ` Herbert Poetzl
2004-04-07 12:46         ` viro [this message]
2004-04-07 14:24           ` Herbert Poetzl

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=20040407124641.GR31500@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 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.