Hacker News Reader

Comment by ippa | Hacker News Reader

Been waiting for raid5 with btrfs!

How stable is btrfs at this point?

They say we must wait a little longer...

I use it full time on my Desktop and my Laptop. It glitches fairly often but nothing unrecoverable. You'll mostly run into issues if you run out of space. Also there's some weird side effects with improper shut-down that you should note. Btrfs tends to leave some stuff in my logs too, but nothing that actually lost data, normally I see the error after a brief lockup in the system.

On that note about running out of space, an interesting thing you have to keep in mind with btrfs is that, as a snapshotting filesystem you can't simply unlink files to free up space. They're still present and taking up space in a previous snapshot.

There's ways to free up space for real but you have to manually use some tools to do it from what I understand.

> glitches

Panic? OOPS?

Mainly oops left in my logs, one or two panics on shutdown. Once a panic when I was doing something silly with my uni research project.

Pity I can't report these really, tainted (AMD) kernel.

I'm using it on two machines (both running arch-linux, so it's typically only one week behind kernel.org kernel releases or so), and I have not noticed data loss or corruptions, even though I crash these machines from time to time (with btrfs-unrelated things).

The ability to make daily snapshots effortlessly is godsent on my tinkering computer (so I can rollback whatever stupid idea I came up with), and on a slow laptop with a even slower 2.5" PATA harddisk, I at least have the illusion of a performance improvement by LZO compression causing less disk-accesses.

Raid5 is not really a good idea. See BAARF[1] (battle against raid five/four) for some reasoning.

[1]: http://www.baarf.com/

I've read a little bit of the material, but I don't get the feeling that they looked beyond block-level RAID5/6 (which btrfs/raid5, as far as I understand, is not).

[1] mentions that RAID5 never checks parity on read, which is not an issue with ZFS/zpool (and, I think, the proposed BTRFS/raid5) because they verify all read blocks' check sum. Also the creeping multiplication of bit-errors on parity rebuild is a non issue because of this. [2] only mentions ZFS, but attributes copy-on-write as the remedy against distribition of bad data over the RAID volume.

[1]: http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt

[2]: http://www.miracleas.com/BAARF/Why_RAID5_is_bad_news.pdf

And, yes, I see this silent corruption problem, and the inabilty to identify the "wrong" drive in case of parity mismatch as a big deficit of block-level RAIDs, and I share their view on the abysmally bad performance of some degraded/rebuilding arrays. But that is mainly what the filesystem-integrated redundancy mechanism try to address with their "blatant layering violation".

Yeah, I don't think they cover raidz or raidz2. raidz is not exactly raid5, in the classic sense, because as you mention zfs does checksum verification.

I wasn't sure what btrfs (or the parent) meant by 'raid5'. I think zfs was wise to call it something else.

Reply on news.ycombinator.com