> > No, not demanding anything. Requesting it as a feature. While your > design has a very crucial use-case of constant checkpointing, there is > > also a use-case to *suspend* checkpointing (or enable it on demand > only). As mentioned in my previous example, when restoring to a > filesystem, or even installing new software, it is extremely unlikely > that you would want a to go back to a point *inbetween* the time you > > started the install/restore to the time it completed. Say for example > you are installing a new version of Openoffice which installs > > home:/opt/openoffice.org$ find . ! -type d |wc -l > > 4100 > > 4000 odd files. For sure if the software didn't work, crashed, was > buggy, i would go back completely to the pre-install state and would > never need any intervening checkpoint. In this case i would suspend > > checkpointing before installing (which may by default create a > snapshot), and then i'd restart the constant checkpointing after i'd > finished the install/restore. Please note, i am not comparing nilfs to > zfs, but zfs doesn't have constant cp (i think) but does have the > > feature i mention, i.e you take snapshots when needed (perhaps via a > cron job daily, monthly, weekly) > > I just want to give my though on this one, keeping checkpoints as-is seems ideal to me, in this case you have a very granular way to go back in time, however, what you say is right, when installing a new software for example, it's nice to have a way to get back to it, I guess in this case you would just convert the last checkpoint to snapshot before the installation so you have a time mark of where to rollback (and of course have a steady state which won't go away during the installation), right?
_______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
