GNU bug report logs - #44196
Problems with /gnu/store in a different btrfs subvolume

Previous Next

Full log

Message #72 received at 44196 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 44196 <at> debbugs.gnu.org
Subject: Re: bug#44196: [PATCH 2/3] system: Add store-directory-prefix to
 boot-parameters.
Date: Mon, 02 Nov 2020 19:52:18 +0100

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:
> (Btrfs no0b here.)  Does that mean that /gnu is like a bind-mount of
> /gnufs in this case?

Yes, it's exactly like that for the end user, but that use case isn't
implemented yet---it should be useful too for the Hurd and
translators---so I have it under my radar.

> Anyway, I think I got it now, but I feel I’ll have to search again for
> this example next time I stumble upon it.  ;-)

I also linked this report on the commit message, as it's a non-trivial
use case and everybody could need as much info as possible if an error
hits---fingers crossed.

>> Writing the last email I though about adding this:
>> ------------------------------------------------------------------------------
>>    ;; OS's root file system, so it might be a device path like "/dev/sda3".
>> +  ;; The 'store-directory-prefix' field contains #f or the actual path of
>> +  ;; the store inside the 'store-device' as seen by GRUB, e.g. it would
>> +  ;; contain "/storefs" if the store is located in that subvolume of a btrfs
>> +  ;; partition.
>>    (root-device      boot-parameters-root-device)
>>    (bootloader-name  boot-parameters-bootloader-name)
>>    (bootloader-menu-entries                        ;list of <menu-entry>
>>     boot-parameters-bootloader-menu-entries)
>>    (store-device     boot-parameters-store-device)
>>    (store-mount-point boot-parameters-store-mount-point)
>> +  (store-directory-prefix boot-parameters-store-directory-prefix)
>> ------------------------------------------------------------------------------
>
> s/path/file name/, but otherwise LGTM.

I've pushed this change as 2df44e934c9ba14a89d9245d1a4f7cf18e8cfdaa with
changes on the rest of the comment as well, as the wording was the same,
as I agree that path should refer to a route (where there could be
several concrete locations/file names in unix dialect), and file name
should be the correct term.

> Thanks for working on these changes!

Thanks to you for the review, for me this is useful in my daily life (as
now I can manage btrfs better too, hehe) and much fun! :-)

Happy hacking!
Miguel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.