Messages in this thread | | | Date | Wed, 3 Nov 1999 12:35:58 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: structure dentry help... |
| |
Date: Wed, 3 Nov 1999 15:46:44 +0100 From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
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.
A close interpretation of POSIX.1 requires this, since any time an inode is modified, the mtime field must be updated, and any time the inode is changed (and there isn't an exception made for the mtime field), the ctime field must be updated.
In that case, wouldn't recording just ctime be enough?
I'd record both, just in case some filesystem didn't completely implement POSIX.1 correctly, but in practice this isn't necessary with a compliant implementation.
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.
Yes, if you need to detect changes under a sub-second resolution, we can't do that today. Some Unix filesystems do support using a struct timeval for ctime, but ext2 doesn't, and unfortunately we don't have space in the ext2 inode for that. Still, depending on your application, this might not be an issue.
- ctime is not always updated by some filesystems.
Any kind of magic system to detect when/if a directory or a file has changed isn't going to be implemented by all filesystems. That's just a fact of life. So you have the choice of either using some hueristic (i_size + i_mtime + i_ctime), but if you really want to be sure to catch *any* change, with 100% efficiency, your only choice is going to be to MD5 the entire inode, and store that in your database. TNSTAAFL.....
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.
Modifying the ctime of the parent directory is Right Out. That violates POSIX.1, and will possibly break other programs. It's convenient for your application, but it breaks the semantic meaning of the ctime field.
I understand why you want what you want, but propagating up the directory tree is probably not something we can supply, since space in the ext2 inode is *very* tight, and this would have to be a new field, since you're asking for a completely semantics.
We can probably store something in the in-core inode structure to handle the subsecond update issue, but doing something which propagates up the directory hierarchy is probably not going to happen; at least, I can't see a clean way of doing 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?
Lookup can't update non-directory entires, since it can't do that without actually stat'ing the file. By the time the stat() has happened (which is further down on the stack), it's a lot harder to update the parent directory entry. It's not impossible, but I suspect it will be rather tricky. If you want give it a try, go ahead. :-)
- Ted
- 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/
| |