Re: Noatime vs relatime
Rene Herman <[EMAIL PROTECTED]> wrote: > I must say I've been wondering about relatime a bit as well. Are there > actually users who do really want atime, but not badly enough to want real > atime? Anyone using /var/spool/mail. -- Programming is an art form that fights back. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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: Noatime vs relatime
Rene Herman [EMAIL PROTECTED] wrote: I must say I've been wondering about relatime a bit as well. Are there actually users who do really want atime, but not badly enough to want real atime? Anyone using /var/spool/mail. -- Programming is an art form that fights back. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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: Noatime vs relatime
On 08/10/2007 05:10 PM, Matti Aarnio wrote: On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... "Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel." This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. I must say I've been wondering about relatime a bit as well. Are there actually users who do really want atime, but not badly enough to want real atime? I've been running with noatime for years now and do not plan on changing that so have been shrugging this entire discussion off with "no care of mine", but whose care _is_ it? There MUST be an easy way to tell system that "yes, I want to track last accesstime." mount -o atime. Or as far as I'm concerned, keep the default as posixly compliant as one wants and teach people and distributions to mount "noatime" as I hear some have already been doing. I may be wrong, but to me, relatime sounds like compromising for the sake of compromising... Rene. - 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: Noatime vs relatime
Vlad wrote: Linus Torvalds wrote: What we could do is to make "relatime" updates a bit smarter. A bit smarter would be: - update atime if the old atime is <= than mtime/ctime Logic: things like mailers can care about whether some new state has been read or not. This is the current relatime. - update atime if the old atime is more than X seconds in the past (defaulting to one day or something) Logic: things like tmpwatch and backup software may want to remove stuff that hasn't been touched in a long time, but they sure don't care about "exact" atime. Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime Reading a value in memory into a CPU register is not normally considered an I/O operation. 4) Comparison of "old atime is <= than mtime/ctime" 5) Find out current time 6) Comparison of "current time minus old atime is > X" People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. I suggest treating atime as if it were a subsystem that is scheduled for an overhaul - there have been plenty of those in the past. Give users/distros a config option to disable atime, but default this option in favor of atime for a couple of kernel release cycles. Print a line in dmesg that states something like: "Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel." This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. Vlad Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: > Relatime seems to be wasteful of both IO resources _and_ CPU cycles. > Instead of performing a single IO operation (as atime does), relatime > performs at least three IO operations and three CPU-dependent > operations: > > 1) a read IO operation to find out the old atime > 2) a read IO operation to find out the old ctime > 3) a read IO operation to find out the old mtime > 4) Comparison of "old atime is <= than mtime/ctime" > 5) Find out current time > 6) Comparison of "current time minus old atime is > X" As all [acm]times are stored in the same block (inode), I bet all this is one single IO, plus some insignificant computation (3 comparisons plus reading time is really smaller than one block IO). Xav - 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: Noatime vs relatime
This isn't a Linux problem, it's a *NIX convention. - 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: Noatime vs relatime
Vlad writes: > Relatime seems to be wasteful of both IO resources _and_ CPU cycles. > Instead of performing a single IO operation (as atime does), relatime > performs at least three IO operations and three CPU-dependent > operations: > > 1) a read IO operation to find out the old atime > 2) a read IO operation to find out the old ctime > 3) a read IO operation to find out the old mtime > 4) Comparison of "old atime is <= than mtime/ctime" > 5) Find out current time > 6) Comparison of "current time minus old atime is > X" > > People are going to wonder why all of the sudden everything is running > so slow due to atimes being updated after a long break. Filesystems deal with block devices, which have fairly large (at least 512-byte) read and write granularity. Sane filesystems have atime, ctime and mtime all in the same block, so one read gets all three. The file's metadata would be in the cache while it's open anyway. CPU operations are many orders of magnitude faster than block I/O, so if steps 4-6 eliminate even a fraction of a percent of atime writebacks, relatime is a net benefit. In practice, most files are read many more times than they are written, and most of those are eliminated even with step #6. Academic journals abound with storage-related studies of read versus write patterns (often including temporal locality of reference) for various kinds of files; I refer you to those for details. Michael. - 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: Noatime vs relatime
On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... > "Warning: Atime will be disabled by default in future kernel versions, > but you will still be able to turn it on when configuring the kernel." > > This should give a heads-up to the 0.001% of people who still use > atime so that they know to customize this option or start using modern > file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. There MUST be an easy way to tell system that "yes, I want to track last accesstime." I did recently an embedded Linux PC system where the entire system disk is a single Compact Flash -card. I tried to play with noatime option, but the system still kept writing things, and thus I had to do full and somewhat drastic read-only. > Vlad /Matti Aarnio - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: > Linus Torvalds wrote: > Relatime seems to be wasteful of both IO resources _and_ CPU cycles. > Instead of performing a single IO operation (as atime does), relatime > performs at least three IO operations and three CPU-dependent > operations: > > 1) a read IO operation to find out the old atime > 2) a read IO operation to find out the old ctime > 3) a read IO operation to find out the old mtime you've mistaken the concept of inode-in-memory... there is no IO involved in any of these. - 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/
Noatime vs relatime
Linus Torvalds wrote: > What we could do is to make "relatime" updates a bit smarter. > > A bit smarter would be: > > - update atime if the old atime is <= than mtime/ctime > > Logic: things like mailers can care about whether some > new state has > been read or not. This is the current relatime. > > - update atime if the old atime is more than X seconds > in the past (defaulting to one day or something) > > Logic: things like tmpwatch and backup > software may want to remove > stuff that hasn't been touched in a long time, but they > sure don't care about "exact" atime. Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of "old atime is <= than mtime/ctime" 5) Find out current time 6) Comparison of "current time minus old atime is > X" People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. I suggest treating atime as if it were a subsystem that is scheduled for an overhaul - there have been plenty of those in the past. Give users/distros a config option to disable atime, but default this option in favor of atime for a couple of kernel release cycles. Print a line in dmesg that states something like: "Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel." This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. Vlad Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: Linus Torvalds wrote: Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime you've mistaken the concept of inode-in-memory... there is no IO involved in any of these. - 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: Noatime vs relatime
This isn't a Linux problem, it's a *NIX convention. - 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: Noatime vs relatime
Vlad writes: Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. Filesystems deal with block devices, which have fairly large (at least 512-byte) read and write granularity. Sane filesystems have atime, ctime and mtime all in the same block, so one read gets all three. The file's metadata would be in the cache while it's open anyway. CPU operations are many orders of magnitude faster than block I/O, so if steps 4-6 eliminate even a fraction of a percent of atime writebacks, relatime is a net benefit. In practice, most files are read many more times than they are written, and most of those are eliminated even with step #6. Academic journals abound with storage-related studies of read versus write patterns (often including temporal locality of reference) for various kinds of files; I refer you to those for details. Michael. - 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: Noatime vs relatime
On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel. This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. There MUST be an easy way to tell system that yes, I want to track last accesstime. I did recently an embedded Linux PC system where the entire system disk is a single Compact Flash -card. I tried to play with noatime option, but the system still kept writing things, and thus I had to do full and somewhat drastic read-only. Vlad /Matti Aarnio - 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/
Noatime vs relatime
Linus Torvalds wrote: What we could do is to make relatime updates a bit smarter. A bit smarter would be: - update atime if the old atime is = than mtime/ctime Logic: things like mailers can care about whether some new state has been read or not. This is the current relatime. - update atime if the old atime is more than X seconds in the past (defaulting to one day or something) Logic: things like tmpwatch and backup software may want to remove stuff that hasn't been touched in a long time, but they sure don't care about exact atime. Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. I suggest treating atime as if it were a subsystem that is scheduled for an overhaul - there have been plenty of those in the past. Give users/distros a config option to disable atime, but default this option in favor of atime for a couple of kernel release cycles. Print a line in dmesg that states something like: Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel. This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. Vlad Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X As all [acm]times are stored in the same block (inode), I bet all this is one single IO, plus some insignificant computation (3 comparisons plus reading time is really smaller than one block IO). Xav - 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: Noatime vs relatime
Vlad wrote: Linus Torvalds wrote: What we could do is to make relatime updates a bit smarter. A bit smarter would be: - update atime if the old atime is = than mtime/ctime Logic: things like mailers can care about whether some new state has been read or not. This is the current relatime. - update atime if the old atime is more than X seconds in the past (defaulting to one day or something) Logic: things like tmpwatch and backup software may want to remove stuff that hasn't been touched in a long time, but they sure don't care about exact atime. Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime Reading a value in memory into a CPU register is not normally considered an I/O operation. 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. I suggest treating atime as if it were a subsystem that is scheduled for an overhaul - there have been plenty of those in the past. Give users/distros a config option to disable atime, but default this option in favor of atime for a couple of kernel release cycles. Print a line in dmesg that states something like: Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel. This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. Vlad Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: Noatime vs relatime
On 08/10/2007 05:10 PM, Matti Aarnio wrote: On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel. This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. I must say I've been wondering about relatime a bit as well. Are there actually users who do really want atime, but not badly enough to want real atime? I've been running with noatime for years now and do not plan on changing that so have been shrugging this entire discussion off with no care of mine, but whose care _is_ it? There MUST be an easy way to tell system that yes, I want to track last accesstime. mount -o atime. Or as far as I'm concerned, keep the default as posixly compliant as one wants and teach people and distributions to mount noatime as I hear some have already been doing. I may be wrong, but to me, relatime sounds like compromising for the sake of compromising... Rene. - 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/
