Val,
I'm just updating the mount(2) man page for MS_RELATIME, and this is the
text I've come up with:
MS_RELATIME(Since Linux 2.6.20)
When a file on this file system is accessed, only
update the file's last accessed time (atime) if
the current value of atime is less than or equal
to the file's last modified (mtime) or last sta-
tus change time (ctime). This option is useful
for programs, such as mutt(1), that need to know
when a file has been read since it was last modi-
fied.
This text is based on your comments accompanying the various patches, but
it differs in a respect. Your comments said that the atime would only be
updated if the atime is older than mtime/ctime. However, what the code
actually does is update atime if it is is <= mtime/ctime -- i.e., atime is
older than or *or equal to* mtime/ctime.
I'm sure that the code implements your intention, but before incorporating
the above text I thought I just better check, since the code differs from
your comment. Can you just confirm that the proposed man page text is okay.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.
On Sat, Feb 10, 2007 at 09:56:07AM -0800, Michael Kerrisk wrote:
> Val,
>
> I'm just updating the mount(2) man page for MS_RELATIME, and this is the
> text I've come up with:
>
> MS_RELATIME(Since Linux 2.6.20)
> When a file on this file system is accessed, only
> update the file's last accessed time (atime) if
> the current value of atime is less than or equal
> to the file's last modified (mtime) or last sta-
> tus change time (ctime). This option is useful
> for programs, such as mutt(1), that need to know
> when a file has been read since it was last modi-
> fied.
>
> This text is based on your comments accompanying the various patches, but
> it differs in a respect. Your comments said that the atime would only be
> updated if the atime is older than mtime/ctime. However, what the code
> actually does is update atime if it is is <= mtime/ctime -- i.e., atime is
> older than or *or equal to* mtime/ctime.
>
> I'm sure that the code implements your intention, but before incorporating
> the above text I thought I just better check, since the code differs from
> your comment. Can you just confirm that the proposed man page text is okay.
Whilst on the subject of RELATIME, is there any good reason why
not to make this a default mount option ?
Dave
--
http://www.codemonkey.org.uk
On Sat, Feb 10, 2007 at 09:56:07AM -0800, Michael Kerrisk wrote:
> Val,
>
> I'm just updating the mount(2) man page for MS_RELATIME, and this is the
> text I've come up with:
>
> MS_RELATIME(Since Linux 2.6.20)
> When a file on this file system is accessed, only
> update the file's last accessed time (atime) if
> the current value of atime is less than or equal
> to the file's last modified (mtime) or last sta-
> tus change time (ctime). This option is useful
> for programs, such as mutt(1), that need to know
> when a file has been read since it was last modi-
> fied.
>
> This text is based on your comments accompanying the various patches, but
> it differs in a respect. Your comments said that the atime would only be
> updated if the atime is older than mtime/ctime. However, what the code
> actually does is update atime if it is is <= mtime/ctime -- i.e., atime is
> older than or *or equal to* mtime/ctime.
>
> I'm sure that the code implements your intention, but before incorporating
> the above text I thought I just better check, since the code differs from
> your comment. Can you just confirm that the proposed man page text is okay.
That's correct, yes. Thanks!
-VAL
On Sat, Feb 10, 2007 at 07:54:00PM -0500, Dave Jones wrote:
>
> Whilst on the subject of RELATIME, is there any good reason why
> not to make this a default mount option ?
Ubuntu has been shipping with noatime as the default for some time
now, with no obvious problems (I'm running Ubuntu). I see relatime as
an improvement on noatime.
-VAL
On Sun, Feb 11, 2007 at 10:55:04PM -0800, Valerie Henson wrote:
> On Sat, Feb 10, 2007 at 07:54:00PM -0500, Dave Jones wrote:
> >
> > Whilst on the subject of RELATIME, is there any good reason why
> > not to make this a default mount option ?
>
> Ubuntu has been shipping with noatime as the default for some time
> now, with no obvious problems (I'm running Ubuntu). I see relatime as
> an improvement on noatime.
The one problem with noatime is that mutt's 'new mail arrived' breaks
as you mentioned in the relatime changelog, so I'm surprised that
they turned it on by default. With relatime fixing that however,
I'm also unaware of anything that breaks. I'd be curious to
do a Fedora test release with relatime, but I know the answer I'll
get when I recommend we add it to our generated fstabs..
"If it's good enough, why isn't it the kernel default"
Hence my current line of questioning ;-)
Dave
--
http://www.codemonkey.org.uk
Hi,
On Feb 12 2007 10:40, Dave Jones wrote:
> > > Whilst on the subject of RELATIME, is there any good reason why
> > > not to make this a default mount option ?
> >
> > Ubuntu has been shipping with noatime as the default for some time
> > now, with no obvious problems (I'm running Ubuntu). I see relatime as
> > an improvement on noatime.
>
>The one problem with noatime is that mutt's 'new mail arrived' breaks
Just why does not it use mtime then to check for New Mail Arrived, like
bash does?
Jan
--
ft: http://freshmeat.net/p/chaostables/
On Mon, 12 February 2007 18:49:39 +0100, Jan Engelhardt wrote:
> On Feb 12 2007 10:40, Dave Jones wrote:
> >
> >The one problem with noatime is that mutt's 'new mail arrived' breaks
>
> Just why does not it use mtime then to check for New Mail Arrived, like
> bash does?
Just a guess: because it has to compare the time?
Bash can simply compare mtime of (single) mailbox with time of last
login. Mutt would have to compare mtime of (many) mailboxes with...
I believe with atime of mailboxes.
Jörn
--
Joern's library part 1:
http://lwn.net/Articles/2.6-kernel-api/
On Mon, Feb 12, 2007 at 10:40:10AM -0500, Dave Jones wrote:
>
> The one problem with noatime is that mutt's 'new mail arrived' breaks
> as you mentioned in the relatime changelog, so I'm surprised that
> they turned it on by default. With relatime fixing that however,
> I'm also unaware of anything that breaks. I'd be curious to
> do a Fedora test release with relatime, but I know the answer I'll
> get when I recommend we add it to our generated fstabs..
>
> "If it's good enough, why isn't it the kernel default"
>
> Hence my current line of questioning ;-)
Okay, I have to admit I used the normal atime semantics, exactly once.
Someone hacked my laptop about 4 years ago (back when I didn't have a
firewall and a remotely exploitable samba server was on by default in
some Red Hat install). I pulled the plug on the network (no wireless
either) and figured out which files the attacker read, which gave me
some peace of mind. :)
Personally, I'd trade that for the performance/battery life/etc. of
relatime.
-VAL
On Mon, Feb 12, 2007 at 09:53:18PM +0200, Petri Kaukasoina wrote:
> On Mon, Feb 12, 2007 at 06:49:39PM +0100, Jan Engelhardt wrote:
> > >The one problem with noatime is that mutt's 'new mail arrived' breaks
> >
> > Just why does not it use mtime then to check for New Mail Arrived, like
>
> I have always used:
>
> --enable-buffy-size Use file size attribute instead of access time
>
> Support was there at least in 1998, maybe before.
Good point. However, this works for mutt because new mail is an
append-only operation. Other apps don't have the guarantee that file
modifications that they care about will change the file size.
-VAL
On Mon, Feb 12, 2007 at 06:49:39PM +0100, Jan Engelhardt wrote:
> >The one problem with noatime is that mutt's 'new mail arrived' breaks
>
> Just why does not it use mtime then to check for New Mail Arrived, like
I have always used:
--enable-buffy-size Use file size attribute instead of access time
Support was there at least in 1998, maybe before.