wow, holy shit, thanks for this extended answer!
> The first thing to point out here again is that it's not btrfs-specific.
so that mean that every RAID implemantation (with parity) has such Bug? I'm
looking a bit, it looks like that ZFS doesn't have a write hole. And it _only_
happens when the server has a ungraceful shutdown, caused by poweroutage? So
that mean if I running btrfs raid5/6 and I've no poweroutages I've no problems?
> it's possible to specify data as raid5/6 and metadata as raid1
does some have this in production? ZFS btw have 2 copies of metadata by
default, maybe it would also be an option or btrfs?
in this case you think 'btrfs fi balance start -mconvert=raid1 -dconvert=raid5
/path ' is safe at the moment?
> That means small files and modifications to existing files, the ends of large
> files, and much of the
> metadata, will be written twice, first to the log, then to the final
> location.
that sounds that the performance will go down? So far as I can see btrfs can't
beat ext4 or btrfs nor zfs and then they will made it even slower?
thanks in advanced!
best regards
Stefan
On Saturday, September 8, 2018 8:40:50 AM CEST Duncan wrote:
> Stefan K posted on Fri, 07 Sep 2018 15:58:36 +0200 as excerpted:
>
> > sorry for disturb this discussion,
> >
> > are there any plans/dates to fix the raid5/6 issue? Is somebody working
> > on this issue? Cause this is for me one of the most important things for
> > a fileserver, with a raid1 config I loose to much diskspace.
>
> There's a more technically complete discussion of this in at least two
> earlier threads you can find on the list archive, if you're interested,
> but here's the basics (well, extended basics...) from a btrfs-using-
> sysadmin perspective.
>
> "The raid5/6 issue" can refer to at least three conceptually separate
> issues, with different states of solution maturity:
>
> 1) Now generally historic bugs in btrfs scrub, etc, that are fixed (thus
> the historic) in current kernels and tools. Unfortunately these will
> still affect for some time many users of longer-term stale^H^Hble distros
> who don't update using other sources for some time, as because the raid56
> feature wasn't yet stable at the lock-in time for whatever versions they
> stabilized on, they're not likely to get the fixes as it's new-feature
> material.
>
> If you're using a current kernel and tools, however, this issue is
> fixed. You can look on the wiki for the specific versions, but with the
> 4.18 kernel current latest stable, it or 4.17, and similar tools versions
> since the version numbers are synced, are the two latest release series,
> with the two latest release series being best supported and considered
> "current" on this list.
>
> Also see...
>
> 2) General feature maturity: While raid56 mode should be /reasonably/
> stable now, it remains one of the newer features and simply hasn't yet
> had the testing of time that tends to flush out the smaller and corner-
> case bugs, that more mature features such as raid1 have now had the
> benefit of.
>
> There's nothing to do for this but test, report any bugs you find, and
> wait for the maturity that time brings.
>
> Of course this is one of several reasons we so strongly emphasize and
> recommend "current" on this list, because even for reasonably stable and
> mature features such as raid1, btrfs itself remains new enough that they
> still occasionally get latent bugs found and fixed, and while /some/ of
> those fixes get backported to LTS kernels (with even less chance for
> distros to backport tools fixes), not all of them do and even when they
> do, current still gets the fixes first.
>
> 3) The remaining issue is the infamous parity-raid write-hole that
> affects all parity-raid implementations (not just btrfs) unless they take
> specific steps to work around the issue.
>
> The first thing to point out here again is that it's not btrfs-specific.
> Between that and the fact that it *ONLY* affects parity-raid operating in
> degraded mode *WITH* an ungraceful-shutdown recovery situation, it could
> be argued not to be a btrfs issue at all, but rather one inherent to
> parity-raid mode and considered an acceptable risk to those choosing
> parity-raid because it's only a factor when operating degraded, if an
> ungraceful shutdown does occur.
>
> But btrfs' COW nature along with a couple technical implementation
> factors (the read-modify-write cycle for incomplete stripe widths and how
> that risks existing metadata when new metadata is written) does amplify
> the risk somewhat compared to that seen with the same write-hole issue in
> various other parity-raid implementations
