Hmm. I had thought that ctime was only changed by changes to the inode,
not by simply writing. Now I see that for ext2 at least, ctime and
mtime are changed together by writing. Which is good.
In that case, wouldn't recording just ctime be enough?
Unfortunately that still leaves two problems:
- ctime is 1 second granular.
Fast changes -> broken behaviour. For things like Make we don't
complain because we can run Make again. For a program that should
not have such a failure case, this is not good enough.
- ctime is not always updated by some filesystems.
-- Jamie
> But for what you're trying to do, stashing the mtime and ctime field
> should be quite sufficient.
For the updatedb/fast-find/fast-make thing, I need a way for changes to
propagate up the directory hierarchy too :-)
This can be done quite cleanly using just one bit, as an ext2 attribute:
If bit is set, modifications clear it and the check is repeated for the
parent directory (recursing up as far as necessary to clear bits). The
bit cannot be set if parent is ambiguous.
Unfortunately this would be prone to interference between applications.
Since there are two obvious applications: fast updatedb, and fast
recursive make, it would be a problem.
A solution, which also solves the ctime granularity problem, is this:
Use a few more attribute bits (maybe just one) as a sub-second serial
number, and throttle the update rate. If bit 0 of serial number is set,
increment number when file is modified and repeat for parent directory
(including ctime update of parent). The throttle is implemented by
comparing the serial number to the lower bits of ctime, so that in
normal behaviour there is no need to pause either the process modifying
the file or the process checking it.
> Is it worth having the kernel ext2fs automatically convert DT_UNKNOWN
> directory entries as it encounters them (during lookup)? That would
> allow the time-consuming conversion step to be skipped.
>
> Well, that would only help directory entries. It wouldn't help all of
> the other inodes in the filesystem. It adds a bit of kernel bloat, but
> not that much. Submit a patch. :-)
?? Surely it would end up updating all the FILETYPE settings, as they
are all in directory entries?
-- Jamie
-
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/