guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LVM support


From: Tomáš Čech
Subject: Re: LVM support
Date: Fri, 1 May 2015 13:32:30 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote:
Tomáš Čech <address@hidden> skribis:

On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote:
Tomáš Čech <address@hidden> skribis:

On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:

[...]

Sorry I’m 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 “whole group”?  A tree under /dev/mapper?

From device node POV it generates
/dev/<volume_group_name>/<logical_volume_name> and it also creates
/dev/mapper/<volume_group_name>-<logical_volume_name> and
/dev/dm-<number>.

OK.

From block device perspective it adds another level of "partitioning"
to "physical volume" partitions. You gather block devices (can be
partitions, disks, anything), create volume group to join the space
into one entity and then create logical volumes without caring where
it really is. Logical volumes are useful for resizing, adding and
removing filesystems - it has always the same device node.

Yes, that part I knew.  ;-)


[...]

--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -41,6 +41,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages firmware)
   #:autoload   (gnu packages cryptsetup) (cryptsetup)
+  #:autoload   (gnu packages linux) (lvm2/static)
   #:use-module (gnu services)
   #:use-module (gnu services dmd)
   #:use-module (gnu services base)
@@ -86,7 +87,9 @@
             %base-packages
             %base-firmware

-            luks-device-mapping))
+            luks-device-mapping
+            lvm-mapping
+            lvm-mapping-used?))

 ;;; Commentary:
 ;;;
@@ -208,6 +211,27 @@ file."
    (open open-luks-device)
    (close close-luks-device)))

+(define (logical-volume-group-activate source target)
+  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
+                         "vgchange" "--activate" "y" #$target)))
+
+(define (logical-volume-group-deactivate source target)
+  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
+                    "vgchange" "--activate" "n" #$target)))
+
+(define (lvm-mapping-used? devices)
+  (not
+   (null? (filter
+           (lambda (md)
+             (eq? (mapped-device-type md)
+                  lvm-mapping))
+           devices))))
+
+(define lvm-mapping
+  (mapped-device-kind
+   (open  logical-volume-group-activate)
+   (close logical-volume-group-deactivate)))

This looks good to me!

So I would declare

 (mapped-device
   (source "/dev/sda")
   (target "volume_group_name-logical_volume_name")
   (kind lvm-device-mapping))

and that would give me
/dev/mapper/volume_group_name-logical_volume_name, right?

Volume group can be on multiple block devices. For now I rely on autodetect
abilities of LVM.

So you would declare:

(mapped-device
 (source "") ; irrelevant for LVM
 (target "volume_group_name")
 (type lvm-mapping))

and that would give you
/dev/mapper/volume_group_name-some_volume
/dev/mapper/volume_group_name-other_volume
...

and more conveniently
/dev/volume_group_name/some_volume
/dev/volume_group_name/other_volume
...


 (define (other-file-system-services os)
   "Return file system services for the file systems of OS that are not marked
 as 'needed-for-boot'."
@@ -267,7 +291,10 @@ from the initrd."
         (file-systems (operating-system-file-systems os)))
    (filter (lambda (md)
              (let ((user (mapped-device-user md file-systems)))
-               (and user (file-system-needed-for-boot? user))))
+               (or
+                (and user (file-system-needed-for-boot? user))
+                (and (eq? (mapped-device-type md)
+                          lvm-mapping)))))
            devices)))

I don’t think it’s necessary: if a ‘file-system’ object has
"/dev/mapper/volume_group_name-logical_volume_name" has its ‘device’
field, then this device mapping will automatically be recognized as
needed-for-boot, won’t it?

Yes, you're right, this chunk shouldn't be needed at all. Good catch!

--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -25,6 +25,7 @@
                 #:select (%store-prefix))
   #:use-module ((guix derivations)
                 #:select (derivation->output-path))
+  #:use-module (gnu system)
   #:use-module (gnu packages cpio)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages linux)
@@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear."
                   file-systems)
             (list e2fsck/static)
             '())
+      ,@(if (lvm-mapping-used? mapped-devices)
+            (list lvm2/static)
+            '())
       ,@(if volatile-root?
             (list unionfs-fuse/static)
             '())))
@@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear."

          (boot-system #:mounts '#$(map file-system->spec file-systems)
                       #:pre-mount (lambda ()
-                                    (and address@hidden))
+                                    (and address@hidden
+                                         ;; If we activated any volume group, 
we
+                                         ;; need to ensure that device nodes 
are
+                                         ;; created.  Add code here to call it
+                                         ;; once for all activations.
+                                         #$(when (lvm-mapping-used? 
mapped-devices)
+                                             #~(zero?
+                                                (system* (string-append
+                                                          #$lvm2/static
+                                                          "/sbin/lvm.static")
+                                                         "vgscan"
+                                                         "--mknodes")))))

So ‘lvm vgchange --activate y’ does not create /dev nodes?

Right.

Would it be possible to change the command returned by
‘logical-volume-group-activate’ to somehow create the nodes?  That would
be ideal.

There are two actions needed to be taken:
1] volume group activation
2] creation of nodes

This design choice does as many 1] as needed and 2] once in the end.

I could do always 1] and 2] for every volume group, but I didn't find it nice,
since previous 2] calls are useless only slowing down the process. Do you
really think I should change it?

Thanks for your review.

S_W

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]