Hi Toby As I understand it, snapshots them selves use 0% disk space, but of cause the storage required to keep the copy will be locked, but because of the way it does this its still a very small amount of space. Cheers Mike On 6/02/12 12:20 PM, Toby Corkindale wrote:
On 05/02/12 19:13, Daniel Pittman wrote:
On Sat, Feb 4, 2012 at 23:30, Russell Coker<russell@coker.com.au> wrote:
On Sun, 5 Feb 2012, Daniel Pittman<daniel@rimspace.net> wrote:
Yes, it does good. For something like RAID-5 that has enough information to detect which device is wrong you can find and correct problems with the system. With a RAID-1 you can know that a device is returning bad data. You mean RAID-6. RAID-5 is no better than RAID-1 when it comes to determining which one of the disks is returning corrupt data. Sorry, yes, I did. I was thinking about that at the time I wrote it, then went back and edited. Obviously, poorly.
On Sun, 5 Feb 2012, Daniel Pittman<daniel@rimspace.net> wrote:
Yes. This is the substantial advantage that BTRFS and ZFS have over device-level RAID and LVM. The stronger checksums are useful because they can be checked inline with lower I/O cost, and the intimate knowledge of allocated space means you can check more quickly. Both very attractive features. https://btrfs.wiki.kernel.org/
The above URL lists mirroring as "Additional features in development, I don't think I can use this on serious servers for a while. Honestly, I wouldn't touch btrfs for some time. Last I heard overhead was still in the thirty to fifty percent range, which makes ZFS look nimble and efficient by comparison. ZFS looks significantly better, though it is still a little annoying to use on Linux, and Debian/KFreeBSD is annoying enough that I never got to testing it out seriously.
I've been giving ZFS a bit of a trial run on one of my servers, because the block-based deduplication looked attractive, as did the checksumming and using an SSD as L2 cache.
Unfortunately I ended up giving up -- it *seemed* pretty good on the surface, but I managed to kill the server too often. I ended up in a state where attempting to 'rm -rf' a (large) directory would cause the machine to spike up to over 100 load, and after 15+ minutes the hardware watchdog would reboot the machine because it'd become totally unresponsive, even to the console. Prior to these crashes, there'd be a bunch of log messages about kernel memory allocation failures.
I'm pretty sure this was because the memory required for the dedup hash map is huge -- gigabytes per terabyte of storage. Now, if that can't fit in RAM, then ZFS should just be paging it in from disk, which is slow, but shouldn't crash the machine. However in practice it did seem to kill it :(
I'm giving btrfs another go now; pity about losing the block-based dedup (which is great when you have a lot of virtual machine images), but the overhead just wasn't worth it for me.
One thing I'm already struggling to find in btrfs is simply to work out how much space a snapshot is consuming! Anyone?
-Toby _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main