On Sun, Jun 28, 2020 at 3:11 PM Tom Seewald <tseew...@gmail.com> wrote:
> > For btrfs, it's raid0 data, raid1 metadata.
> Surely this is considered a serious installer bug? Users who choose an option 
> called "raid1" with btrfs would, and should, expect to have data redundancy.

The context of that is: the default when the user does not specify. If
the user chooses 'raid1' in the installer, they get 'raid1' for both
data and metadata.

When you merely choose 2+ devices and use custom partitioning's
"autopartition" option for the Btrfs preset. (a) the UI doesn't show
the profile (single, dup, raid0, raid1, raid10) being used. (b)
mkfs.btrfs default for the multiple device case,  which is raid0 data,
raid1 metadata. If you go look for this, you can certainly set it to
raid1 and then you'll get raid1.

This further relates to the automatic partitioning behavior because
(a) it accepts multiple devices (b) there is a default (c) you can't
see what it is and you can't change it. I'm pretty sure it's rare for
people to pick 2+ devices and then do automatic partitioning. But it
is handled, and what you get depends on the installer default (file

LVM = LVM linear across all devices selected, with ext4 on /home and /
LV's. i.e. linear/concat
Btrfs = raid0 data, raid1 metadata across all devices selected.

The confusing part for 100% of new users to Btrfs is the split between
data (file contents) and metadata (the file system itself). In these
two examples, they both lack meaningful redundancy. What does it mean
for btrfs to have raid1 metadata, but raid0 data in the face of device
failure? Well, it means the file system is still working normally, but
hunks of your files are missing in 64KiB sized strips. Some will read
some won't. But raid0 is faster than linear (called 'single' profile
on btrfs) so it's probably fine leaving it as is.

Chris Murphy
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to