<div>If I may come to Geert's defense, his approach is more transparent: the PVs are accessible from user space and their content arrangement is clear by looking up the maps. Using snapshots puts everything into kernel space and deep into mystery land (unless there is some user space way of hand-manipulating COWs by sector number). I'm on the dm-devel list and they literally have dozens of patches a day... like raging ocean currents under your little, simple ship.</div>

<div> </div>
<div>Unfortunately, I can't answer Geert's practical questions. Anyone?</div>
<div> </div>
<div>Larry Dickson</div>
<div>Cutting Edge Networked Storage<br> </div>
<div><span class="gmail_quote">On 9/26/08, <b class="gmail_sendername">Stuart D. Gathman</b> <<a href="mailto:stuart@bmsi.com">stuart@bmsi.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">geert Geurts wrote:<br>> ps. for people interested, I'm trying to create a disk of allot of<br>> small virtual disks so I can create a encrypted partition on for<br>
> instance gmailfs and minimalize up/download time on changes.<br>> Pretty cool if it's possible no?<br>I think a better solution might be to keep the encrypted fs on a single<br>normal LV.  Take a snapshot and send to remote.  Keep the snapshot<br>
around.  On next upload, take a 2nd snapshot, and send the diff between<br>the two snapshots.  The diff can be efficiently computed from the COW<br>tables - accessible as dw-nn devices.  After sending the diff, delete<br>
the 1st snapshot and go back to "keep snapshot around".<br><br><br><br>_______________________________________________<br>linux-lvm mailing list<br><a href="mailto:linux-lvm@redhat.com">linux-lvm@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-lvm">https://www.redhat.com/mailman/listinfo/linux-lvm</a><br>read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/">http://tldp.org/HOWTO/LVM-HOWTO/</a><br>
<br></blockquote></div><br>