Hello Anand and all, On 2011-08-17 T 10:15 +0800 Anand Jain wrote: > Appears that no one is working on the auto-snapshot feature for > btrfs, so here I am implementing the same. thanks for bringing this up! The group of features you are listing is indeed of high interest for people using btrfs. That said, not only have other people though about this, but a lot of your question already have been implemented in "snapper", and open source infrastructure developed as part of openSUSE and SUSE Linux Enterprise. Please see: http://en.opensuse.org/Portal:Snapper http://en.opensuse.org/openSUSE:Snapper_install http://lizards.opensuse.org/2011/04/01/introducing-snapper/ Source code is here: http://gitorious.org/opensuse/snapper "snapper" will be part of openSUSE 12.1 and SUSE Linux Enterprise 11 Service Pack 2, and is available as part of the respective Beta releases and Milestones already. snapper's concept in short: - shared library to make the functionality available to other tools as well - libsnapper is implemented on top of the btrfsprogs - cmdline tool "snapper" - global configuration file /etc/sysconfig/snapper - one configuration file per subvolume to be snapshotted /etc/snapper/configs/<config-name> I call this a "single configuration" going forward. Here also policies for time based snapshotting and cleanup are to be configured. - Integration into SUSE's management framework (YaST2/zypper), however, "snapper" should work independent of those, i.e. usable on other distributions easily. > Below is a draft on the feature list. Any comments / questions / > suggestions are welcome, please do let me know. Let me go through the single features quickly and list the matching snapper functionality. > btrfs auto snapshot feature will include: > Initially: > - configurable timely snapshots Yes. Configured per single configuration > - uses services and crontab to schedule Yes. > - Gnome integration I more see a need for integration into systems management frameworks. > - snapshot rollback and cleanups Yes. Rules for cleanups (time based, number of snapshots) per single configuration. > - snapshot trashing based on available space // not yet done. > - snapshot destination will be subvol/.btrfs/snapshot@<time> and snapshot destination is "/.snapshots/<number>/", > snapshot/.btrfs/snapshot@<time> for subvolume and snapshot > respectively Timestamp and Description of a snapshot are stored in a small XML file /.snapshots/<number>/info.xml". One small file per snapshot. [...] > Challenges: > - rollback per file or dir instead of entire snapshot-rollback ? snapper implements "rollback" on a FILE level only. To differentiate this way of "rolling back" from jumping into another snapshot, we call it "undochange" for now. This keeps the option to also manage a full per snapshot-rollback in a later point int time. [...] > modify the snapshot - do we need to implement a kind of read-only > snapshot ? snapper treats snapshots as read only snapshots, i.e. when doing a rollback - aehem, I should say "undochange" - only the "master" volume will be changed, not the single snapshots. We are aware that this has pros and cons. But that's another discussion. I hope that this is a starting point for you. Enjoy "snapper". so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE® Linux Enterprise SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
