Re: silent semantic changes with reiser4

Nicholas Miell
2004-08-26T02:03:19Z

On Wed, 2004-08-25 at 18:53, Jamie Lokier wrote:
> Nicholas Miell wrote:
> > > Additionally, all of those things you describe should be deleted if
> > > the file is modified -- to indicate that they're no longer valid and
> > > should be regenerated if needed.
> > >
> > > Whereas there are some other kinds of metadata which should not be
> > > deleted if the file is modified.
> > >
> > > -- Jamie
> >
> > Presumably the app which uses the metadata will be smart enough to
> > compare the st_mtime of the MDS/stream/attribute/whatever (can we choose
> > a name for these things now?) to the st_mtime of the file and do the
> > right thing.
>
> [This is straying off the topic of files-as-directories].
>
> st_mtime tests are weak. They break sometimes, and are not suitable
> for strong data models such as transparently caching generated data
> from a file's contents.
>
> They're especially breakable if you change a file and then read it
> within a second. Sometimes, more than a second.
>
> As has been raised before, nanosecond timestamps (a) don't solve this
> unless they're stored in the filesystem; (b) even then they will fail
> one day, on a sufficiently fast box; (c) don't work when there are
> changes to wall clock time.
>
> They're fine where you don't care if the generated data is wrong sometimes.
>
> If you want the _equivalent_ behaviour to opening and parsing the
> file, but fast, then they're no good.
>
> Modification serial numbers would work, though.
>
> -- Jamie

Remember that the Solaris attribute model is just another filesystem
tree rooted in a hidden directory associated with a regular file. If you
can come up with semantics that work in general for all files, that's
fine.

inodes that delete themselves when other inodes are changed creep me
out.