Messages in this thread | | | Subject | Re: silent semantic changes with reiser4 | From | Nicholas Miell <> | Date | Wed, 25 Aug 2004 19:02:43 -0700 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |