Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] lvm snapshot cloning



> On Oct 24, 2011, at 8:41 PM, markw at mohawksoft.com wrote:
>>
>> With snapshots, its a bad design in that all snapshots receive all COW
>> blocks. So if you have two snapshots with the same basic content, there
>> will be duplicative data. This means that you have to allocate enough
>> space for the changes N times depending on the number of snapshots.
>
> This appears to be a bad design to you because you are thinking in terms
> of high-level file I/O.  And yes, I agree: it is very inefficient from the
> perspective of the high-level file system.  So don't do that.  Treat LVM
> volumes as simple block devices like I described.

I can't understand your perspective here. We have various RAID drivers, we
have linear drivers, sparse volumes, encrypted volumes, and so on. All
implemented at the block device level.

How are snapshots any more or less complex or problematic than a RAID5 or
encrypted block device?

I've posted proof that any performance degradation on LVM volumes with a
snapshot is only transient. You'll mostly never notice it in the real
world because its very unusual for large areas to undergo change in a
short period of time. Obviously, this is not an absolute, but it is
generally true.

For instance, writing a whole 1TB volume at 160MB/s (best case in October
2011, SATA/SAS) will take about 2 hours. Not that this would not happen in
some rare circumstance, but that's not typical.

I have not been able to find a good alternative. ZFS is stalled with
license issues and Btrfs is not stable. Both are under Oracle. LVM2 works
now and with a little finesse seems to do what is needed.

To address your concerns about it being a block device, I see this as
making the system more capable. You can put any file system you want on
it.

Isn't it better to improve what is stable and working rather than wait for
Oracle?




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org