Re: Documenting MS_RELATIME
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-sizeUse file size attribute instead of access time Support was there at least in 1998, maybe before. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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-sizeUse 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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-sizeUse 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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-sizeUse file size attribute instead of access time Support was there at least in 1998, maybe before. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting MS_RELATIME
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
