R: Re: Subvolumes and /proc/self/mountinfo

R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli <kreijack@libero.it>]

HI all,

>----Messaggio originale----
>Da: hpa@zytor.com
>Data: 20/06/2012 5.22
>A: "cwillu"<cwillu@cwillu.com>
>Cc: <helmut@hullen.de>, <linux-btrfs@vger.kernel.org>
>Ogg: Re: Subvolumes and /proc/self/mountinfo
>

>
>The concept of what is the "root" and what is the "path" is
>straightforward for lesser filesystems: the root of the filesystem is
>defined by the root inode, and the path is a unique sequence of
>directories from that root.  Note that this is completely independent of
>how the filesystem was mounted when the boot loader was installed.

For the aim of the discussion, I would like to highlight a small difference 
between the path of the subvolume and the subvolume-id.
The latter is the specific subvolume, the former is a "functional" reference
to this subvolume.

For example, in my root btrfs I have two two subvolumes: __active (the root 
filesystem of my system) and (__rollback the last "good" copy)

If I swap (via a rename) __active and __rollback, in the next boot my system
uses a "good" copy of the root filesystem. This is a simple way to swap 
two subvolumes, without involving the boot logic

Instead if I had tracked the subvolume-id, to swap the root filesystem I 
would have update the boot logic.

I suspect that could exists other cases where it is preferable to track the 
subvolume-id instead the path. However what I would highlight it is the two
ways aren't equal.

BR
G.Baroncelli

Re: R: Re: Subvolumes and /proc/self/mountinfo

[H. Peter Anvin]

On 06/20/2012 05:02 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:
> 
> If I swap (via a rename) __active and __rollback, in the next boot my system
> uses a "good" copy of the root filesystem. This is a simple way to swap 
> two subvolumes, without involving the boot logic
> 
> Instead if I had tracked the subvolume-id, to swap the root filesystem I 
> would have update the boot logic.
> 
> I suspect that could exists other cases where it is preferable to track the 
> subvolume-id instead the path. However what I would highlight it is the two
> ways aren't equal.
> 

Yes.  The question here is what makes sense for the low-level part of a
bootloader (Syslinux in this case) to use, and it sounds like you have
some experience here that would be highly useful to have.

The thing to keep in mind here is that the low level bootloader code
*must* match what is installed in the boot block (functionally another
part of the bootloader), or all hell will break loose.  I think that
means that relying on the subvolume ID makes more sense.  To upgrade the
bootloader, invoke the bootloader installer at the end of the update;
that will repoint *everything*, which is rather nice.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

On 06/20/2012 05:37 PM, H. Peter Anvin wrote:
> On 06/20/2012 05:02 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:
>>
>> If I swap (via a rename) __active and __rollback, in the next boot my system
>> uses a "good" copy of the root filesystem. This is a simple way to swap 
>> two subvolumes, without involving the boot logic
>>
>> Instead if I had tracked the subvolume-id, to swap the root filesystem I 
>> would have update the boot logic.
>>
>> I suspect that could exists other cases where it is preferable to track the 
>> subvolume-id instead the path. However what I would highlight it is the two
>> ways aren't equal.
>>
> 
> Yes.  The question here is what makes sense for the low-level part of a
> bootloader (Syslinux in this case) to use, and it sounds like you have
> some experience here that would be highly useful to have.
> 
> The thing to keep in mind here is that the low level bootloader code
> *must* match what is installed in the boot block (functionally another
> part of the bootloader), or all hell will break loose.  I think that
> means that relying on the subvolume ID makes more sense.  To upgrade the
> bootloader, invoke the bootloader installer at the end of the update;
> that will repoint *everything*, which is rather nice.


At the first I tough that having the /boot separate could be a good
thing. Unfortunately /boot contains both the bootloader code and the
kernel image. The kernel image should be in sync with the contents of
/lib/modules/....

This is the tricky point. If I handle /boot inside the filesystem
submodule a de-sync between the bootloader code and the boot sector
could happens. In I handle /boot as separate subvolume/filesystem a
de-sync between the kernel image and the modules could happens.

Anyway, from a bootloader POV I think that /boot should be handle
separately (or as filesystem or as subvolume identified by specific ID).
The best could be move the kernel in the same subvolume as /lib/modules,
so a switch of the subvolume as root filesystem would be coherent.


