From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: LVM support Date: Thu, 16 Apr 2015 14:47:52 +0200 Message-ID: <87twwgxmrr.fsf@gnu.org> References: <20150415050756.GC6648@venom> <878udt1sj5.fsf@gnu.org> <20150416062401.GD6648@venom> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YijDB-0001Zw-Rq for guix-devel@gnu.org; Thu, 16 Apr 2015 08:48:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YijD5-0007vW-OJ for guix-devel@gnu.org; Thu, 16 Apr 2015 08:48:05 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YijD5-0007vS-LJ for guix-devel@gnu.org; Thu, 16 Apr 2015 08:47:59 -0400 Received: from nat-inria-48-gw-01-bso.bordeaux.inria.fr ([194.199.1.48]:42447 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YijD4-000306-N5 for guix-devel@gnu.org; Thu, 16 Apr 2015 08:47:59 -0400 In-Reply-To: <20150416062401.GD6648@venom> (=?utf-8?B?IlRvbcOhxaEgxIxlY2gi?= =?utf-8?B?J3M=?= message of "Thu, 16 Apr 2015 08:24:01 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org Tom=C3=A1=C5=A1 =C4=8Cech skribis: > On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Court=C3=A8s wrote: [...] >>Sorry I=E2=80=99m not really familiar with LVM. > > It's implemented using device mapper but instead of mapping one block > device to another you map one block device to whole group (like > playground where you can do anything). What do you mean by =E2=80=9Cwhole group=E2=80=9D? A tree under /dev/mappe= r? >>Technically, if LVM volumes are mapped devices, the best would be to >>define a structure for them, as discussed on IRC >>(like =E2=80=98luks-device-mapping=E2=80=99 in (gnu system).) > > I didn't like the idea first because it felt confusing and > unatural. Words like `mapping' and `source' and `target' are > misleading. But from programming POV it seems to be the easisest > approach in the end. I would think the terms are pretty descriptive, esp. when looking at the corresponding section of the manual, but I=E2=80=99m biased. ;-) Now, my understanding of your message is not so much that the terms are misleading, but rather that the abstraction is bogus (which appears to be the case based on what you say.) > On the other hand problem starts with need-for-boot?. Device mapped > device will be activated during the boot (which is desirable for LVM) > only if there is filesystem which uses such device and has > `need-for-boot?' set to #t. Right. I was hesitant about this approach actually, see 9cb426b8. > I needed to tweak operating-system-boot-mapped-devices to not filter > mappings of the new type at all. Now it seems to generate initrd > capable of booting root filesystem from LVM :) Nice! Could you post your working version of the patch, just to make things more concrete? > The thing is that this design is not nice. I always admired Scheme's > power in expressing things naturally. mapped-device interface is for > mapping 1 block device to 1 block device which will contain 1 > filesystem. Understood. This has nothing to do with Scheme, really. :-) > Design I'm thinking about would follow file-system structure. For > device property (I'm not sure if this is proper word in Scheme for > item of record type) to define functions like `partition' (disk, > number), `mapped-device' (source, target, type), `logical-volume' (group, > volume) and whatever would be needed further. You could then express > your mount in more powerful way like: > > (partition "sda" 1) > > (mapped-device > (partition "sda" 2) > "encrypted_swap" > luks-mapping-type) > > (logical-volume > "system_group" > "root") > > > (mapped-device > (logical-volume "some_group" "some_volume") > "encrypted data" > luks-mapping-type) > > etc. I see. Looks good! Does the volume some_group/some_volume have an associated /dev node or tree? What does it look like? Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is enough; no need to abstract it, IMO, since device node name is up to the user. > Of course, it would lead to more complicated code to handle such > configuration, but it would definitely feel more natural. > > When other block device type (like iSCSI) would be required, just > another function (or whatever it is) would be implemented. Anything special about iSCSI? I would expect iSCSI partitions/disks to just have block devices as usual, no? Thank you! Ludo=E2=80=99.