Bug 866101 - redundancy selection for btrfs device results in raid0, not raid1
Summary: redundancy selection for btrfs device results in raid0, not raid1
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH RejectedBlocker
Depends On:
Blocks: F18Blocker, F18FinalBlocker F18Beta-accepted, F18BetaFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-10-14 00:04 UTC by Chris Murphy
Modified: 2012-11-08 09:21 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-11-08 09:21:18 UTC
Type: Bug

Attachments (Terms of Use)
program log (20.56 KB, application/octet-stream)
2012-10-14 00:04 UTC, Chris Murphy
no flags Details
anaconda-tb log (367.13 KB, application/octet-stream)
2012-10-14 00:05 UTC, Chris Murphy
no flags Details
anaconda-tb log (367.13 KB, text/plain)
2012-10-14 00:06 UTC, Chris Murphy
no flags Details
program log (20.56 KB, text/plain)
2012-10-14 00:07 UTC, Chris Murphy
no flags Details
program.log, smoke11 includes anaconda-18.18 (27.16 KB, text/plain)
2012-10-18 05:06 UTC, Chris Murphy
no flags Details
all *.logs (44.94 KB, application/x-compressed)
2012-10-24 22:18 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2012-10-14 00:04:44 UTC
Created attachment 626713 [details]
program log

Description of problem:
It is not possible to create a RAID 1 BTRFS device. When choosing Device Type BTRFS and selecting redundancy, a RAID 0 BTRFS volume is created instead.

Version-Release number of selected component (if applicable):
anaconda 18-16

How reproducible:

Steps to Reproduce:
1. Boot from netinst.iso
2. Choose two 80GB disks, and option to customize partitioning.
3. In Manual Partitioning, click on automatic partitioning (baseline).
4. Click on Home, change Device Type to BTRFS with Redundancy checked.
5. Click on Root, change Device Type to BTRFS with Redundancy checked.
6. Click Finish Partitioning.
Actual results:
(Crash. Reported separately as Bug 864765.)
The resulting btrfs volume is metadata raid1, data raid0.

Expected results:
Resulting btrfs volume should be metadata and data, raid1.

Additional info:
anaconda.tb and program.log indicate the command used to create the volume is:
mkfs.btrfs --label=fedora_f18v /dev/sda2 /dev/sdb1

should be:
mkfs.btrfs --label=fedora_f18v -d raid1 /dev/sda2 /dev/sdb1

When mounted, 'btrfs fi df /mnt' indicates the volume is data RAID 0.

Comment 1 Chris Murphy 2012-10-14 00:05:51 UTC
Created attachment 626714 [details]
anaconda-tb log

Comment 2 Chris Murphy 2012-10-14 00:06:38 UTC
Created attachment 626715 [details]
anaconda-tb log

Comment 3 Chris Murphy 2012-10-14 00:07:11 UTC
Created attachment 626716 [details]
program log

Comment 4 Chris Murphy 2012-10-14 00:09:24 UTC
Propose as blocker: Fedora 18 Beta Release Criterion #11. The installer must be able to create and install to software RAID-1.

Contra-argument is that md raid1 works, and the release criteria don't explicitly state that btrfs raid1 is a requirement. The resulting filesystem, while data raid0 not raid1, would be workable for the purposes of beta testing, despite this bug. For F18beta, I'm -1 blocker, +1 NTH; For F18Blocker, I'm +1 blocker.

Comment 5 David Lehman 2012-10-17 13:22:28 UTC
Please try again with anaconda-18.17-1. BTRFS raid options in the UI were very messed up in 18.16 and earlier.

Comment 6 Adam Williamson 2012-10-17 17:36:37 UTC
Discussed at 2012-10-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-17/f18beta-blocker-review-4.2012-10-17-16.00.log.txt . We agreed that this is yet another area that needs clarification in the criteria: when it was written, "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" clearly meant 'mdraid' when it talked about 'software RAID', but Chris argues strongly that in fact, the term covers btrfs-with-redundancy just as well as it covers mdraid.

Still, for F18 purposes we agreed to take the original intent of the criterion rather than a strict interpretation as it applies to currently available technologies, so since btrfs-with-redundancy is not what we meant by 'software RAID' at the time, this is rejected as a blocker. It's accepted as NTH as changes should only affect btrfs devices and this would be a useful fix to have for Beta.

For F19, we should clarify the criteria.

Comment 7 Chris Murphy 2012-10-18 04:53:30 UTC
Not fixed in anaconda-18.18-1. Checkboxes aren't sticking, resulting file system for two disks is still data raid0, not raid1.

Comment 8 Chris Murphy 2012-10-18 05:06:55 UTC
Created attachment 629153 [details]
program.log, smoke11 includes anaconda-18.18

Command still is missing -d raid1: 00:59:04,007 INFO program: Running... mkfs.btrfs --label=fedora_f18v /dev/sda2 /dev/sdb1

Comment 9 Adam Williamson 2012-10-24 01:06:53 UTC
Confirming this is still valid in 18.19.

