On Tue, 2 May 2000, Peter Moulder wrote:
> On Tue, 2 May 2000, Bruce Janson wrote:
>
> > Maintenance of the traditional unix atime field turns read-like
> > operations into write-like operations. For sophisticated network
> > file systems that maintain a coherent distributed view, this
> > hurts performance.
> >
> > Which popular/essential/useful user-level Linux applications
> > break when atime is disabled (say, pegged to zero)?
>
> Things I've used atime for:
>
> - Finding file creation time of a file that is still being written to but
> never been read from.
>
> - Finding programs/packages that I never / rarely use. (I think Debian's
> popularity-contest package uses atime to estimate the frequency of
> usage of different packages.)
>
> Rather than pegging to zero, _I_ would prefer that atime was weakly
> updated (i.e. some "logical updates" are allowed to get lost). More
> specifically, we update the in-memory atime just as we do currently, but
> either:
>
> 1) not marking the inode dirty if only the atime is changed; or possibly
> 2) marking it "mildly dirty", meaning that it should be written back to
> disk only if cheap to do so (e.g. if there's no other I/O to be
> done and the disk isn't spun down; on some systems this may be almost
> never). Of course the inode can also be written to disk if it is made
> dirty in some other way (e.g. ctime change).
>
> There is one disadvantage of always updating the in-memory atime but not
> always writing that change to disk: it can result in atime going backward
> in time if the inode is flushed from memory without writing the updated
> atime to disk. I.e.
>
> Read inode into memory: atime is 42.
> Read from file, update atime to 69.
> stat shows atime is 69.
> Short on memory, so discard that inode from memory since it is clean
> apart from a dirty atime field.
> stat called again: read inode into memory from disk, atime back at 42.
>
> Nevertheless, I'd be content with this model (so long as it was a mount
> etc. option just as noatime is at the moment).
Ideally, we could set a "do not discard" flag on the inode - so it isn't
written to disk like a dirty inode would be, but isn't thrown away,
either.
While it is "in_use", it shouldn't be discarded anyway. If we just set a
new flag in the inode, then check this when it comes off the "in_use" list
and sync if necessary, this should do the job?
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:10 EST