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’.
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.