GB
> 
> 	-hpa
> 

Re: R: Re: Subvolumes and /proc/self/mountinfo

[H. Peter Anvin]

On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:
> 
> At the first I tough that having the /boot separate could be a good
> thing. Unfortunately /boot contains both the bootloader code and the
> kernel image. The kernel image should be in sync with the contents of
> /lib/modules/....
> 
> This is the tricky point. If I handle /boot inside the filesystem
> submodule a de-sync between the bootloader code and the boot sector
> could happens. In I handle /boot as separate subvolume/filesystem a
> de-sync between the kernel image and the modules could happens.
> 
> Anyway, from a bootloader POV I think that /boot should be handle
> separately (or as filesystem or as subvolume identified by specific ID).
> The best could be move the kernel in the same subvolume as /lib/modules,
> so a switch of the subvolume as root filesystem would be coherent.
> 

You're not really answering the question.   "The best could be move the
kernel in the same subvolume as /lib/modules" isn't really going to
happen... the whole *point* of /boot is that /boot contains everything
needed to get to the point of kernel initialization.

So, sorry, you're out to sea here...

	-hpa

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

HI,
On 06/20/2012 07:41 PM, H. Peter Anvin wrote:
> On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:
>>
>> At the first I tough that having the /boot separate could be a good
>> thing. Unfortunately /boot contains both the bootloader code and the
>> kernel image. The kernel image should be in sync with the contents of
>> /lib/modules/....
>>
>> This is the tricky point. If I handle /boot inside the filesystem
>> submodule a de-sync between the bootloader code and the boot sector
>> could happens. In I handle /boot as separate subvolume/filesystem a
>> de-sync between the kernel image and the modules could happens.
>>
>> Anyway, from a bootloader POV I think that /boot should be handle
>> separately (or as filesystem or as subvolume identified by specific ID).
>> The best could be move the kernel in the same subvolume as /lib/modules,
>> so a switch of the subvolume as root filesystem would be coherent.
>>
> 
> You're not really answering the question.   "The best could be move the
> kernel in the same subvolume as /lib/modules" isn't really going to
> happen... the whole *point* of /boot is that /boot contains everything
> needed to get to the point of kernel initialization.

??
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some advantages.

Few year ago there are some gains to have a separate /boot (ah, the time
when the bios were unable to address the bigger disk), where there are
the minimum things to bootstrap the system.

Now we have the possibility to move the kernel near the modules, and
this could lead some interesting possibility: think about different
linux installations, with an own kernel version and an own modules
version; what are the reasons to put together under /boot different
kernel which potential conflicting names ? de facto standard ?
historical reasons ? Nothing wrong here; but also the idea to moving the
kernel under /lib/modules is not so wrong.

> So, sorry, you're out to sea here...

True, the sea is far away from my house :-)

> 
> 	-hpa
> 
> .
> 

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Helmut Hullen]

Hallo, Goffredo,

Du meintest am 20.06.12:

[...]

> Am not saying that we *should* move the kernel away from /boot. I am
> only saying that having the kernel near /lib/modules *has* some
> advantages.

> Few year ago there are some gains to have a separate /boot (ah, the
> time when the bios were unable to address the bigger disk), where
> there are the minimum things to bootstrap the system.

> Now we have the possibility to move the kernel near the modules, and
> this could lead some interesting possibility: think about different
> linux installations, with an own kernel version and an own modules
> version; what are the reasons to put together under /boot different
> kernel which potential conflicting names ?

Where is the big problem?
I use separate subdirectories for different kernels, p.e. "/boot/ 
2.6.38.4" or "/boot/3.3.4" or "/boot/3.3.4-big". And these subdirs  
contain (p.e.) ".config", "vmlinuz", "initrd", "System.map".

It's a very clear design. No incredibly long filenames.

Viele Gruesse!
Helmut

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

On 06/20/2012 09:15 PM, Helmut Hullen wrote:
> Hallo, Goffredo,
Hi Helmut,

