Re: booting btrfs

[Michael Chang]

2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 20.12.2013 10:46, Michael Chang wrote:
>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
>>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>>>> В Mon, 28 Oct 2013 01:44:26 +0100
>>>> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:
>>>>
>>>>> I changed in trunk to make / refer to real root and modified
>>>>> grub-mkrelpath to follow the same convention, even if disk is mounted
>>>>> with subvolid.
>>>>>
>>>>
>>>> Can it cause compatibility issues? It means if config file that works
>>>> for grub before this change will stop working after. So e.g. attempt to
>>>> "configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>>>>
>>> Normally I'd consider this a problem but the current behaviour is the
>>> intended one, just back when the code was written thre were no changing
>>> default yes
>>>> May be subvolume support should use different syntax. Something like
>>>>
>>>> (hd0,1){sv=subvolume}/xxx
>>>> (hd0,1){svid=NNN}/yyy
>>>>
>>> This would complicate the code a lot and commit us to maintaining it
>>> long-term. Given that btrfs isn't clasified as stable, I consider this
>>> behaviour change acceptable and it's better to handle this now rather
>>> than perpetuating the issue.
>>
>> Please consider the case if a snapshot was taken against real root fs
>> tree to a subvolume with SNAPSHOT_ID. With syntax above providing
>> mount option support we can possibly boot that snapshot with this
>> config.
>>
>>   set root=(hd0,1){svid=<SNAPSHOT_ID>}
>>   set prefix=($root)/boot/grub2
>>   normal
>>
>> Without the syntax support it's almost impossible to do that. At lease
>> I can't figure out any.
>>
> Every volume has a name, even if you don't know it. Use grub-mkrelpath
> to find out.

That means we need to modify the grub,cfg in snapshot to make files
used by config refer to new path output by grub-mkrelpath (relative to
real root), right ? That could be difficult to manage especially if
you have a lot of snapshots and the update takes time to finish.

Compare to use path relative to snapshot's fs root, we can leave the
grub.cfg in snapshot unmodified and by setting snapshot id or name in
a master config to switch the snapshot we want to boot. That will make
things a lot easier.

>> Besides we may leverage that mount option support in grub-mount to
>> test/develop and so on. For modern innovative file systems the mount
>> option support is becoming necessary for dealing many different use
>> cases.
>>
> This is feature request without usecase. As such it's rejected
> automatically.

Probably a case is in os-prober, we can use that feature to have
grub-mount test subvolumes without resorting to linux mount. But I
admit that the gain is little.

Regards,
Michael

>> Thanks,
>> Michael
>>
>>>> And continue to interpret old syntax as relative to default.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Grub-devel mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>