unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guix-devel@gnu.org
Subject: Re: LVM support
Date: Tue, 21 Apr 2015 17:52:33 +0200	[thread overview]
Message-ID: <87h9s9h41q.fsf@gnu.org> (raw)
In-Reply-To: <20150417010911.GA610@venom> ("Tomáš Čech"'s message of "Fri, 17 Apr 2015 03:09:11 +0200")

Tomáš Čech <sleep_walker@gnu.org> skribis:

> On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote:
>>Tomáš Čech <sleep_walker@gnu.org> 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 #$@device-mapping-commands))
> +                                    (and #$@device-mapping-commands
> +                                         ;; 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	other threads:[~2015-04-21 15:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15  5:07 LVM support Tomáš Čech
2015-04-15 12:32 ` Ludovic Courtès
2015-04-16  6:24   ` Tomáš Čech
2015-04-16 12:47     ` Ludovic Courtès
2015-04-17  1:09       ` Tomáš Čech
2015-04-21 15:52         ` Ludovic Courtès [this message]
2015-05-01 11:32           ` Tomáš Čech
2015-05-03 19:59             ` Ludovic Courtès
2015-05-07  8:02               ` Tomáš Čech
2015-05-19 10:32                 ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
2018-07-30  1:23 ` Pjotr Prins
2018-07-30  9:02   ` Nils Gillmann
2018-07-30 12:47     ` Pierre Neidhardt
2018-08-19 11:06       ` LVM support Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h9s9h41q.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).