lkml.org 
[lkml]   [1999]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.053 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site