From: Gabriel de Perthuis <g2p.code@gmail.com>
To: grub-devel@gnu.org, LVM2 development <lvm-devel@redhat.com>
Subject: Re: [PATCH] Install to LVM PVs
Date: Fri, 27 Sep 2013 15:56:40 +0200 [thread overview]
Message-ID: <52458E98.9000306@gmail.com> (raw)
In-Reply-To: <52457EA1.10804@gmail.com>
Le 27/09/2013 14:48, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :
> On 27.09.2013 12:39, Gabriel de Perthuis wrote:
>> Le 26/09/2013 10:53, Vladimir 'φ-coder/phcoder' Serbinenko a écrit:
>>> On 25.09.2013 14:39, Gabriel de Perthuis wrote:
>>>> Hello,
>>>> This patch lets grub install to a reserved area in LVM physical volumes.
>>>> These bootloader areas can be created with LVM 2.02.99 and the
>>>> --bootloaderareasize argument to pvcreate and vgconvert.
>>>> I tested it in QEMU, installing to and booting a disk that contains a PV
>>>> and no partition table.
>>>>
>>> This is not how the use of this area was imagined. There are couple of
>>> subtleties which your patch didn't take in account.
>>> Currently there is joint developpement with LVM guys but it wasn't
>>> published yet.
>>
>> For anyone else who may be interested, apparently patches exist and are
>> waiting for Peter Rajnoha to finish them. They haven't been posted or
>> discussed publicly and I've never seen them.
>>
>> According to Vladimir:
>>> the zone will be subdivided to cover more cases and the agreement was
>> to use "pvs" to get offsets rather than having own code for this
>>
>> As shipped in 2.02.99, pvs exposes exactly one ba_start/ba_size area.
>> Other areas will have to use extra extension fields and extra fields in
>> the pvs output, to be compatible with released versions of LVM.
> No, you didn't understand: this area will have another header, GRUB one
> which will subdivide it. LVM gives us area and we take care of subdivision.
Or you could split the task in two: embed Grub on PVs, like it does on
partition tables, ext2-ext4, Btrfs; then add advanced embedding that
does some mini-partitioning of embedding areas.
The first task is really easy and brings an immediate benefit in making
LVM-only disks bootable.
I don't feel qualified to discuss the second task, because I'm not
seeing the use case. I don't think it's been brought up.
WARNING: multiple messages have this Message-ID (diff)
From: Gabriel de Perthuis <g2p.code@gmail.com>
To: lvm-devel@redhat.com
Subject: [PATCH] Install to LVM PVs
Date: Fri, 27 Sep 2013 15:56:40 +0200 [thread overview]
Message-ID: <52458E98.9000306@gmail.com> (raw)
In-Reply-To: <52457EA1.10804@gmail.com>
Le 27/09/2013 14:48, Vladimir '?-coder/phcoder' Serbinenko a ?crit :
> On 27.09.2013 12:39, Gabriel de Perthuis wrote:
>> Le 26/09/2013 10:53, Vladimir '?-coder/phcoder' Serbinenko a ?crit:
>>> On 25.09.2013 14:39, Gabriel de Perthuis wrote:
>>>> Hello,
>>>> This patch lets grub install to a reserved area in LVM physical volumes.
>>>> These bootloader areas can be created with LVM 2.02.99 and the
>>>> --bootloaderareasize argument to pvcreate and vgconvert.
>>>> I tested it in QEMU, installing to and booting a disk that contains a PV
>>>> and no partition table.
>>>>
>>> This is not how the use of this area was imagined. There are couple of
>>> subtleties which your patch didn't take in account.
>>> Currently there is joint developpement with LVM guys but it wasn't
>>> published yet.
>>
>> For anyone else who may be interested, apparently patches exist and are
>> waiting for Peter Rajnoha to finish them. They haven't been posted or
>> discussed publicly and I've never seen them.
>>
>> According to Vladimir:
>>> the zone will be subdivided to cover more cases and the agreement was
>> to use "pvs" to get offsets rather than having own code for this
>>
>> As shipped in 2.02.99, pvs exposes exactly one ba_start/ba_size area.
>> Other areas will have to use extra extension fields and extra fields in
>> the pvs output, to be compatible with released versions of LVM.
> No, you didn't understand: this area will have another header, GRUB one
> which will subdivide it. LVM gives us area and we take care of subdivision.
Or you could split the task in two: embed Grub on PVs, like it does on
partition tables, ext2-ext4, Btrfs; then add advanced embedding that
does some mini-partitioning of embedding areas.
The first task is really easy and brings an immediate benefit in making
LVM-only disks bootable.
I don't feel qualified to discuss the second task, because I'm not
seeing the use case. I don't think it's been brought up.
next prev parent reply other threads:[~2013-09-27 13:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 12:39 [PATCH] Install to LVM PVs Gabriel de Perthuis
2013-09-26 8:53 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-09-27 10:39 ` Gabriel de Perthuis
2013-09-27 10:39 ` Gabriel de Perthuis
2013-09-27 12:48 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-09-27 13:56 ` Gabriel de Perthuis [this message]
2013-09-27 13:56 ` Gabriel de Perthuis
2013-09-27 14:27 ` Andrey Borzenkov
2015-02-15 10:47 ` Andrei Borzenkov
-- strict thread matches above, loose matches on Subject: below --
2016-05-08 4:53 Dryden Personalis
2016-05-08 6:05 ` Andrei Borzenkov
2016-05-08 8:47 ` Andrei Borzenkov
2016-05-08 13:10 ` Dryden Personalis
2016-05-08 17:16 ` Dryden Personalis
2016-05-08 17:40 ` Dryden Personalis
2016-05-08 13:01 ` Dryden Personalis
2016-05-09 6:07 ` Andrei Borzenkov
2016-05-09 8:41 ` Dryden Personalis
2016-05-09 16:10 ` Dryden Personalis
2016-05-09 16:18 ` Dryden Personalis
2016-05-09 17:56 ` Dryden Personalis
2016-05-17 18:01 ` Dryden Personalis
2016-05-08 9:23 ` Andrei Borzenkov
2016-05-08 13:09 ` Dryden Personalis
2016-05-09 0:10 ` Xen
2016-05-09 0:10 ` Dryden Personalis
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=52458E98.9000306@gmail.com \
--to=g2p.code@gmail.com \
--cc=grub-devel@gnu.org \
--cc=lvm-devel@redhat.com \
/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.