Blacklisting insecure filesystems in openSUSE

Posted Feb 9, 2019 3:57 UTC (Sat) by jeffm (subscriber, #29341)
In reply to: Blacklisting insecure filesystems in openSUSE by mangix
Parent article: Blacklisting insecure filesystems in openSUSE

We ship btrfs as the default root file system for SLE12 and SLE15 on all architectures including s390x, which is big endian. The hiccups we have encountered aren't endian related, but rather in the way s390x handles page dirtying. I haven't seen an s390x-specific btrfs bug in some time and it's not for lack of deployments.

Blacklisting insecure filesystems in openSUSE

Posted Feb 9, 2019 6:15 UTC (Sat) by mangix (guest, #126006) [Link] (5 responses)

I have. From kernel 3.18 to 4.19.

Blacklisting insecure filesystems in openSUSE

Posted Feb 9, 2019 14:41 UTC (Sat) by mageta (subscriber, #89696) [Link] (4 responses)

Did you report them? I've been using btrfs with SLES12 and 15 on s390x for 3+ years now (as it is the default filesystem on SLES), and have not seen a single panic/warning, or at least I can't remember one. I didn't use any advanced features like raid and such, but at least snapshots worked also fine.

Blacklisting insecure filesystems in openSUSE

Posted Feb 9, 2019 19:46 UTC (Sat) by mangix (guest, #126006) [Link]

I've previously reported the f2fs error. No comment. The code actually has several endian related bugs from a quick glance at fsck output as well as the code.

Reported the btrfs issue just now. Given that my issue has probably been there for a long time, I'm not hopeful.

Blacklisting insecure filesystems in openSUSE

Posted Feb 11, 2019 13:58 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

RAID56 is not just "advanced". It's red on Status page. And always was red. The fact that people are trying to use it (and are then burned) so often makes me wonder: why attempt to use it does not cause warning in CAPITAL LETTERS from kernel?

Blacklisting insecure filesystems in openSUSE

Posted Feb 15, 2019 16:46 UTC (Fri) by jhhaller (guest, #56103) [Link] (1 responses)

The btrfs status page gives a high level view of RAID56, the details are more subtle. There are a combination of issues related to the write hole potentially corrupting metadata, and no unclean dismount flags suggesting a log replay is needed. But if one uses RAID10 for metadata and RAID 5 for data, the problem should be no worse than other filesystems when there is an unclean dismount. RAID 6 doesn't really support multi-drive failure when the metadata is RAID 10, as one can only lose one drive before there is a possibility of data loss in the RAID 10 metadata. The most recent status is a thread in the email archives here: https://lore.kernel.org/linux-btrfs/5d7f63b2-d340-7c3a-67... - follow the thread.

Blacklisting insecure filesystems in openSUSE

Posted Feb 15, 2019 19:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I have just lost data from a btrfs RAID5 NAS. We had power outages going and the external enclosure was b0rked by it, causing drives to appear and disappear. BTRFS has corrupted the filesystem beyond repair.

I do have a secondary cloud backup so it's all good.

However, there's no way I'm going to trust btrfs with ANYTHING important.