Re: strangely uncorrectable errors with RAID-5

[Russell Coker <russell@coker.com.au>]

On Monday, 21 October 2024 08:01:52 AEDT Qu Wenruo wrote:
> The metadata is gone, and there is only one mirror for it.
> 
> What profile are you using for metadata?

# btrfs fi df /mnt
Data, RAID5: total=4.92GiB, used=1.21GiB
System, RAID5: total=48.00MiB, used=16.00KiB
Metadata, RAID5: total=864.00MiB, used=172.77MiB
GlobalReserve, single: total=6.95MiB, used=0.00B

It's all RAID5.  Why would it be all gone?  Also why can't it be recreated 
when diff doesn't report any file loss?  Can I convert a BTRFS filesystem from 
this state to an all good state?

As an aside I've had something quite similar happen on a production server 
running Ubuntu 20.04 and RAID-1 and now I'm just running it knowing that a 
scrub will give errors but that it apparently works.

> Just in case, RAID5 is not recommended for metadata due to the complex

From what I know it's still not recommended for anything though.  But 
definitely if I didn't want to have data loss and I wanted RAID-5 then I'd use 
RAID-1 for metadata.  But in this case I was more interested in seeing how it 
might break than in keeping the data intact.

> recovery combinations:
>  >> The power failure safety for metadata with RAID56 is not 100%.
> 
> I'm pretty sure if you're using RAID5 for metadata, that's exactly the
> case where corrupted metadata can not be properly fixed at a per-sector
> basis.
> 
> Thus it's recommended to go RAID1* for metadata if you want to use RAID5
> for data.

OK.  I'll run some new tests on RAID1 metadata and RAID5 data and see how that 
goes.

Is there any way of recovering the filesystem with those errors or is mkfs 
required?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/