Subject: Re: bug#38435: BTRFS open_ctree failed

From: Maxim Cournoyer <[email-masked]>
Date: Tue, 18 Feb 2020 11:29:53 -0500

Hello,

Guillaume Le Vaillant <[email-masked]> writes:

> raingloom skribis:
>
>> This is what I get after a recent `guix system reconfigure` :
>> Scanning for Btrfs filesystems
>> [    2.342790] BTRFS error (device sda1): open_ctree failed
>>
>> Previous profiles work, I haven't modified anything about my config.scm
>> between them.
>>
>> [...]
>>
>>
>> Contents of /etc/profile.scm:
>>
>> [...]
>>
>>   (file-systems (cons* (file-system
>>                          (device (file-system-label "GUIX"))
>>                          (mount-point "/")
>> 			 (options "lazytime,compress")
>>                          (type "btrfs"))
>>                        ;(file-system
>>                        ;  (device (uuid "1234-ABCD" 'fat))
>>                        ;  (mount-point "/boot/efi")
>>                        ;  (type "vfat"))
>>                        %base-file-systems))
>>
>
> I just tried adding the 'lazytime' option to my root file system, and
> I got the same error as you when booting. Could you try removing it and
> see if it works?
>
> Until recently, the options declared in 'file-system' records were
> always ignored when mounting the root file system. Now they are taken
> into consideration, and I think it reveals a bug in the way file systems
> are mounted. If some options like 'lazytime' or 'defaults' are declared
> in a 'file-system' record (root file system or not), mounting it fails.
> However some other options like 'compress' or 'autodefrag' work fine.
>
> I suspect Guix adds some options by default when trying to mount file
> systems, and maybe we end up with conflicting options or doubled options
> that cause problems.

The problem here is that "lazytime" is a file system independent mount
options (see FILESYSTEM-INDEPENDENT MOUNT OPTIONS in 'man 8 mount'),
which is not understood by the Btrfs file system driver itself.

Currently Guix targets mount(2) through its file-system record API,
although this could be easily abused before (because the options were
not passed to the `mount-file-system' calls that the init RAM disk
uses).

This leaves some work to be done though, as if we target mount(2), we
need some glue code to translate mount(2) flags into mount(8) file
system independent mount options (otherwise you wouldn't be able to have
'lazytime' in your /etc/fstab).

I have a partial solution posted for review here:
https://lists.gnu.org/archive/html/guix-patches/2020-02/msg00382.html,
in the patch:
https://lists.gnu.org/archive/html/guix-patches/2020-02/msg00382.html.
Currently it filters out the file system independent mount options
before passing the options to `mount-file-system'.

Comments or patches welcome!