Messages in this thread | | | Date | Fri, 1 Nov 2002 03:32:08 +0000 | From | Jamie Lokier <> | Subject | Re: New nanosecond stat patch for 2.5.44 |
| |
Bill Davidsen wrote: > > Oh, the inode of a file which is open does remain in core. It's just > > that between runs of a program like "make", the file's aren't open are > > they? > > I thought we were talking about parallel make, rather than "between runs."
A parallel build often does call "make" separately many times, in parallel but not guaranteed to overlap all file opens. Between those, the files are closed.
> Your point is valid, but given the certainty that the inode has been > recently used, hopefully the kernel is smart on releasing them.
That's a "hopefully", and it depends on how much RAM you have as well as pure luck. I can live with that for building programs at home, but there are many applications where "hopefully" affecting correctness of behaviour is not acceptable.
> My first thought is that the commonly used filesystems, other than ext2, > do or will support high resolution time. NFS is its own nasty little > problem.
Do they support nanosecond time, though, or do they round it to microseconds or something like that?
> [stuff about atime]
There seems to be general agreement that atime is not a very important value, with which I concur. (Why do we even bother with nanosecond atimes?)
I am only concerned about mtime, which is very useful indeed when we talk about building things which can detect changes to files.
Andi, I belive there is space in every architecture's stat64 (i.e. all those that have one) for a word describing the mtime resolution. If I code a patch to create that field, would you be interested?
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |