Re: [Patch] BME, noatime and nodiratime

[Linus Torvalds]

On Wed, 7 Apr 2004 viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
> On Tue, Apr 06, 2004 at 09:48:44PM +0100, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> 
> > noatime/nodiratime: OK, but we still have direct modifications of i_atime
> > that need to be taken care of.
> 
> Particulary interesting one is in tty_io.c.  There we
> 	1) unconditionally touch i_atime on read()
> 	2) do not touch it on write()
> 	3) never mark the inode dirty.

All of 1-3 are correct.

They all mean that:

 - atime never gets written out for tty devices, because there is no
   point, and we shouldn't cause disk activity (or worse, network 
   activity) just because somebody is typing at the keyboard. Thus #3.

 - atime is maintained properly for "last effective read" purposes, which 
   is what "ps"/"w" and friends want to see for idle time reporting.
   Thus both #1 and #2 are important.

 - atime is only valid as long as the tty is open (again, think "idle 
   time" - nobody actually cares what the atime is after the device has 
   been closed). Thus "atime potentially going backwards" due to #3 is a 
   non-issue.

So yes, tty atime updates are strange, but they are strange on PURPOSE. 

> Note that the last one means that doing stat() in a loop will sometimes
> give atime going backwards.  We also completely ignore noatime here.

Ignoring noatime is potentially the only one we should look at, but since 
tty's really _are_ "noatime" as far as the filesystem is concerned, I 
think it makes sense in the situation we are in anyway. The real reason 
for "noatime" is to avoid unnecessary filesystem activity, not that we 
necessarily want a constant atime.

> There are similar places in some other char drivers.  Obvious step would
> be to have them do file_accessed() instead; however, I'd really like to
> hear the rationale for existing behaviour.  Comments?

I don't know about other char drivers, those may well be wrong. But for
tty's in particular, idle time calculations really do pretty much require
the behaviour (apart from #3 - and #3 is, I think, effectively required by
not wanting to touch the disk on keyboard accesses).

Doing effectively a update_atime() on final tty close might be ok just to
avoid the backwards-running time, but you'd have to open-code it to avoid 
the "inode_times_differ()" check. Not worth it, I feel, since atime on a 
tty that has been closed is irrelevant.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/