Why I'm going to use btrfs

    • OMV 4.x
    • Resolved
    • Why I'm going to use btrfs

      Hi all,

      after I tried out actually every omv-supported file systems able to handle more than one HDDs in a single volume, from my humble opinion there remain only two file systems, that are reasonable so far: ZFS, the non-Linux mother and btrfs, her real Linux child.

      I will use btrfs in future, as it supports an implicit RAID5 or RAID6 like ZFS. And even if already hear the cry: "But the write hole...." Sorry, but the write hole is an issue not only of btrfs, but of ZFS as well, and in fact of *every* RAID (raid-recovery-guide.com/raid5-write-ole.aspx) Think it's not really difficult to understand: *Any* redundant saving needs at least two writes to disk to be fulfilled. Which must occure at exatcly at the same time at the platters involved, if a sudden power outage shoudl do no harm. But which OS existing can guarantee this? And even if the OS would do it - how can we be sure, that our disks write their buffered date at the same time? Or at least in the time, they still have, to do anything, if power suddenly fails?

      So there is a write hole not only by theory, but by hardware. And there is only one solution: a UPS able to let the drives write all data they got before shut down. With today's drives buffering 100MB or more we even cannot rely on BBUs on drive controllers no more. They only can save data not sent to the drives yet. But they cannot recover data, that are sent to the drive's buffers already.

      So what at all - to be safe, for every setup with >1 drives driven parallely we need uninterrupted power, as long as the writes last. And a UPS for the whole system is the only solution against write holes. Regardless, which file system and drive pool organisation we use.

      Btw: Btrfs is used quite normally for RAID5 and 6 setups by Synology and Rockstor. Both recommend to use a UPS. Of course.

      Btw2: I actually don't beleive, that the write hole ever can be closed. Neither in btrfs, nor in any other file system. Just think, this would need multiple disc writes and confirmation at the same time. I don't beleive this possible with a power fail inbetween.


      Thanks for reading my thoughts and

      Best regards,
      Der Jopa
      Private playground NAS: Asus P9D-I Board + Xeon E3-1220L CPU + 8GB ECC RAM + LSI SAS2108 HBA + upto 7 HDDs + OMV 4 booting from single SLC SSD drive
      Enterprise NAS: Asus CS-B Board + i3-4330T CPU + 4GB RAM + HP SC44Ge Controller + 3x3TB SATA RAID5 + 3x2TB SATA RAID5 + OMV 2.x booting from single SAS drive
    • Jopa wrote:

      So what at all - to be safe, for every setup with >1 drives driven parallely we need uninterrupted power, as long as the writes last
      Nope, since the write hole is only a thing with parity RAID (be it mdraid, RAIDz or btrfs' raid56). With mirrors it's not an issue and with storage topologies that allow to combine a bunch of mirrors (see here) this works really well. It also only affects operation in degraded mode so you 'only' need to fear power losses when you already lost a disk.

      Jopa wrote:

      I actually don't beleive, that the write hole ever can be closed
      That's what a log device is for (an SSD with a super capacitor). Fixed in mdraid since years and about to be fixed with btrfs raid56 sometimes in the future.
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • Hi Thomas,

      sorry, the link I included was bad - the "h" of "hole" was cut out somehow. So please look here and tell me, if you think, the author of this article (and coder of a disaster recovery software) did not understand the write hole issue...

      The articles on jr-s.net are quite informative - not only the one you linked - and I'll give them to my co-admin at company.

      BTW: I actually fear power losses at company, and some four or five years ago urged deciders to buy an UPS at least for our servers. Few month later a sudden outage killed the phone system, but not the server integrity. After power was back, most collegues could continue their work from local backups of open/libre office without any help. I only had to clean up the Windows Server for the ERP, because it had blocked a client, that was writing data, when outage occured. I don't even want to think about, what could have happen, if the Win Server had lost power as well.

      Best regards
      Private playground NAS: Asus P9D-I Board + Xeon E3-1220L CPU + 8GB ECC RAM + LSI SAS2108 HBA + upto 7 HDDs + OMV 4 booting from single SLC SSD drive
      Enterprise NAS: Asus CS-B Board + i3-4330T CPU + 4GB RAM + HP SC44Ge Controller + 3x3TB SATA RAID5 + 3x2TB SATA RAID5 + OMV 2.x booting from single SAS drive
    • Jopa wrote:

      So please look here and tell me, if you think, the author of this article (and coder of a disaster recovery software) did not understand the write hole issue...
      The write hole is explained properly but he only talks about primitive/anachronistic mirrors (like mdraid's raid1) which no-one right in his mind should use any more. With a btrfs raid1 or a zMirror this won't happen since checksums are there and the filesystems are CoW (copy on write). So even if one disk does not contain all data it's no problem since both filesystem and data will be intact. But this requires correct write barrier semantics working (see the Github issue I linked to above).
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • Hi Thomas,

      thank you for your replies, helping me to understand write hole issue another bit deeperly.

      Remains just one thing re this forum: How can I mark my thread as solved by my own, or must a moderator do it?

      Best regards
      Private playground NAS: Asus P9D-I Board + Xeon E3-1220L CPU + 8GB ECC RAM + LSI SAS2108 HBA + upto 7 HDDs + OMV 4 booting from single SLC SSD drive
      Enterprise NAS: Asus CS-B Board + i3-4330T CPU + 4GB RAM + HP SC44Ge Controller + 3x3TB SATA RAID5 + 3x2TB SATA RAID5 + OMV 2.x booting from single SAS drive
    • Users Online 1

      1 Guest