Dear Reinoud, On Tue, 26 Aug 2008 15:29:44 +0200, Reinoud Zandijk wrote: > > > But how to number checkpoints and snapshots then? > > > > I don't like CVS revision like extension. > > Just appending derived checkpoints (from a snapshot) to current head, > > seems to be preferable. What do you think? > > For option (2) new data/modifications can we written out only under the old > checkpoint number like the cleaner does.... but if you create a new > checkpoint for it ... i dunno; that would break the rule `the last > checkpoint is the head'.
Or, we can just think the ``main'' stream was replaced by the continued snapshot every time it is mounted in rw-mode. In this case, the head is regarded to be moved to the new (latest) checkpoint. This is actually convenient for the recovery in which a user pushed ``recover button'' for the snapshot. Note that even the old head becomes a plain checkpoint, it's still mountable and continuable again by being changed to a snapshot. To realize writable snapshots on this interpretation, However, we have to solve technical problems around the DAT file. The DAT file, which is a table file to map virtual disk addresses to actual disk addreses, also maintains lifetime information of each disk block, which is used to perform garbage collection. To that end, this file must be extended to handle multiple lifetimes per block, and this would complicate the DAT. Without the DAT file, things are not so difficult. This would be achieved in a future, but in the meantime, I'll use rsync to continue snapshots ;) > We could also give snapshot/head a name; then > increasing checkpoints is no issue if you keep the head name Yeah, this would be possible by adding another meta data file (e.g. tag file) which maps the HEAD names to checkpoint numbers of snapshots. When keeping multiple writeable snapshots, this kind of extension would be demanded than now. However, I'd rather do this in userland with a regular file (i.e. a DB file) or with TAG files each of which simply records a checkpoint number. Regards, Ryusuke Konishi _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
