From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Oliva Subject: Re: BTRFS, LVM, LUKS Date: Thu, 04 Jul 2019 16:20:45 -0300 Message-ID: References: <875zon2wac.fsf@roquette.mug.biscuolo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:37848) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hj7Hx-0002BY-2g for guix-devel@gnu.org; Thu, 04 Jul 2019 15:21:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hj7Hv-00010X-Lw for guix-devel@gnu.org; Thu, 04 Jul 2019 15:21:01 -0400 Received: from linux-libre.fsfla.org ([209.51.188.54]:48696) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hj7Hv-0000zq-GU for guix-devel@gnu.org; Thu, 04 Jul 2019 15:20:59 -0400 In-Reply-To: <875zon2wac.fsf@roquette.mug.biscuolo.net> (Giovanni Biscuolo's message of "Sun, 30 Jun 2019 12:38:03 +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" To: Giovanni Biscuolo Cc: guix-devel@gnu.org Hello, Giovanni, On Jun 30, 2019, Giovanni Biscuolo wrote: > wellcome to Guix! Thanks! > Alexandre Oliva writes: > Guix is "just" not able to activate/assemble LVM volumes at boot Ok, that doesn't sound too hard to fix. (famous last words ;-) > Device mapper is definitely supported Excellent > I personally manage a physical machine using multi-disk BTRFS > and tested root on BTRFS on LUKS a couple of times on a physical machine Yay! > "It sounds like we=E2=80=99re almost there, I guess." Yeah, it looked so nearly finished that I was very surprised it didn't make it yet. > Please do not be blocked by the lack of LVM support, try start using > Guix on BTRFS on a physical host if you can I might have to make up some room by shrinking LVM partitions ;-) I don't think I have any systems that don't have all disks fully allocated to LVM, other than the yeeloongs. > All I can say is that to start hacking (that means locally build several > packages or services) on Guix you need enough memory (at least 4GB but > 8GB is far better... and use swap!) and enough CPU power (4 cores at > least) That won't be a problem, once I get at least some LVM going. My most powerful local machines (just as old as the others, but desktops with 6 cores and 24+GB of RAM) should be able to deal with the workload, but rearranging their disks is even trickier. [reordered] > must first undestand how device-mapped device are activated and add > support to for LVM ones I'm quite familiar with that myself. There are basically three ways to go about it: (i) scan and activate all PV-like devices, (ii) scan and activate them individually as they come up from udev or whatever, or (iii) know what you're looking to assemble, and look for the specific physical volumes (i) is the simplest, at least as long as you don't have devices that take a long time ot come up and might cause the scan to time out before they're there, but I'm told it's not such a good idea for shared-storage systems (like, multiple hosts connected to the same pool of physical or virtual storage, with some arbitration among them that can get messed up if one of them goes about scanning and activating and whatever what others are already using. (ii) is probably the sanest, at least after the root fs is fully activated, since removable storage might be plugged in at any time, and the infrastructure to support scanning and activating it automatically then is pretty much the same that activates the initially-available volumes, though the latter might take some simulated udev events. (iii) sounds a little more in line with what I understand GuixSD system configuration is about, but... though it's nice to have a config file describing how the storage is set up, that kind of obviates the flexibility of lvm and could make things more difficult for storage disaster recovery. Anyway, I guess it would make most sense to at least start building up on existing practice. How does Guix currently bring up multi-device root filesystems (btrfs, mdraid, ...), and any recursive combinations of mdraid, dmcrypt, etc? I suppose it would make sense to stick to similar logic in bringing up physical volumes towards assembling a volume group containing the root logical volume, bearing in mind that any of these might be also be mdraid, dmraid, dmcrypt... So a single lvm vgscan, while covering the simplest configurations, would not quite go all the way to full generality, which, in the GNU spirit of avoiding arbitrary limitations, if not quite in in the strict sense of the letter, is what I assume GuixSD would aim for. Is that so? --=20 Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jam=C3=A1s - Che GNUevara