> 
> Du meintest am 20.06.12:
> 
> [...]
> 
>> Am not saying that we *should* move the kernel away from /boot. I am
>> only saying that having the kernel near /lib/modules *has* some
>> advantages.
> 
>> Few year ago there are some gains to have a separate /boot (ah, the
>> time when the bios were unable to address the bigger disk), where
>> there are the minimum things to bootstrap the system.
> 
>> Now we have the possibility to move the kernel near the modules, and
>> this could lead some interesting possibility: think about different
>> linux installations, with an own kernel version and an own modules
>> version; what are the reasons to put together under /boot different
>> kernel which potential conflicting names ?
> 
> Where is the big problem?
> I use separate subdirectories for different kernels, p.e. "/boot/ 
> 2.6.38.4" or "/boot/3.3.4" or "/boot/3.3.4-big". And these subdirs  
> contain (p.e.) ".config", "vmlinuz", "initrd", "System.map".
> 
> It's a very clear design. No incredibly long filenames.

Let me to explain my set-up.
My filesystem is in a subvolume; only /boot is in another filesystem.
Every time I upgrade, remove, or change the system I take a snapshot,
and regenerate the grub.cfg in order to take in account the new/old
subvolume (a script generates a menu entry for every subvolume, so I am
theoretically able to launch last kernel on every subvolume).

The point is that every snapshot could have a different set of kernel
module, depending by the upgrade history. Often the latest kernel cannot
boot^w work properly with old snapshot.

I am sure that there would be a lot of solutions, like:
- the script could be more smart, adding a grub menu entry only for
valid kernel/subvolume pairs
- the /boot filesystem could have a subdir for each subvolume
[...]

To me it seems that make sense to put the kernel near the /lib/modules
directories: the kernel is coupled with the modules, so why put them in
different three ? Today the modern bootloader could address the full
filesystem, so I don't see any reason to mandate the kernel to be under
/boot.

May be that there is another more rationale solution to my problem. I am
open to suggestions.
To me it was more traumatic the (re)moval of /sbin,/bin,/lib to
/usr/sbin,/usr/sbin,/usr/lib :-) [*]

Thanks
G.Baroncelli

[*] http://fedoraproject.org/wiki/Features/UsrMove

> 
> Viele Gruesse!
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 

Re: R: Re: Subvolumes and /proc/self/mountinfo

[H. Peter Anvin]

On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:
> 
> Am not saying that we *should* move the kernel away from /boot. I am
> only saying that having the kernel near /lib/modules *has* some advantages.
> 
> Few year ago there are some gains to have a separate /boot (ah, the time
> when the bios were unable to address the bigger disk), where there are
> the minimum things to bootstrap the system.
> 

There still is (in fact this exact problem has made a comeback, as there
are plenty of BIOSes which have bugs above the 2 TB mark); however,
there are also issues with RAID (firmware often cannot address all the
devices in the system -- and no, that isn't ancient history, I have a
system exactly like that that I bought last year), remote boot media
(your / might be on an iSCSI device, or even a network filesystem!) and
all kinds of situations like that.

The bottom line is that /boot is what the bootloader needs to be able to
address, whereas / can wait until the kernel has device drivers.  That
is a *HUGE* difference.

> Now we have the possibility to move the kernel near the modules, and
> this could lead some interesting possibility: think about different
> linux installations, with an own kernel version and an own modules
> version; what are the reasons to put together under /boot different
> kernel which potential conflicting names ? de facto standard ?
> historical reasons ? Nothing wrong here; but also the idea to moving the
> kernel under /lib/modules is not so wrong.

No, it is completely, totally and very very seriously wrong.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

On 06/20/2012 11:49 PM, H. Peter Anvin wrote:
> On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:
>>
>> Am not saying that we *should* move the kernel away from /boot. I am
>> only saying that having the kernel near /lib/modules *has* some advantages.
>>
>> Few year ago there are some gains to have a separate /boot (ah, the time
>> when the bios were unable to address the bigger disk), where there are
>> the minimum things to bootstrap the system.
>>
> 
> There still is (in fact this exact problem has made a comeback, as there
> are plenty of BIOSes which have bugs above the 2 TB mark); however,
> there are also issues with RAID (firmware often cannot address all the
> devices in the system -- and no, that isn't ancient history, I have a
> system exactly like that that I bought last year), remote boot media
> (your / might be on an iSCSI device, or even a network filesystem!) and
> all kinds of situations like that.
> 
> The bottom line is that /boot is what the bootloader needs to be able to
> address, whereas / can wait until the kernel has device drivers.  That
> is a *HUGE* difference

