btrfs subvolumes [was Re: Bugs and tasks for 2.02[~rc1] ]

btrfs subvolumes [was Re: Bugs and tasks for 2.02[~rc1] ]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Wednesday, April 13, 2016, Olaf Hering <olaf@aepfle.de> wrote:

> On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > On Wednesday, March 9, 2016, Olaf Hering <olaf@aepfle.de <javascript:;>>
> wrote:
> >     On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
> >     > I would like to come up with a complete list of 2.02 blockers in
> one week
> >     > time, so that we can have a reasonable timeline
> >     Did anyone took the time to fix btrfs support (convert it from
> handling
> >     btrfs as filesystem into that what it really is: a container of
> >     subvolumes)?
> > What is the problem with current approach? subvolume is little more than
> a
> > directory from a point of view of read-only implementation
>
> A root filesystem in a subvolume is kind of a chroot. For example
> grub.cfg within that subvolume references /boot/initrd. But upstream
> grub can not use such grub.cfg via 'configfile ($root)$subvol/grub.cfg'
> because the referenced path '/boot/initrd' does not take the subvolume
> path into account.  This breaks at least in pvgrub, and makes testing
> upstream grub with SLE12 or Leap impossible.
>
> Why does it break pvgrub? Both grub on BIOS and xen use the same
convention

> The changes made by SUSE tweak grub2 enough to take subvolumes into
> account. Not sure why these changes are missing upstream.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org <javascript:;>
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 2296 bytes --]

Re: btrfs subvolumes [was Re: Bugs and tasks for 2.02[~rc1] ]

[Michael Chang]

On Mon, Apr 18, 2016 at 06:22:10AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, April 13, 2016, Olaf Hering <olaf@aepfle.de> wrote:
> 
> > On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > On Wednesday, March 9, 2016, Olaf Hering <olaf@aepfle.de <javascript:;>>
> > wrote:
> > >     On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
> > >     > I would like to come up with a complete list of 2.02 blockers in
> > one week
> > >     > time, so that we can have a reasonable timeline
> > >     Did anyone took the time to fix btrfs support (convert it from
> > handling
> > >     btrfs as filesystem into that what it really is: a container of
> > >     subvolumes)?
> > > What is the problem with current approach? subvolume is little more than
> > a
> > > directory from a point of view of read-only implementation
> >
> > A root filesystem in a subvolume is kind of a chroot. For example
> > grub.cfg within that subvolume references /boot/initrd. But upstream
> > grub can not use such grub.cfg via 'configfile ($root)$subvol/grub.cfg'
> > because the referenced path '/boot/initrd' does not take the subvolume
> > path into account.  This breaks at least in pvgrub, and makes testing
> > upstream grub with SLE12 or Leap impossible.
> >
> > Why does it break pvgrub? Both grub on BIOS and xen use the same
> convention

It won't. But we have been using relative patch schemes to support booting
subvolumes via btrfs set-default to rollback changes.

> 
> > The changes made by SUSE tweak grub2 enough to take subvolumes into
> > account. Not sure why these changes are missing upstream.

Because there's could only be one path scheme at a time and upstream has
decided to settle on absolute path. I think unless in config level could
provide means to deal with subvolumes and its mount point information there
couldn't be a clean solution for that.

Thanks,
Michael

> >
> > Olaf
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org <javascript:;>
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> 
> -- 
> Regards
> Vladimir 'phcoder' Serbinenko

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel