From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?VG9tw6HFoSDEjGVjaA==?= Subject: Re: LVM support Date: Thu, 16 Apr 2015 08:24:01 +0200 Message-ID: <20150416062401.GD6648@venom> References: <20150415050756.GC6648@venom> <878udt1sj5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YidDc-0005Pq-2y for guix-devel@gnu.org; Thu, 16 Apr 2015 02:24:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YidDY-00082X-RW for guix-devel@gnu.org; Thu, 16 Apr 2015 02:24:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52224 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YidDY-00082P-Hk for guix-devel@gnu.org; Thu, 16 Apr 2015 02:24:04 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6D6EEABA2 for ; Thu, 16 Apr 2015 06:24:02 +0000 (UTC) Content-Disposition: inline In-Reply-To: <878udt1sj5.fsf@gnu.org> 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 On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Court=C3=A8s wrote: >Tom=C3=A1=C5=A1 =C4=8Cech skribis: > >> as project for my Hackweek in SUSE I decided to spend my time on LVM >> support in GuixSD - something I miss greatly. This also means that >> I'll have much less time for that after this week :( > >Well this is nice already! > >> So far I spent time on reviving my GuixSD installation and preparing >> staticly linked binaries for initrd. I have now lvm2 package with >> extra output "static". > >Don=E2=80=99t worry about static linking or anything: you can use any pack= age, >including dynamically-linked, and it will be magically added to the >initrd if needed. > >Then as a second step, since that=E2=80=99ll probably be very big, you can= work >on statically-linked variants of the relevant packages (as done for >=E2=80=98e2fsck/static=E2=80=99.) I did this already :) > >> Now the simplest way would be to simply call >> >> vgchange --activate y >> >> Matching configuration could be one configuration option: >> (use-lvm?) >> >> >> That would scan all block devices and look for LVM signature. >> >> Pros: >> - it's super simple! >> Cons: >> - if LVM with filesystem required at boot-time is not found, error >> is not detected or returned by LVM itself >> >> >> >> Slightly bit more complicated way could be >> >> vgchange --activate y >> >> for every volume group defined in system configuration. Matching configu= ration could be >> (logical-volume-groups '("system" "data")) >> >> e.g. specify list of volume group names used by system. >> >> Pros: >> - still simple >> - if group activation fails, I can detect it and report it to user >> >> Cons: >> - some block devices with LVM may not be available at boot-time (like >> iSCSI devices accessible through network only or Luks devices >> available after entering password) >> >> That is my current approach. >> >> >> >> I could also specify whether it should be made available at boot time or= not >> (logical-volume-groups '('("system" #t) >> '("data" #f))) >> >> (sorry for my poor Scheme taste here :) >> >> Pros: >> - with this I could say that volume group "system" should be activated >> at boot time, but "data" should be activated later. >> >> Cons: >> - starting to be more complicated - I need both initrd stage LVM >> activation and root filesystem stage LVM activation (implemented as >> service? which dependencies it has?) > >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). > >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. (define-record-type* mapped-device make-mapped-device mapped-device? (source mapped-device-source) ;string (target mapped-device-target) ;string (type mapped-device-type)) ; =20 `source' will be ignored (I not only don't need it but I don't even know how to pass it or what it should do). `target' will be used for volume group name. mapped-device-kind structure is easily applicable. 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. 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 :) 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. 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. 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. Please don't tell me 'this is not how Guix works' :) Best regards, S_W