[PATCH] btrfs: Use default subvolume as filesystem root

Qu Wenruo wqu at suse.com
Wed Sep 1 16:01:46 CEST 2021



On 2021/9/1 下午9:48, Matthias Brugger wrote:
> 
> 
> On 01/09/2021 13:36, Tom Rini wrote:
>> On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote:
>>> Hi Tom,
>>>
>>> On 02/08/2021 01:06, Qu Wenruo wrote:
>>>>
>>>>
>>>> On 2021/8/2 上午4:52, Matwey V. Kornilov wrote:
>>>>> BTRFS volume consists of a number of subvolumes which can be mounted separately
>>>>> from each other. The top-level subvolume always exists even if no subvolumes
>>>>> were created manually. A subvolume can be denoted as the default subvolume i.e.
>>>>> the subvolume which is mounted by default.
>>>>>
>>>>> The default "default subvolume" is the top-level one, but this is far from the
>>>>> common practices used in the wild. For instance, openSUSE provides an OS
>>>>> snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
>>>>> filesystem is located into a separate subvolume which is "default" but not
>>>>> "top-level". That means that the /boot/dtb/ directory is also located inside
>>>>> this default subvolume instead of top-level one.
>>>>>
>>>>> However, the existing btrfs u-boot driver always uses the top-level subvolume
>>>>> as the filesystem root. This behaviour 1) is inconsistent with
>>>>>
>>>>>       mount /dev/sda1 /target
>>>>>
>>>>> command, which mount the default subvolume 2) leads to the issues when
>>>>> /boot/dtb cannot be found properly (see the reference).
>>>>
>>>> I also noticed the problem in the past, but forgot to fix it....
>>>>
>>>>>
>>>>> This patch uses the default subvolume as the filesystem root to overcome
>>>>> mentioned issues.
>>>>>
>>>>> Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
>>>>> Signed-off-by: Matwey V. Kornilov <matwey.kornilov at gmail.com>
>>>>
>>>> Reviewed-by: Qu Wenruo <wqu at suse.com>
>>>>
>>>
>>> I can see that this patch is marked in your patchwork queue as "Need Review /
>>> ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart from
>>> that we have it running on openSUSE on top of v2021.07 for some time without any
>>> issues.
>>
>> Ah, yup.  Qu is one of the people I do look for to have reviewed a btrfs
>> patch before I apply it (and I throw things under Need Review / ACK as a
>> note-to-self to make sure a patch does have one, when I can expect one,
>> before applying, FWIW).
>>
>>> Would it be possible to merge this for v2021.10 or do you see any blocker here?
>>
>> I think I had mentally filed it was feature not bugfix and was going to
>> hold off, but since you're asking, yes, I can grab it for this release.
>> Thanks!
>>
> 
> It's a bugfix, as loading files from BTRFS, at least in openSUSE does not work
> without it.

Just to be extra accurate, the original code always accesses subvol 5 as 
the entrance point, thus for openSUSE or any other distros setting other 
default subvolume, this will cause behavior difference between kernel 
and u-boot, thus unable to find the correct /boot path.

This problem is cause by my rework using btrfs-progs code. All my fault.

Btrfs-progs never needs to bother the default subvolume, as it has no 
way to "mount" the fs nor explore the directories/files structure.

Thus it's a regression, and I'm not sure if we should use Fixes: tag.

Just in case, the fixes tag is:

Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from 
btrfs-progs")

Thank all guys involved in this case.
Qu

> 
> Thanks for the quick answer!
> Matthias
> 



More information about the U-Boot mailing list