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 |
> 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 | |
We also thank MIT for the use of their facilities. |