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: Tue, 6 Apr 2004 21:48:44 +0100 [thread overview]
Message-ID: <20040406204843.GL31500@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20040406145544.GA19553@MAIL.13thfloor.at>
On Tue, Apr 06, 2004 at 04:55:44PM +0200, Herbert Poetzl wrote:
>
> Hi Andrew!
>
> according to todays vfs strategy (hope it hasn't changed
> again), here is the first patch, which adds the mount
> flags propagation, fixes the /proc display, and implements
> noatime and nodiratime per mountpoint ...
>
> please consider for inclusion ...
noatime/nodiratime: OK, but we still have direct modifications of i_atime
that need to be taken care of.
massage of ->show(): more or less OK. However, we don't need to keep
MS_NOATIME and MS_NODIRATIME in flags at all -
> + if (flags & MS_NOATIME)
> + mnt_flags |= MNT_NOATIME;
> + if (flags & MS_NODIRATIME)
> + mnt_flags |= MNT_NODIRATIME;
> flags &= ~(MS_NOSUID|MS_NOEXEC|MS_NODEV);
should remove them from flags in the last line, same way we do that for
nosuid/noexec/nodev, with obvious consequences for ->show().
Note that we don't need to keep MS_NOATIME check in update_atime() - that
animal is purely per-mountpoint now.
> + if (MNT_IS_NOATIME(mnt))
> + return;
> + if (S_ISDIR(inode->i_mode) && MNT_IS_NODIRATIME(mnt))
> + return;
Do we need those to be macros? AFAICS, this is the only place where we
do such checks and we shouldn't get new callers. IOW, keeping them
separate doesn't buy us anything and only obfuscates the code.
> -#define MNT_NOSUID 1
> -#define MNT_NODEV 2
> -#define MNT_NOEXEC 4
> +#define MNT_RDONLY 1
> +#define MNT_NOSUID 2
> +#define MNT_NODEV 4
> +#define MNT_NOEXEC 8
> +#define MNT_NOATIME 16
> +#define MNT_NODIRATIME 32
*ugh*
a) what's the point of reordering them (rdonly shifting the existing ones)?
b) since MNT_RDONLY doesn't do anything at that point, why introduce it
(and associated confusion) now? As it is, your /proc/mounts will pretend
that per-mountpoint r/o works right now. Since it doesn't...
> +#define MNT_IS_RDONLY(m) ((m) && ((m)->mnt_flags & MNT_RDONLY))
> +#define MNT_IS_NOATIME(m) ((m) && ((m)->mnt_flags & MNT_NOATIME))
> +#define MNT_IS_NODIRATIME(m) ((m) && ((m)->mnt_flags & MNT_NODIRATIME))
See above. Besides, are we ever planning to pass NULL to these guys?
next prev parent reply other threads:[~2004-04-06 20:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-06 14:55 Herbert Poetzl
2004-04-06 20:48 ` viro [this message]
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
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=20040406204843.GL31500@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome