• mholiv@lemmy.world
    link
    fedilink
    arrow-up
    12
    ·
    edit-2
    7 months ago

    As for “years away” I agree. As my first post said people should wait till you can use bcachefs in the stable distros. Debian isn’t getting kernel 6.7 any time soon 😆. So years away is right in any case.

    I think bcachefs addresses the reason why people don’t use SMR HDDs. (Aka changes resulting in cascading writes)

    You could have a data pool with the following tiers.

    Tier 1: SSDs

    Tier 2: HDDs

    Tier 3: SMR HDDs

    With bcachefs you would only ever write to your tier 1 storage. In the background, as able, bcachefs would offload the data from the faster lower tiers to the slower higher tiers based on frequency of data access.

    You would only ever read from the SMR HDDs and would never write to them. They act as a sort of async backing to your data.

    Personally I would love a data pool with a few SSDs, backed by a few HDDs, backed by many SMR HDDs. You would save so much money just with good architecting.

    Bcachefs should be a ZFS killer. All the features of ZFS with storage tiers being a superior version of ZFS’s L2arc with none of the DKIM kernel license incompatibility nonsense.

    • Lupec@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      Damn, I didn’t think to include SMR drives when it comes to bcachefs. Your whole comment made me appreciate the whole concept under a whole new light actually, thanks!