> Dne 10.7.2013 16:45, markw@mohawksoft.com napsal(a): >>> Dne 10.7.2013 05:45, markw@mohawksoft.com napsal(a): >>> Yes - differential snapshot will be supported through thin provisioning >>> target - where you will be able to make a simple diff just by reading >>> metadata - it will be essential piece of replication. >> >> Is any of this in place now? > > Surely not - if it would be in place - I'd suggest which command you > should use :) Ahh, ok. > >> >>> >>> AFAIK Joe has this in plan for some time - and there was even some >>> announcement from some third-party developer to support this. >> >> Do you have a link? > > > https://www.redhat.com/archives/dm-devel/2013-July/msg00005.html > >>> >>> There is not going to be any upstream support for doing this with >>> old-snaps in foreseeable future. >>> >>> Also keep in mind your idea of using old-snap of snap of snap would be >>> very >>> slow and fragile to use. >> >> Well, the reason I am pursuing this..... >> >> At a previous employment a few years back, I created a system using >> LVM2, >> old style snapshots, and FUSE to create this functionality. >> >> Using my previous example as a reference >> >> disk0 would always have one live snapshot to maintain diffs, call it >> disk0_snap_root. > > Using chain of old-snaps is just way too heavy for anything - you really > need > to use system which is not copying blocks Well, yes, grabbing a new block and using it in the original volume would be more efficient than copying old data to (n) snapshots. However, in the system I wrote I only did the copy to one snapshot. All previous snaps referred to the next newer snap in the chain. > > >> I need to implement similar behavior at a new employer and really really >> want not to use FUSE and rewrite all that crap again and am trying to >> see >> how to get it done using the device mapper layer. Also this is going to >> be >> for a product that is expected to ship to customers in the relatively >> near >> term. >> >> Any information or insight you can share would be much appreciated. I am >> beginning to suspect that LVM will not be usable for the project. > > As I said - btrfs has some kind of functionality you are looking for, > Or you may start to help with lvm project... > (Or thin-provisioning tools in this case) Where's a good place to look to start? > > Zdenek > > _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
