guix-devel
[Top][All Lists]
Advanced

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

Re: LVM support


From: Ludovic Courtès
Subject: Re: LVM support
Date: Tue, 21 Apr 2015 17:52:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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?

>  (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?

> --- 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?  Would it be
possible to change the command returned by
‘logical-volume-group-activate’ to somehow create the nodes?  That would
be ideal.

Thanks!

Ludo’.



reply via email to

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