>>> Jan Blunck <jblunck@xxxxxxx> 10/24/06 3:22 PM >>> On Mon, Oct 23, Molle Bestefich wrote: > > >Although that includes a complete redesign of the exception store code. > > > > Especially when you say stuff like that :- ). > > > The chained- snapshots approach needs that too. In the chained snapshots, the only addition is a way to tell if an exception is to be preserved or can be written over. So for every disk-exception an additional field is required (Alasdair also recently suggested that we could use a bitmap to save space). So I would say this is not a major re-architecture of the disk exception structures but a simple (but incompatible) format change. > > >The throughput issues should be addressed by only > > >writing to one exception store. > > > > Wouldn't this make debugging more complex, and further add to > > the difficulty of snapshot resizing? > Resizing? Nope, you only need to resize the exception store thats it. Resizing > the chained- snapshots approach is complex however: in the worst case you have > to move the exception stores to get enough free space. I agree that there is work to be done while resizing. It seems simple to code though and can be done similar to a snapshot delete. If a snapshot is being resized, and will lose exception data, then we need to move the exception and data to the first snapshot after this snapshot in the write chain which has space to hold that data. Yes, data move is involved here. btw I couldn't figure out how resize will work with the common exception store approach. Can you please explain that in detail ? Thanks and Regards, Haripriya -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