This leads to have a separately /boot filesystem. In this case I agree
with you: make sense that the kernel is near the bootloader files.

But if /boot has to be in a separate filesystem, which is the point to
support btrfs at all ? Does make sense to support only a subset of btrfs
features ?

> 
>> Now we have the possibility to move the kernel near the modules, and
>> this could lead some interesting possibility: think about different
>> linux installations, with an own kernel version and an own modules
>> version; what are the reasons to put together under /boot different
>> kernel which potential conflicting names ? de facto standard ?
>> historical reasons ? Nothing wrong here; but also the idea to moving the
>> kernel under /lib/modules is not so wrong.
> 
> No, it is completely, totally and very very seriously wrong.

When a bootloader (and the bioses) will be able to address the whole
diskS, this will change.. Not now

> 
> 	-hpa
> 

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Martin Steigerwald]

Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
> > 
> >
> >> Now we have the possibility to move the kernel near the modules, and
> >> this could lead some interesting possibility: think about different
> >> linux installations, with an own kernel version and an own modules
> >> version; what are the reasons to put together under /boot different
> >> kernel which potential conflicting names ? de facto standard ?
> >> historical reasons ? Nothing wrong here; but also the idea to moving
> >> the kernel under /lib/modules is not so wrong.
> >
> > 
> >
> > No, it is completely, totally and very very seriously wrong.
> 
> When a bootloader (and the bioses) will be able to address the whole
> diskS, this will change.. Not now

Why not the other way around? /boot/modules-3.4 or so.

But either way, these are different discussions. H. Peter´s question was, 
if I understood correctly, whether to use subvolid or path?

I tend to lean towards subvolid.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: R: Re: Subvolumes and /proc/self/mountinfo

[H. Peter Anvin]

On 06/20/2012 10:47 PM, Goffredo Baroncelli wrote:
> 
> This leads to have a separately /boot filesystem. In this case I agree
> with you: make sense that the kernel is near the bootloader files.
> 
> But if /boot has to be in a separate filesystem, which is the point to
> support btrfs at all ? Does make sense to support only a subset of btrfs
> features ?
> 

Yes, and that's another good reason for /boot: btrfs supports that kind
of policy (e.g. "no compression or encryption in this subtree.")

>>
>>> Now we have the possibility to move the kernel near the modules, and
>>> this could lead some interesting possibility: think about different
>>> linux installations, with an own kernel version and an own modules
>>> version; what are the reasons to put together under /boot different
>>> kernel which potential conflicting names ? de facto standard ?
>>> historical reasons ? Nothing wrong here; but also the idea to moving the
>>> kernel under /lib/modules is not so wrong.
>>
>> No, it is completely, totally and very very seriously wrong.
> 
> When a bootloader (and the bioses) will be able to address the whole
> diskS, this will change.. Not now
> 

People have said that for 15 years.  The reality is that firmware will
always be behind the curve, and *that's ok*, we just need to deal with it.

	-hpa

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

On 06/21/2012 01:46 PM, Martin Steigerwald wrote:
> Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
>>>
>>>
>>>> Now we have the possibility to move the kernel near the modules, and
>>>> this could lead some interesting possibility: think about different
>>>> linux installations, with an own kernel version and an own modules
>>>> version; what are the reasons to put together under /boot different
>>>> kernel which potential conflicting names ? de facto standard ?
>>>> historical reasons ? Nothing wrong here; but also the idea to moving
>>>> the kernel under /lib/modules is not so wrong.
>>>
>>>
>>>
>>> No, it is completely, totally and very very seriously wrong.
>>
>> When a bootloader (and the bioses) will be able to address the whole
>> diskS, this will change.. Not now
> 
> Why not the other way around? /boot/modules-3.4 or so.
> 
> But either way, these are different discussions. H. Peter´s question was, 
> if I understood correctly, whether to use subvolid or path?
> 

For which ?
If you want to point the bootloader subvolume (where the 2nd stage
relies), I suggest subvolid=. If you need to point to the kernel
(bzImage/initrd) *for my setup* it would be useful to use the path.
Unfortunately these two requirements are in contrast.

> I tend to lean towards subvolid.

> 
> Ciao,
Ciao
Goffredo

Re: R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli]

