All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Goffredo Baroncelli <kreijack@libero.it>" <kreijack@libero.it>
To: <hpa@zytor.com>, cwillu <cwillu@cwillu.com>
Cc: <helmut@hullen.de>, <linux-btrfs@vger.kernel.org>
Subject: R: Re: Subvolumes and /proc/self/mountinfo
Date: Wed, 20 Jun 2012 14:02:22 +0200 (CEST)	[thread overview]
Message-ID: <32353828.234981340193742067.JavaMail.defaultUser@defaultHost> (raw)

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


             reply	other threads:[~2012-06-20 12:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20 12:02 Goffredo Baroncelli <kreijack@libero.it> [this message]
2012-06-20 15:37 ` R: Re: Subvolumes and /proc/self/mountinfo H. Peter Anvin
2012-06-20 16:34   ` Goffredo Baroncelli
2012-06-20 17:41     ` H. Peter Anvin
2012-06-20 18:06       ` Goffredo Baroncelli
2012-06-20 19:15         ` Helmut Hullen
2012-06-20 20:22           ` Goffredo Baroncelli
2012-06-20 21:49         ` H. Peter Anvin
2012-06-21  5:47           ` Goffredo Baroncelli
2012-06-21 11:46             ` Martin Steigerwald
2012-06-21 17:05               ` Goffredo Baroncelli
2012-06-21 13:38             ` H. Peter Anvin
2012-06-21 17:05               ` Goffredo Baroncelli
2012-06-21 17:11                 ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2012-06-20 12:10 Goffredo Baroncelli <kreijack@libero.it>
2012-06-20 11:51 Goffredo Baroncelli <kreijack@libero.it>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32353828.234981340193742067.JavaMail.defaultUser@defaultHost \
    --to=kreijack@libero.it \
    --cc=cwillu@cwillu.com \
    --cc=helmut@hullen.de \
    --cc=hpa@zytor.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.