4 ms·

Glad to see Btrfs getting continual updates. It's my favorite filesystem for my personal machines (work and home PCs). The feature set is just awesome. I just h

Glad to see Btrfs getting continual updates. It's my favorite filesystem for my personal machines (work and home PCs). The feature set is just awesome. I just hope it doesn't get completely abandoned as its development seems to have slowed significantly. The only thing it's missing before I consider it full-featured is stable RAID 5/6. But it looks like that hasn't been forgotten.

warmwaffles 4y ago
> The only thing it's missing before I consider it full-featured is stable RAID 5/6. But it looks like that hasn't been forgotten. I've been running BTRFS RAID6 since 2016 and have only had one issue (arch kernel needed to be rolled back) and never suffered anything catastrophic. It's perfectly happy humming along with a 15x8TB raid array.
- Tuna-Fish 4y ago
  Are you using Raid6 for both data and metadata? If yes, you could just as well have been running raid 0 and having more space and performance out of the same disks. Because of well documented issues, metadata on raid6 is not yet safe in power/hw failure situations. And if you have no safety in those situations, what is raid even for? (It's perfectly safe to run metadata on raid1 and data on raid5/6.)
  - ludocode 4y ago
    With data on raid6 you should be running metadata on raid1c3 or raid1c4, not raid1 nor raid5/6.
    - nwallin 4y ago
      Wait, what's wrong with metadata on raid1?
      - wtallis 4y ago
        Metadata on raid1 doesn't guarantee the resilience to two-drive failures that raid6 is used for, but metadata on raid1c3 does give you that degree of resilience (with more space overhead, but that's seldom a problem for the metadata).
  - warmwaffles 4y ago
    I'm running RAID6 for data and RAID1 for metadata. Wanted the metadata replicated. So far I've had no HW failure situations and I have suffered a few power outages while I was away from home even though I have a backup battery. Although these drives have surpassed 50,000 hours of running time, I am fairly certain the day of reckoning is coming, but I have backups and a plan to recover. I may recover to something not BTRFS. Not sure just yet.
_kdave 4y ago
The development speed has to balance the schedule of linux kernel development (merge window, release candidates, 3 months cycle) and demand to merge several distinct features or core changes. There are no formal deadlines but we have to make sure that the new code is feasible to be stabilized in the given time. Once a new feature is in the wild some bugs or fixups are still needed so this takes some time from the new development and has to be accounted for. My strategy to pull new things is to have one big feature that has ideally been reviewed and iterated in the mailinglist or there was a lot of testing already done. In addition two smaller features can be merged, with limited scope, not affecting default setup and possibly easy to debug/fix/revert if needed. Besides that there are cleanups or core updates going on so this should not touch the same code to make testing less painful. With new features the test matrix grows, code might need wide cleanups or generalizaionts before the actual feature code is merged. So this can indeed slow down development. The raid56 is progressing but until the 6.2 pull from today there was not much to announce regarding stability/reliability. There were proposed fixes but as incompatible features, which means some changes on the user side and with backward compatibility issues. What's pending for 6.2 should fix one of the bad problems at least for raid5.

warmwaffles 4y ago

> The only thing it's missing before I consider it full-featured is stable RAID 5/6. But it looks like that hasn't been forgotten. I've been running BTRFS RAID6 since 2016 and have only had one issue (arch kernel needed to be rolled back) and never suffered anything catastrophic. It's perfectly happy humming along with a 15x8TB raid array.

Tuna-Fish 4y ago
Are you using Raid6 for both data and metadata? If yes, you could just as well have been running raid 0 and having more space and performance out of the same disks. Because of well documented issues, metadata on raid6 is not yet safe in power/hw failure situations. And if you have no safety in those situations, what is raid even for? (It's perfectly safe to run metadata on raid1 and data on raid5/6.)
- ludocode 4y ago
  With data on raid6 you should be running metadata on raid1c3 or raid1c4, not raid1 nor raid5/6.
  - nwallin 4y ago
    Wait, what's wrong with metadata on raid1?
    - wtallis 4y ago
      Metadata on raid1 doesn't guarantee the resilience to two-drive failures that raid6 is used for, but metadata on raid1c3 does give you that degree of resilience (with more space overhead, but that's seldom a problem for the metadata).
- warmwaffles 4y ago
  I'm running RAID6 for data and RAID1 for metadata. Wanted the metadata replicated. So far I've had no HW failure situations and I have suffered a few power outages while I was away from home even though I have a backup battery. Although these drives have surpassed 50,000 hours of running time, I am fairly certain the day of reckoning is coming, but I have backups and a plan to recover. I may recover to something not BTRFS. Not sure just yet.

_kdave 4y ago

The development speed has to balance the schedule of linux kernel development (merge window, release candidates, 3 months cycle) and demand to merge several distinct features or core changes. There are no formal deadlines but we have to make sure that the new code is feasible to be stabilized in the given time. Once a new feature is in the wild some bugs or fixups are still needed so this takes some time from the new development and has to be accounted for. My strategy to pull new things is to have one big feature that has ideally been reviewed and iterated in the mailinglist or there was a lot of testing already done. In addition two smaller features can be merged, with limited scope, not affecting default setup and possibly easy to debug/fix/revert if needed. Besides that there are cleanups or core updates going on so this should not touch the same code to make testing less painful. With new features the test matrix grows, code might need wide cleanups or generalizaionts before the actual feature code is merged. So this can indeed slow down development. The raid56 is progressing but until the 6.2 pull from today there was not much to announce regarding stability/reliability. There were proposed fixes but as incompatible features, which means some changes on the user side and with backward compatibility issues. What's pending for 6.2 should fix one of the bad problems at least for raid5.