Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] nanosecond resolution for stat(2)
Original-Message-ID: <Pine.LNX.4.33.0209231154520.3512-100000@penguin.transmeta.com>
Date: Mon, 23 Sep 2002 19:11:45 GMT
Message-ID: <fa.oca1duv.ikm43a@ifi.uio.no>

On Mon, 23 Sep 2002, Andi Kleen wrote:
>
> Some drivers (like mouse drivers or tty) do dubious inode [mac] time
> accesses of the on disk inode and without even marking it dirty. This is
> likely a bug.

No, it is intentional. At least some versions of "w" (maybe all) will use
the tty access times to judge how long the tty has been idle. The point is
that this is all information that is interesting (and useful), but not
worth sending to disk - it is useful only as long as the inode remains
locked in-core for other reasons, ie being in use.

(It's not only "not worth it" to send to disk, but it would be positively
wrong to even _try_ updating the disk with the access times, since we want
these things to work even with a read-only /dev).

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [Patch] BME, noatime and nodiratime
Original-Message-ID: <Pine.LNX.4.58.0404140803040.12398@ppc970.osdl.org>
Date: Wed, 14 Apr 2004 15:18:47 GMT
Message-ID: <fa.isnllo9.12kka3r@ifi.uio.no>

On Wed, 7 Apr 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> On Tue, Apr 06, 2004 at 09:48:44PM +0100, viro@parcelfarce.linux.theplanet.co.uk 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