On 22/08/11 14:56, Robert Porter wrote: > The snapshot disk space only needs to hold the amount of the changed data - > not the whole filesystem. To the applications, it appears that a copy was > made, but actually writes are being held behind the scenes. Don't think I'm > explaining this well (Monday am), so lets try an example. Say that the UV DB > is 10GB and it will take 1 hour to back it up. During 1 hour, only 1GB of > data will be changed. The snapshot LV needs to be 1GB + a little for overhead > - not 10GB. If you do a df while snapshot'ed it appears that 2 10GB > partitions are mounted - the original and the snapshot. But the snapshot LV > is actually only holding the pending writes. Unmounting the snapshot writes > all the data (in order) to the real LV. While snapshot'ed the OS knows > what's changed and what hasn't and UV never knows the difference. > Interesting. The reason I suggested breaking the mirror was that mirroring is a common technique.
As for snapshotting, there's a new linux btree-based file system on the way. It's completely copy-on-write, so effectively it's always taking snapshots until it runs out of disk and needs to delete old snapshots to make room. I don't know much about it, but I know the idea has been around for ages. There was a filesystem called TuxFS that did this, but that never made it out of beta. I think the new one owes a lot of its ideas but none of its code to TuxFS. Cheers, Wol _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