On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
>> But if /boot has to be in a separate filesystem, which is the point to
>> > support btrfs at all ? Does make sense to support only a subset of btrfs
>> > features ?
>> > 
> Yes, and that's another good reason for /boot: btrfs supports that kind
> of policy (e.g. "no compression or encryption in this subtree.")

But what about large disk ? Syslinux is able to handle large disk ? Or
it uses BIOS interrupt?

Re: R: Re: Subvolumes and /proc/self/mountinfo

[H. Peter Anvin]

On 06/21/2012 10:05 AM, Goffredo Baroncelli wrote:
> On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
>>> But if /boot has to be in a separate filesystem, which is the point to
>>>> support btrfs at all ? Does make sense to support only a subset of btrfs
>>>> features ?
>>>>
>> Yes, and that's another good reason for /boot: btrfs supports that kind
>> of policy (e.g. "no compression or encryption in this subtree.")
> 
> But what about large disk ? Syslinux is able to handle large disk ? Or
> it uses BIOS interrupt?

It uses the firmware.. how well the firmware can handle large disks is
another matter.
	-hpa



-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli <kreijack@libero.it>]

Hi All,

>----Messaggio originale----
>Da: list@fajar.net
>Data: 20/06/2012 8.31
>A: "H. Peter Anvin"<hpa@zytor.com>
>Cc: <linux-btrfs@vger.kernel.org>
>Ogg: Re: Subvolumes and /proc/self/mountinfo
>
>On Wed, Jun 20, 2012 at 10:22 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> a. Make a snapshot of the current root;
>> b. Mount said snapshot;
>> c. Install the new distro on the snapshot;
>> d. Change the bootloader configuration *inside* the snapshot to point
>>   to the snapshot as the root;

Or (as I wrote in an another replay), let the bootloader to start a subvolume 
identified by a path, and  swapping the subvolume via a simple rename.

>> e. Install the bootloader on the snapshot, thereby making the boot
>>   block point to it and making it "live".
>
>
>IMHO a more elegant solution would be similar to what
>(open)solaris/indiana does: make the boot parts (bootloader,
>configuration) as a separate area, separate from root snapshots. In
>solaris case IIRC this is will br /rpool/grub.
>
>A similar approach should be implementable in linux, at least on
>certain configurations, since if you put /boot as part of "/" (thus,
>also on btrfs), AND you don't change the default subvolume, AND the
>roots are on their own subvolume, the paths to vmlinuz and initrd on
>grub.cfg will have subvols name in it. So it's possible to have a
>single grub.cfg having several entries that points to different
>subvols. So you don't need to install a new bootloader to make a
>particular subvol live, you only need to select it from the boot menu.
>
>I'm doing this currently with ubuntu precise, but with
>manually-created grub.cfg though. Still haven't found a way to manage
>this automatically.

My /boot directory is an ext4 filesystem. During a "grup-update", I added an 
hook in the scripts which generates some entries for grub.cfg on the basis of 
the subvolumes which exist. Every entry is equal to the
default one but the options rootflags=subvol=<subvol>. So at the boot I can 
select different root (typicalli the default one and the one before an
aptitude update/upgrade)


Br
G.Baroncelli
>
>-- 
>Fajar
>--
>To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

R: Re: Subvolumes and /proc/self/mountinfo

[Goffredo Baroncelli <kreijack@libero.it>]

HI all,

>----Messaggio originale----
>Da: chris.mason@fusionio.com
>Data: 20/06/2012 1.49
>A: "H. Peter Anvin"<hpa@zytor.com>
>Cc: "linux-btrfs@vger.kernel.org"<linux-btrfs@vger.kernel.org>
>Ogg: Re: Subvolumes and /proc/self/mountinfo
>

>> b. Are there better ways (walking the tree using BTRFS_IOC_TREE_SEARCH?)
>> to accomplish this than using /proc/self/mountinfo?
>
>Not yet, but I'm definitely open to adding them.  Lets just hash out
>what you need and we'll either go through Kay's stuff or add ioctls for
>you.

Chris, what about adding a /sys/btrfs/<fs-uuid>/<subvol-id> interface ?

For example under

/sys/btrfs/<fs-uuid>

we can list the devices which btrfs uses

under 

/sys/btrfs/<fs-uuid>/<subvol-id> 

we can show/set the subvolume properties (like RO, compres....)

>
>-chris
>--
>To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>