I've noticed that for a while now any btrfs partition that I setup that uses multiple devices will not mount on boot, always giving me the same error about an invalid filesystem. However, I don't have this problem with a single device btrfs partition. If I add `btrfsctl -a` to scan for btrfs devices to /etc/init.d/localmount right before it tries to mount everything in /etc/fstab then everything works fine. I'm not sure if this bug has to go upstream or not to the btrfs devs. Reproducible: Always Steps to Reproduce: 1. Create a multi device btrfs partition 2. Add the btrfs partition to /etc/fstab 3. Reboot the system Actual Results: Error that the btrfs partition is not valid Expected Results: The btrfs partition should mount
This may be related to a know race condition that occurs at boot time for btrfs, as noted on the btrfs wiki (https://btrfs.wiki.kernel.org/index.php/Gotchas).
i cant see this being a bug in baselayout/openrc if btrfs needs weird boot handling, it should write an init.d script like all the other packages (mdadm/device-mapper/etc...) for people to use or it's a bug in the kernel
The btrfs kernel module packages are going away soon - very outdated, so any init.d action would need to take place in the btrfs-progs package. However, this does look like a kernel btrfs issue, and as it's still experimental, things like this are not surprising. If you get a chance, can you post the specifics of your issue to the btrfs mailing list? They are very responsive. If there's something we could/should do in the progs package, I'll be glad to look into that.
I believe that using btrfsctl -a is the accepted solution from upstream on this. Btrfs stores some state internally about the devices in multi-device configurations, and this doesn't get populated until either the array is scanned with btrfsctl -a, or the filesystem is mounted using one particular disk. I agree that this should be fixed, but it'll need to be fixed upstream; not a lot that can be done about it from inside Gentoo.
(In reply to comment #4) > I believe that using btrfsctl -a is the accepted solution from upstream on > this. Btrfs stores some state internally about the devices in multi-device > configurations, and this doesn't get populated until either the array is > scanned with btrfsctl -a, or the filesystem is mounted using one particular > disk. > > I agree that this should be fixed, but it'll need to be fixed upstream; not a > lot that can be done about it from inside Gentoo. > You can see the message I sent to the btrfs mailing list and the reply I received at http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04639.html Looks like upstream will implement the needed stuff later on, the workaround is the accepted practice in the mean time.
Hey,thanks for researching. So I wonder where the recommended place for this command (btrfsctl -a) is. Obviously, modding an /etc/init.d file is not ideal at all.
[hat type="kernel-misc,base-system"] lavajoe: add your own init.d script per below and in init.d/localmount, we can add 'use btrfs'. Does the command need to be run before fsck as well, or just before mount? [/hat]
(In reply to comment #7) > [hat type="kernel-misc,base-system"] > lavajoe: > add your own init.d script per below and in init.d/localmount, we can add 'use > btrfs'. > > Does the command need to be run before fsck as well, or just before mount? > [/hat] > I never needed to scan before fsck'ing before, but it has been a while; I can't really break my system at the moment to find out.
Bugs #303529 and #303531 are related to this bug. They propose genkernel patches for detecting btrfs volumes and multiple root devices which carry same UUIDs (e.g. btrfs raid0 volumes).
Convenience links: bug 303529 and bug 303531 - sorry for not including them in my previous post.
I put 'btrfsctl -a' on line 22 in init.d/localmount for the time being.
This bug is fairly old now. Any new information on proper fixes?
Resolving this as "needs info" for now. If any new info is available, please reopen. Otherwise I'll consider this but old and not an issue anymore.