I set up a VM with two disks, a 15GB and a 10GB, blank. I went to custom partitioning and created the partitions 'automatically', which gave me a 500MB /boot, a 14GB / , and 4GB of swap. I picked the / partition and set it to Device Type BTRFS and checked the checkbox for 'redundancy'; even though this should cause it to reduce to a max size of 10GB or so it didn't reduce the displayed size of the partition or pop up a warning or anything, it let me complete partitioning and run the install.

After install I booted the installed system. It seems anaconda created a 10GB partition on the first disk and a 10GB partition on the second disk and combined them into a single...volume?...and mounted it as /. I verified with 'btrfs filesystem df /' (thanks chris murphy) that the / partition says:

'Data, RAID0'
'Metadata, RAID1'

indicating it's storing the data striped, not redundant. 'df -h' shows the / partition as 20GB in size, further confirming this. Like in Chris' test, there is no '-d raid1' passed to mkfs.btrfs in the program.log.

Setting back to assigned.

Comment 10 Adam Williamson 2012-10-24 01:30:21 UTC
this probably fails "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above", so nominating as a Final blocker too.

Comment 11 David Lehman 2012-10-24 21:30:12 UTC
Logs would help.

Comment 12 Chris Murphy 2012-10-24 21:48:58 UTC
program.log and anaconda-tb.log attached to this bug; which other logs would you like? At the moment anaconda 18.19 Redundancy checkbox doesn't stay checked.

Comment 13 Chris Murphy 2012-10-24 22:18:37 UTC
Created attachment 633057 [details]
all *.logs

All *.log files at installation completion, in /tmp.

Redundancy checkbox won't stay checked. Unchecks in between clicking between Root and Boot. Also unchecks itself upon clicking the Apply button.

Comment 14 Adam Williamson 2012-10-24 23:21:21 UTC
I didn't notice it doing that, but I'll re-do my install, watch the checkbox, and get logs too.

Comment 15 Adam Williamson 2012-10-24 23:21:56 UTC
erm, if you're installing from a live image, you can't change the filesystem for / , can you? that's one of the known limitations of live installs...

Comment 16 Chris Murphy 2012-10-24 23:31:00 UTC
(In reply to comment #15)
That's oldui, because the install image was ext4, then resized to fit /. With newui they're doing it differently, presumably to support either ext4 or btrfs live installs. I end up with a completely valid bootable raid0 btrfs only install for boot root and home on subvols. It's just that it should be raid1.

Comment 17 David Lehman 2012-10-25 00:06:10 UTC
(In reply to comment #15)
> erm, if you're installing from a live image, you can't change the filesystem
> for / , can you? that's one of the known limitations of live installs...

It has nothing to do with newui specifically, but the live backend was rewritten for F18 and this limitation was removed.

Comment 18 Fedora Update System 2012-11-01 02:50:46 UTC
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.

Comment 19 Adam Williamson 2012-11-01 06:17:18 UTC
Heh, I'm learning stuff from this bug.

So I did an install following the procedure outlined above with smoke13. 'btrfs filesystem df /' says DATA, RAID1: total=4.00GB used=2.63GB. So that looks like it's working. Funnily, 'df -h' reports rootfs Size: 20G Used: 5.8G Avail: 13G. So I think df doesn't understand btrfs RAID1 - it reports a filesystem twice as large as it should be (20G not 10G), with twice as much data on it as btrfs df. But that's a bug in df, probably, it seems like my test verifies this is fixed.

The behaviour of the custom part screen here still seems problematic - I just changed a 15GB partition to Device Type btrfs, with redundancy checked, and then the screen variously claimed it was either 15GB or 20GB in size, but gave me a 10GB RAID-1 device in the end. But that's another separate report. Setting VERIFIED.

Comment 20 Chris Murphy 2012-11-01 14:57:42 UTC
anaconda 18.22-1 in smoke13 appears to fix this bug. I get a raid1 btrfs volume.

(In reply to comment #19)
re: how df works vs 'btrfs fi df /' there are recent discussions on linux-btrfs.org list about improving btrfs fi df, and also about the "doubling" effect. In some respect the question of file system size is perspective. For e.g. ext4 on md raid, you're right, the file system isn't 20GB but 10GB and "duplicated" by the md layer. But in btrfs that's not what happens, the file system is 20GB and files using the raid1 data profile take up twice as much space (on in each of mirrored chunks on different devices); it's expected that per subvolume and even per file data profiles can be applied, and same for compression options. So it seems to make more sense to treat the volume/pool as the true size that it is, since the various data profiles apply to the data, not the volume.

Comment 21 Fedora Update System 2012-11-01 18:26:07 UTC
Package anaconda-18.22-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2012-11-02 04:05:14 UTC
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.

Comment 23 Fedora Update System 2012-11-03 01:04:46 UTC
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.

Comment 24 Fedora Update System 2012-11-06 01:39:55 UTC
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.

Comment 25 Fedora Update System 2012-11-07 02:11:52 UTC
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.

Comment 26 Adam Williamson 2012-11-08 09:21:18 UTC
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).

Note You need to log in before you can comment on or make changes to this bug.