Re: structure dentry help...

Jamie Lokier (
Wed, 3 Nov 1999 22:31:13 +0100

Theodore Y. Ts'o wrote:
> 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.

NB, there is an exception for atime, which seems to do its own thing.

> 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.

Some of the Linux filesystems aren't compliant in this regard. Grep for
CURRENT_TIME in fs/*/*.c and you'll see a few places where i_mtime is
set and i_ctime is not.

> 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.

That's ok. If it's implemented as an attribute, then a filesystem which
doesn't support the feature will show up clearly and I can fall back to
another, slower mechanism, or just assume the file has changed every time.

> 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.....

It's the only choice _at the moment_. That's why I'm arguing :-)

> 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.

ctime would only be modifed when a particular attribute is set on the
directory, and the attribute changes. So the directory does not have to
comply with POSIX.1 anyway. This is supports the fast-recursive-make
style of application (where it's ok to declare a directory as
"non-POSIX.1"), but not updatedb or system-wide backups.

> 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.

I am thinking of ways to share bits with the NFS generation field...
The same kind of bit shuffling and combination with ctime I mentioned
for change detection could perhaps be used to reduce the bits required
to generate a reliable generation number. After all, we can assume that
recycled inodes have a new ctime every second... Do you have any ideas

> We can probably store something in the in-core inode structure to handle
> the subsecond update issue

That is an interesting idea for change detection. If an inode stays in
core, changes can be detected accurately by any app. Refuse to release
an inode from memory for 1 second after it's ctime changes (it can be
written, just not freed), and the detection is accurate always. That
is, as long as the system clock does not jump...

> 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.

To avoid clobbering POSIX times, something to do with attributes and/or
parts of the generation number would seem to be required.

-- Jamie

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at