If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

I've been hearing about BTRFS for years, but it seems it is not fully stable, yet they throw new features with each kernel version... am I missing something ?

Not really, people work on what they want to work on. Someone on the dev team is gonna be OCD about fixing every bug, for someone else apparently the extents tree was too big for their uses / likes so they changed it, for someone else apparently quotas weren't working quite right so they changed them. All of the major issues about BTRFS have been worked out, im running it on my home server and the only thing that bugs me is there's no fsck.btrfs (but there is btrfsck) and grub-mkconfig freaks out about btrfs being split over two drives but it still properly makes the grub.cfg and boots just fine.

Comment

I use BTRFS on my large storage drives. i have a btrfs 'raid1' across 3x 3TB drives. btrfs checksums all the data, which gives me confidence that its safe. having the raid in the filesystem means that scrubs or repairs only needs to look at blocks that are actually used. it also means that if the 2 copies differ the filesystem knows which one is correct.

the only problem i have ever hit is when i moved added a second drive to an existing btrfs filesystem, and re-striped it to be raid1. I forgot (and the tools did not tell me) to make the metadata raid1 (it was still DUP). when I tried to replace one of the drives (due to SMART errors) there was not a full copy of the metadata on the second drive. I had to put the failing drive back in, re-stripe the metadata and then replace the disk. all went fine and no data was lost. but it would be nice if the tools made sure your metadata was at least as redundant as the data.