[Top][All Lists]

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

Re: LVM support

From: Tomáš Čech
Subject: Re: LVM support
Date: Fri, 17 Apr 2015 03:09:11 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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

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.

Technically, if LVM volumes are mapped devices, the best would be to
define a <mapped-device-kind> structure for them, as discussed on IRC
(like ‘luks-device-mapping’ in (gnu system).)

I didn't like the idea first because it felt confusing and
unatural. Words like `mapping' and `source' and `target' are
misleading. But from programming POV it seems to be the easisest
approach in the end.

I would think the terms are pretty descriptive, esp. when looking at the
corresponding section of the manual, but I’m biased.  ;-)

I meant in LVM context of course.

Now, my understanding of your message is not so much that the terms are
misleading, but rather that the abstraction is bogus (which appears to
be the case based on what you say.)

On the other hand problem starts with need-for-boot?. Device mapped
device will be activated during the boot (which is desirable for LVM)
only if there is filesystem which uses such device and has
`need-for-boot?' set to #t.

Right.  I was hesitant about this approach actually, see 9cb426b8.

Ah, OK, I didn't updated since I started to work on LVM.

I needed to tweak operating-system-boot-mapped-devices to not filter
mappings of the new type at all. Now it seems to generate initrd
capable of booting root filesystem from LVM :)

Nice!  Could you post your working version of the patch, just to make
things more concrete?

I attach patch to this mail.

The thing is that this design is not nice. I always admired Scheme's
power in expressing things naturally. mapped-device interface is for
mapping 1 block device to 1 block device which will contain 1

Understood.  This has nothing to do with Scheme, really.  :-)

Design I'm thinking about would follow file-system structure. For
device property (I'm not sure if this is proper word in Scheme for
item of record type) to define functions like `partition' (disk,
number), `mapped-device' (source, target, type), `logical-volume' (group,
volume) and whatever would be needed further. You could then express
your mount in more powerful way like:

(partition "sda" 1)

 (partition "sda" 2)


 (logical-volume "some_group" "some_volume")
 "encrypted data"


I see.  Looks good!

Does the volume some_group/some_volume have an associated /dev node or
tree?  What does it look like?

Yes, it does, I described above.

Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is
enough; no need to abstract it, IMO, since device node name is up to the

Well, I faced situations where such freedom of expression would be
handy, but there were rare. sda says that it is the first found scsi
device in the system but it doesn't say anything about accessibility
of the device (`local-disk' should be introduced as well I think).

Of course, it would lead to more complicated code to handle such
configuration, but it would definitely feel more natural.

When other block device type (like iSCSI) would be required, just
another function (or whatever it is) would be implemented.

Anything special about iSCSI?  I would expect iSCSI partitions/disks to
just have block devices as usual, no?

Yes, but when you have root filesystem on iSCSI, you need to perform
other actions to make that block device available as with device
mapping or LVM...

(You need to configure and establish connection to iSCSI target.)

Ad the progress - current state of the patch is that it should work
for filesystems mounted from initrd. And is ugly.

As I understand the problem, created device nodes are missing after
switch-root and it seems it tried to mount filesystems before starting
eudev. I'll have a look on that again after some sleep.

Thank you for your comments.


Attachment: lvm.patch
Description: Text document

Attachment: pgpIZSrCyNvnB.pgp
Description: PGP signature

reply via email to

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