Dear Ryusuke, On Tue, Aug 26, 2008 at 07:29:42PM +0900, Ryusuke Konishi wrote: > On Mon, 25 Aug 2008 17:52:44 +0200, Reinoud Zandijk wrote: > > - writable snapshots > > > > This sounds like a fun feature. Would you like to have 1) multiple writable > > and snapshotable heads? 2) support updating a snapshot or 3) support > > writing to a snapshot that is lost when unmounted? > > What's the difference between (1) and (2), do you mean ? > The number of read/write mounts concurrently mountable ? > > I'd like to allow read/write mount for snapshots like: > > # mount -t nilfs2 -o rw,cp=xxx /dev/block /dir > > and maybe (2) is nearest to what I want. > The (3) seems to be rather restrictive.
well i already guessed so :) though a forkable FS has its advantages! but would one really use it in practice? It could be handy for switching between configurations and effectively has a COW strategy that keeps the diffs for each head between the fork point and the current point but that could also be done with an LVM. > > 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'. We could also give snapshot/head a name; then increasing checkpoints is no issue if you keep the head name; one can then search for the `HEAD' name with the highest checkpoint number. Or are you suggesting a different way? > > - data integrity support > > I'd rather expect that the future data integrity extension of block > layer (e.g. T10 DIF) due to simplicity and performance reason. yeah, maybe the block level would be better yes; easier at least :-D > > - B tree base directory management > > - Extent support > > For extent based management, there seem to be some possibilities to apply > it in NILFS. For example, > > - Extent tree (like ext4. This is a possible displacement of B-tree ) > - Extent based DAT (would save disk space consumed by DAT and improve > performance) > - Extent based binfo in segment summary. Extent based DAT yeah, that could be used yes. An extent tree is quite ... a different thing though i dont know how difficult it would be to implement an extent based DAT; haven't tried it yet. With regards, Reinoud
pgpmYEvR0fcb8.pgp
Description: PGP signature
_______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
