Dear folks, dear Ryusuke, On Mon, Sep 01, 2008 at 02:39:56PM +0900, Ryusuke Konishi wrote: > 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.
sounds reasonable yes... but why would that give problems with the DAT file? If you allways load the DAT, CP and SU descriptors from the latest checkpoint as recorded in the superroot even when mounting a snapshot read-write all is ok i think. The `old head' will be preserved initially as will be all allocations. If you want to keep the old head you'll have to make it a snapshot and thus protect all entries that have the old head snapshot in their intervals. Changing the `old head' snapshot to a checkpoint will just result in the cleaned up AFAICS. Do you expect trouble with the current interval code in the cleaner? I can't see why the DAT would need change. > 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 ;) are you thinking about removing the DAT file?? I thought it was the addition to v2.0 :) > > 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. The extra meta file sounds good but i dont like the `userland' DB solution; it would make nilfs dependent on DB4 (or the like) and it could make it non-selfcontaining. With regards, Reinoud
pgp925xREh6n7.pgp
Description: PGP signature
_______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
