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/
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.
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
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.
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
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
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.
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]