Created attachment 675872 [details] this is what it looks like when the install fails Description of problem: If you install Fedora 18 RC 2 and pick the BTRFS autopart scheme, not changing anything else, the install will proceed and then will fail once the package installation process starts. This happens because a BTRFS install needs more space (or perhaps the default software selection - GNOME Desktop - takes up more space now than when it was calculated for anaconda's logic) than the other installs so the space check in the GUI thinks there's enough space. When I ran into the issue (reliably reproduces everytime) this is the space needs output from /tmp/anaconda.log: disk free: 8.19 GB, fs free: 0 B, sw needs: 3 GB, auto swap: 4.03 GB
Use a larger disk? question is how large.
@Máirín Duffy I think this might be a DUP or a similar problem: * Bug 893331 - black screen after installation is complete (small HDD) I believe that it is not just than btrfs needs more space, sometimes the filesystem gets broken before becoming full, and it breaks "by pieces". I mean, you can create and delete files but not moving or renaming or deleting a hard-link, sometimes you cannot delete anything. So package scripts start to fail weirdly and in my case there is not even a message like yours, instead a xxxx package fails or black screen. I am still conducting tests and have not yet updated my bug-report but i will soon. Cheers.
Well, I think that bug is for btrfs's bad behaviour when it runs out of space, and this bug is for anaconda's space required calculation not being correct for btrfs. They're separate problems.
On a 7GB new virtual disk, on the Installation Summary "hub" page, I get a message saying an additional 470MB is needed. On an 8GB new virtual disk, installation gets to 100%, and then I get a distinctly different error: The following error occurred while installing. This is a fatal error and installation will be aborted. rsync exited with code 12. I accidentally hit space, and got a crash which libreport says bug 872936 is a duplicate using parent bug 868755. Without logs from Máirín, I don't know if she has encountered something distinctly different, or related. But I can't reproduce. However: [root@localhost ~]# btrfs fi show Label: 'fedora_f18v' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a Total devices 1 FS bytes used 2.87GB devid 1 size 3.57GB used 3.57GB path /dev/sda3 So the file system is 80% full. [root@localhost ~]# btrfs fi df /mnt/sysimage Data: total=2.69GB, used=2.69GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=438.94MB, used=183.36MB Metadata: total=8.00MB, used=0.00 And I get nothing in dmesg. The Btrfs file system may be "small" enough to be impractical, but I see no evidence that Btrfs itself has imploded.
Actually, I'm wrong. The file system no matter how you look at it is full. The results above I do find a little confusing, is it using 2.69 GB? or is it using 3.57GB? Well, it's the way Btrfs allocates data, system and metadata separately. Basically it has allocated all it can for data, and that allocation is full. So even though there's more room for metadata, you can't add anything.
Created attachment 677194 [details] anaconda-tb-
Created attachment 677195 [details] program.log Relevant last seconds of this install's life... 23:48:22,246 ERR program: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) 23:48:22,335 ERR program: rsync: connection unexpectedly closed (1815886 bytes received so far) [sender] 23:48:22,336 ERR program: rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
(In reply to comment #7) > Created attachment 677195 [details] > program.log > > Relevant last seconds of this install's life... > > 23:48:22,246 ERR program: rsync: writefd_unbuffered failed to write 4 bytes > to socket [sender]: Broken pipe (32) > 23:48:22,335 ERR program: rsync: connection unexpectedly closed (1815886 > bytes received so far) [sender] > 23:48:22,336 ERR program: rsync error: error in rsync protocol data stream > (code 12) at io.c(605) [sender=3.0.9] Code 12 can mean several things, but in this context it means "destination disk is full": http://rsync.samba.org/issues.html (See Question 3.)
Retested on a 9GB virtual disk and it works out fine. So here's how to explain the 8GB case, at least what I experienced, and probably what anaconda isn't accounting for. Btrfs allocates space into chunks. There are data and metadata chunks (the system chunks are small and can be ignored for practical purposes). This line: Metadata, DUP: total=438.94MB, used=183.36MB 439MB of volume space is allocated to metadata, data can't use this. Maybe from anaconda's perspective when it estimated, it thought it would have the extra bytes. 8GB post install: Data: total=2.69GB, used=2.69GB 9GB post install: Data: total=3.59GB, used=2.83GB So Btrfs needed to allocate another 900MB data chunk, just to write another 142MB of data, but couldn't with the 8GB disk. And it won't use the unused metadata allocation for data. So the file system was in fact full. I'd say the bug is that anaconda needs to add a notch in the belt for Btrfs when determining the minimum acceptable Btrfs volume size, by better taking into account its need for metadata space. I don't know that this needs to be put in Commonbugs. I don't think it's common. In maybe 100+ Btrfs installs I never encountered this, but then the only time I use an 8GB virtual disk is when there's no swap (VM install doesn't need swap).
Further information, this line from 'btrfs fi df' has a secret decoder ring value inserted into it. Metadata, DUP: total=438.94MB, used=183.36MB The DUP means the metadata is mirrored, and in actuality the total allocation for metadata (which is thus not available to data) is twice the total= value, and the on-disk used amount is twice the used= value. This further emphasizes that the issue is anaconda is underestimating how much metadata BTRFS needs to allocate, and that it's separate from the data allocation. Upstream conversation on linux-btrfs@ suggests that for file systems 32GB and smaller, or better "any filesystem that you expect to normally run within half a gb of full" should have a Btrfs volume created with the -M flag. This mixes data and metadata, so that they can share all available space. As a consequence, the data/metadata profiles (single, dup, raid1, raid0, raid10) must be the same for data and metadata. More in this thread: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg21151.html Anyway, I still feel it's obscure enough to not be included in CommonBugs.
Chris, do you really think this bug is obscure if it hits every user that configures BTRFS autopart (whether or not they go into custom partitioning)?
The F18 Installation Quick Start Guide hasn't been published yet, but the minimum disk space requirement for F17 is 10 GB: The computer on which you intend to install Fedora 17 from the live CD should have: a CD or DVD drive, and the capability to boot from this drive. a 400 MHz processor or faster at least 1 GB of memory (RAM) at least 10 GB of permanent storage (hard drive) space. Installation Quick Start Guide 2. Requirements http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Quick_Start_Guide/Requirements.html
Mairin: so far as I can tell, you only hit this bug if you happen to have a fairly narrow range of disk space available (enough that anaconda's check thinks you have sufficient, but not enough that you *actually* have sufficient space). It's not going to hit very many people at all. Most btrfs installs will be fine.
(In reply to comment #11) > Chris, do you really think this bug is obscure if it hits every user that > configures BTRFS autopart (whether or not they go into custom partitioning)? I have done over 50 Btrfs installs, maybe 1/2 dozen were autopart installs. I only encountered this bug by reading proposed CommonBugs and tried to reproduce it with an 8GB virtual disk. I can't reproduce it with a 9GB, 10GB, 20GB, 80GB, 100GB, 2 or 3TB virtual disk. I can't reproduce it on a 500MB real disk. So I don't understand why/how you're saying it hits every user that uses BTRFS autopart. If you can reproduce it on a virtual disk >= 10GB, then I'd like to see a step by step and some logs to see what the X factor is.
If we have some evidence this hits people with more reasonably sized disks, I'd be happy to take a look into this. However for now it looks like it's likely to only hit people with pretty small devices, perhaps even below the recommendations in our own documentation. And we've got a lot of other stuff to do, so I don't think we're going to be able to spend time here.