Matthew Dillon wrote an update for the state of HAMMER, the new file system for DragonFly. It’s at the point where historical data can retrieved even after data is deleted, though it’s not stable yet. The most recent commit notes an interesting upcoming feature idea: historical atime and mtime tracking.
A running description of activity related to DragonFly BSD.
I think this has already been bikeshedded to death, but I’m reminded…
In-band signaling seems really novel until the moment you encounter the nightmare situation of a filesystem with files containing the signaling characters. @@ isn’t a very common combination, but I’m sure it must happen somewhere.
To keep the universe in alignment, it feels like there should be a mount option to turn that on or off, and the equivalent functionality available via the out-of-band ‘mess of options’ technique (…or should we just grow a way to pass an “options” string straight through from tools and let filesystems eat it or ignore it?…)…
I also had this idea about using something like named pipes to access historical data (is that a job for varsyms?), but I’m not sure how dangerously recursive that could get. On the one hand, it seems like it should be possible/desirable to back those up or copy them around as references/symlinks, but on the other, if you’re relying on a persistent pointer to historical data rather than copying or marking that data into the current working set you want to preserve…. [The FS could specifically preserve historical data that has open references, I guess, but then it has to keep track of all those, and if you remove and recreate the reference, you could be in for a nasty surprise…]
I’ve been meaning to review the mailing lists and raise this there, but I’ve had negative spare time in the past few months, so y’all get an incoherent blog comment instead. ^^