What happened here (btrfs issue maybe?)

I have mostly avoided “btrfs”. But I decided that it was time to give it a fair try.

So I recently installed Leap 15.1 Beta in a KVM virtual machine with a 50G virtual disk. I configured the VM for “virtio” video, since QXL seems to be broken. And I set the install to use UEFI. Beyond that, I mostly took the defaults. So I ended up with “btrfs” for the root file system, and with “/home” as a subvolume of that “btrfs” system. That was perhaps a week ago.

Yesterday, I booted it up, and updated to the lastest release (with “zypper dup”). It now seems to be a release candidate (the “Beta” has disappeared from the name). I installed enigmail and Thunderbird. I uploaded “.thunderbird” from my main desktop. And I checked whether “enigmail” was working (it was).

Then I shutdown. And I noticed a “fail to unmount” message on shutdown. It went too fast to read. So I booted it up again. And the VM was hopelessly slow. It took about 5 minutes for the boot menu to show up. At that point, I forced it off. Several retries, and the same every time. But other VMs started normally, so it wasn’t an obvious failure of virt-manager and associated software.

I connected a recent 15.1 iso as a virtual DVD, and booted that iso. That booted fine. So the virtual machine itself seemed to be working. It was just grub2 from the installed 15.1 that was ridiculously slow.

I booted that iso to the rescue system. Once in the rescue system, I did:


mount /dev/sda2 /mnt   ### mount the btrfs root file system
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

I’ll note that the “btrfs” root file system mounted without any problems.

Continuing, I did:


chroot /mnt
mount -a  ### mount everything within the chroot environment
exit  ### leave the "chroot" environment

Again, this all went smoothly and quickly. The “df” command showed that all of the subvolumes were properly mounted.

So I rebooted, without having actually done anything other than mounting the “btrfs” file system.


umount -R /mnt
shutdown -r now

The system rebooted just fine. The grub menu from the installed system now worked properly. It was no longer ridiculously slow.

I really don’t know what happened. My guess is that there was a problem with the “btrfs” file system, and mounting then unmounting it was enough to fix it. But that’s only a guess.

That VM is now working just fine again. But it does look as if there’s a “FAIL to unmount /var” on every shutdown.

This leaves me with concerns about “btrfs”. However, if this was a “btrfs” problem, then I’m surprised at how easy it was to fix.

Questions like this, even if you resolve yourself should be posted to the Virtualization forum…

I recommend that you click on the little triangle icon at the bottom of any post in this thread, the tool tip should say “Report post” but you just want to send a message to a Forum Admin requesting that this thread be moved to the Virtualization forum.

TSU

Whoops,
Didn’t take another look at who you are… Sorry :slight_smile:

Still recommend moving to Virtualization forum, and you should provide which virtualiztion (KVM? Xen?)

Personally, I suspect that you had a dirty unmount, and BTRFS may have actually auto repaired inconsistencies without requiring you to run an fsck.

You’re describing what might be a problem so if you have time, if the boot log can be extracted (or the problem replicated and then generate a bootlog) for inspection, that might be valuable.

TSU

I’m doubting that it is a virualization issue.

On rethinking, I’m inclined to see it as an issue with how grub accesses “btrfs” file systems.

If I look in “grub.cfg”, I find this line:

echo "Please press t to show the boot menu on this console"

On a real machine, I rarely see that “press t” line. It is quickly overwritten by the menu. On a virtual machine, if I look closely I can see that line, but it is quickly overwritten by the menu.

On a virtual machine using “btrfs”, that line lingers for a bit longer before being overwritten. And how long it lingers seems to vary. The amount of time it takes is possibly a measure of how many disk blocks that grub has to read to get to the menu.

I have not seen a repeat of a several minute delay. But the delay is still more apparent with “btrfs” and more variable with “btrfs”.

I have the suspicion that, a Btrfs file system, after the initial installation, needs some time to get itself sorted out …
Possibly, “btrfs balance start -dusage=85 /” and “btrfs balance start -musage=70 /” have to be executed to, help “it” get itself sorted out somewhat more quickly than, the default …
BTW: “btrfs df /”, please …
And, I have absolutely no idea as to why, Btrfs is considered to be a “better” filesystem for a normal, everyday, maintained, Desktop system.
And, I can’t prove, yet, that it’s not so wonderful with SSHD (hybrid) Laptop drives …

You might be right. It is behaving pretty well now.

BTW: “btrfs df /”, please …

That just tells me that I got the command syntax wrong.

And, I have absolutely no idea as to why, Btrfs is considered to be a “better” filesystem for a normal, everyday, maintained, Desktop system.

I think that’s supposed to be because of the rollback ability. But I cannot imagine ever using that in normal usage.

Of course, I will experiment with that as a test, just before I delete this virtual machine. That will probably be when the official 15.1 release comes out.

You were probably looking for this:


# btrfs fi df /
Data, single: total=14.01GiB, used=12.89GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=680.12MiB
GlobalReserve, single: total=39.59MiB, used=0.00B