Re: directory entries

[Reinoud Zandijk <reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2292 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 478 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users