5 ms·

I’m really confused what the author is trying to accomplish here. He sets a scenario that Btrfs openly says is known to cause issues. He doesn’t necessarily com

I’m really confused what the author is trying to accomplish here. He sets a scenario that Btrfs openly says is known to cause issues. He doesn’t necessarily come to the conclusion that one needs to trash Btrfs but I’m not sure why you would go through this exercise prior to deployment if the exercise is pitting an undeployable configuration against something that has already been heavily battle tested. Until Btrfs development marks the RAID5/6 write hole issue fixed this test is pointless. I’m a little disheartened to read all of the negative comments about Btrfs in this thread as well. I’ve spent a ton of time researching Btrfs in RAID 10 for deployment on my home lab (99% Linux environment) for when it’s time to expand storage and from everything I read it seemed like it was going to be a good idea. Now I’m back to wondering if I should research ZFS again.

viraptor 7y ago
I took it as: in an unsupported case this is what happens and these are the errors you get. It's useful information and makes the description easier to Google when you run across it.
cmurf 7y ago
I think you're best off using what you're familiar with, and keeping multiple backup copies of the important stuff. I've used Btrfs for 9-10 years and haven't ever had unplanned data loss. Planned, due to testing, including intentional sabotage, for bug reporting, yes. And in the vast majority of those cases, I could still get data off by mounting read-only. I use it for sysroot on all of my Linux computers, even the RPi, and for primary network storage and three backup copies. A fourth copy is ZFS. If you've had a negative experience, it can leave a bad taste in the mouth. People do this with food too, "I once got violently sick off chicken soup, I'll never eat it again." I wouldn't be surprised if there's an xkcd to the effect of how filesystem data loss is like food poisoning. There is a gotcha with Btrfs raid10, it's does not really scale like a strict raid 1+0. In that traditional case, you specify drive pairs to be mirrors, sometimes with drives on different controllers so if a whole controller dies, you still have all the other mirrors on other controller and the array lives on. You just can't lose two of any mirrored pair. Btrfs raid10 is not a raid at the block level, it's done at the block group level. The only guarantee you have with any size Btrfs raid10 is the loss of one drive.
- cmurf 7y ago
  Correction: Btrfs raid is not at the device level.
aeroevan 7y ago
I have been using btrfs in RAID 10 at home for several years with no issues. From what it sounds like, he didn't really have any issues with RAID 5, but btrfs scrub took longer than the ZFS equivalent. I'm even using btrfs with zstd compression on my laptop since it only has a small ssd (64 GB) and it makes it a lot more usable.

viraptor 7y ago

I took it as: in an unsupported case this is what happens and these are the errors you get. It's useful information and makes the description easier to Google when you run across it.

cmurf 7y ago

I think you're best off using what you're familiar with, and keeping multiple backup copies of the important stuff. I've used Btrfs for 9-10 years and haven't ever had unplanned data loss. Planned, due to testing, including intentional sabotage, for bug reporting, yes. And in the vast majority of those cases, I could still get data off by mounting read-only. I use it for sysroot on all of my Linux computers, even the RPi, and for primary network storage and three backup copies. A fourth copy is ZFS. If you've had a negative experience, it can leave a bad taste in the mouth. People do this with food too, "I once got violently sick off chicken soup, I'll never eat it again." I wouldn't be surprised if there's an xkcd to the effect of how filesystem data loss is like food poisoning. There is a gotcha with Btrfs raid10, it's does not really scale like a strict raid 1+0. In that traditional case, you specify drive pairs to be mirrors, sometimes with drives on different controllers so if a whole controller dies, you still have all the other mirrors on other controller and the array lives on. You just can't lose two of any mirrored pair. Btrfs raid10 is not a raid at the block level, it's done at the block group level. The only guarantee you have with any size Btrfs raid10 is the loss of one drive.

cmurf 7y ago
Correction: Btrfs raid is not at the device level.

aeroevan 7y ago

I have been using btrfs in RAID 10 at home for several years with no issues. From what it sounds like, he didn't really have any issues with RAID 5, but btrfs scrub took longer than the ZFS equivalent. I'm even using btrfs with zstd compression on my laptop since it only has a small ssd (64 GB) and it makes it a lot more usable.