Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
so a program writes to a file, the scanner gets notified, scans the file, notes the mtime, the program writes to the file again.
on a fast machine it's very possible that this can all take place in a short enough time that the mtime does not change
TALPA strides forward
Posted Aug 29, 2008 0:35 UTC (Fri) by njs (guest, #40338)
and the scanner gets notified again, and scans the file again, yes.
All the things you say are true, but I'm afraid I don't understand why you are saying them here (i.e., I'm missing your point somewhere)?
Posted Aug 29, 2008 0:47 UTC (Fri) by dlang (✭ supporter ✭, #313)
I posted a proposal for a slightly different approach where instead of using mtime and a single 'clean' bit I suggested stealing a chunk of xattr namespace and have the kernel clear this namespace when the file was dirtied.
this would let a scanner set a placeholder in the namespace to indicate that it was looking at the file, then when it was done it could check to see if the placeholder was still there, if so the file didn't change while it was being scanned and it's safe to mark it as scanned, if the placeholder is not there then you know the file changed and the scan you just did is worthless.
by using a chunk of namespace you can also support multiple scanners (without them needing to know anything about each other)
Posted Aug 29, 2008 7:46 UTC (Fri) by njs (guest, #40338)
(In practice I'm pretty sure that the mtime *would* always be updated, though, because in linux, in-memory inodes always get nanosecond-accurate timestamps. The extra resolution gets stripped away by the filesystem driver when the metadata gets pushed out to disk, but the actual data structures used in the core kernel don't care about that.)
Posted Aug 29, 2008 16:45 UTC (Fri) by bfields (subscriber, #19510)
In practice I'm pretty sure that the mtime *would* always be updated, though, because in linux, in-memory inodes always get nanosecond-accurate timestamps.
That's not true. On a recent kernel try running a simple test program, that does e.g., write, stat, usleep(x), write, stat. You'll see that on ext2/ext3 "x" has to be at least a million (a second) before you see a difference in the two stats, and that on something like xfs, it has to be at least a thousand to ten thousand (a few milliseconds--the time resolution used is actually jiffies).
(On older kernels I think the ext2/3 behavior might look like xfs's; that was fixed because of problems with unexpected changes in timestamps (due to lost nanoseconds field) when an inode got flushed out of cache and then read back.)
Posted Aug 30, 2008 1:47 UTC (Sat) by njs (guest, #40338)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds