Re: raid10 corruption while removing failing disk

[Martin Steigerwald <martin@lichtvoll.de>]

Nikolay Borisov - 10.08.20, 09:51:47 CEST:
> On 10.08.20 г. 10:38 ч., Martin Steigerwald wrote:
> > Hi Nikolay.
> > 
> > Nikolay Borisov - 10.08.20, 09:22:14 CEST:
> >> On 10.08.20 г. 10:03 ч., Agustín DallʼAlba wrote:
> > […]
> > 
> >>> # uname -a
> >>> Linux susanita 4.15.0-111-generic #112-Ubuntu SMP Thu Jul 9
> >>> 20:32:34
> >>> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> >> 
> >> This is a vendor kernel so you should ideally seek support through
> >> the vendor. This kernel is not even an LTS so it's not entirely
> >> clear which patches have/have not been backported. With btrfs it's
> >> advisable too use the latest stable kernel as each release brings
> >> bug fixes or at the very least (because always using the latest is
> >> not feasible) at least stick to a supported long-term stable
> >> kernel  - i.e 4.14, 4.19 or 5.4 (preferably 5.4)
> > 
> > The interesting thing with this recommendation is that it to some
> > part equals:
> > 
> > Do not use distro / vendor kernels.
> 
> On the contrary - it means to use kernels which have support for
> btrfs. Namely - Suse distributes kernels with btrfs + have developers
> who are familiar with the state of btrfs on their kernel. So if
> someone hits a problem on a Suse kernel  - they should report this to
> Suse and not the upstream mailing list. Suse's (or any other vendor
> for that matter) needn't look anything like the upstream kernel. Same
> thing with Fedora or Ubuntu. Since time is limited I (as an upstream
> developer) would prefer to spend my time where it would have the most
> impact - upstream and not spend possibly hours looking at some custom
> kernel.

While I get your argument and I bet SUSE support for BTRFS has improved 
a lot, I also still remember that SUSE supported BTRFS in SLES while it 
was still being unstable. With SLES 11 SP 2/3, not sure from memory 
which one it was, I had 2 GiB free in a BTRFS file system, yet got "no 
space left on device" with no ability to delete a file, remove a snapshot 
or do anything else about this, except to add a new virtual disk to 
BTRFS, delete something then. All of this happened cause the standard 
settings for Snapper created a huge lot of snapshots. I do not know how 
much for sure, but I made sure I had quite some free space as I 
installed SLES, knowing of free space related issues back then. All I 
did to trigger the failure condition was to install some OpenLDAP to do 
some example solutions for a training of mine and letting it sit over 
night. Next morning no remove desktop login anymore due to the out of 
space issue.

So my firm statement here is: SUSE used an instable version of BTRFS on 
this older SLES release. In my trainings I recommend at least SLES 12, 
preferably SLES 15 for BTRFS usage, preferable with latest service pack. 
I cannot prove it anymore, without installing such a VM again, cause I 
do not have that VM image anymore. But I remember what I have seen. With 
SLES 11 SP2/3 BTRFS was not really ready for production use – that was 
at least my experience.

So I still wonder: When is BTRFS in upstream to be considered stable 
enough to be used in distro kernels, at least when they are based on LTS 
kernels and updated to their latest releases regularly? I believe it 
would or should be by now. Or otherwise asked: Since which upstream LTS 
kernel can BTRFS be considered stable enough for *production use*?

My last issues had been around Linux 4.4 or 4.5. Since 4.6 I personally 
have no issues anymore… but what is upstream developers idea on this?

[…]
> > What would need to happen for it to be okay to use vendor kernels?
> > Is
> > there a minimum LTS version where you would say it would be okay?
> > 
> > I am challenging this standard recommendation here, cause I am not
> > sure whether for recent distribution releases it would still be
> > accurate or helpful. At some point BTRFS got to be as stable as XFS
> > or Ext4 I would think. Again, for me it is.
> > 
> > I have no idea why Ubuntu opted to use a non LTS kernel – especially
> > as 4.15 is pretty old and so does not sound to come from a
> > supported Ubuntu release unless it is some Ubuntu LTS release, but
> > then I'd expect a LTS kernel to be used –, but "-111" indicates
> > they added a lot of patches by now. So maybe they provide some kind
> > of LTS support themselves.
> All those are valid assumptions - however without direct experience
> with the Ubuntu kernel it's not entirely clear how accurate they are.
> Hence my recommendation to address Ubuntu kernel people because they
> should know best.

Fair enough. I get the recommendation to test against upstream kernel.

At the same you helped Agustín already with an idea that the Ubuntu 
kernel team may not have been aware of.

So I am still challenging any notion that people should not write to 
this list when they have trouble, even when they use some recent enough 
distribution kernel. My question though still is: What would be recent 
enough? 4.19, 5.4, 4.6, 5.7? When would upstream consider it to be 
recent enough to ask here?

At the same time of course you are free not to respond to a mail, in 
case you consider it too much trouble or time needed…

Ciao,
-- 
Martin