On 06/19/2012 06:16 PM, cwillu wrote:
>>> The big reason it isn't here yet is because Kay had this neat patch
>>> to blkid and udev to just put all the info you need into /dev/btrfs
>>> (or some other suitable location). It would allow you to see which
>>> devices belong to which filesystems etc.
>>
>> "btrfs" should work even without any "udev" installation.
>
> It does; you can always mount with an explicit -o
> device=/dev/foo,device=/dev/bar if you're inclined to punish
> yourself^w^w^w^w^w your requirements dictate that you don't rely on
> udev.
I think you're misunderstanding what this is about.
I'm working on trying to make the Syslinux installer for btrfs as robust
as it possibly can be. I really don't like leaving corner cases where
it will do the wrong thing and leave your system unbootable.
Now, that having been said, there are a lot of things that are not
really very clear how they should work given btrfs. Specifically, what
is needed is:
1. The underlying device(s) for boot block installation.
2. A concept of a root.
3. A concept of a path within that root to the installation directory,
where we can find syslinux.cfg and the other bootloader modules.
All of this needs to be installed in the fixed-sized boot block, so a
compact representation is very much a plus.
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 btrfs, a lot of things aren't so clear-cut, especially in the light
of explicit and implicit subvolumes. Furthermore, sorting out these
semantic issues is really important in order to support the "atomic
update" scenario:
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;
e. Install the bootloader on the snapshot, thereby making the boot
block point to it and making it "live".
If the root also contains subvolumes, e.g. /boot may be a subvolume
because it has different policies, this gets pretty gnarly to get right.
It is also a very high value to get right.
So it is possible I'm approaching this wrong. I would love to have a
discussion about this.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
