[Yaird-devel] Re: evms first try

[Erik van Konijnenburg]

On Fri, Dec 02, 2005 at 11:56:26AM +0100, Marco Amadori wrote:
> Alle 00:36, venerdì 2 dicembre 2005, hai scritto:

> > You probably have evms and lvm2 installed on a single box?

> I had in the past, in  this case I had an old broken initramfs-tools image 
> that included all the three tools, mdadm, lvm and evms, so the mess is coming 
> from here.

Good, this makes an excellent test case.

> > A more reliable way might be to look at the tool that will be used to
> > activate the device: evms_activate uses /dev/evms, the rest uses
> > /dev/mapper.  In order to make that work, we would have to annotate the
> > active block device in tryEvms and friends, then use that annotation in
> > yspecial.
> 
> I think I only partially understood, How could I help now?

I only understand it partially myself, this is where we work out
what yaird is supposed to do.

I'll try to implement something; as a first draft here's a revised
description of the issue, intended to be incorporated in the HTML docs.
If you could comment on the text, that would be most welcome.

Is it comprehensible?  The following text describes how it is supposed
to be, not the implementation we now have.


An issue that deserves special attention is the naming of block devices.
Internally, the kernel uses major:minor numbers to keep track of devices;
as an example, 3:1 could be used for the first partition of the first IDE disk.
However, that's not how fsck and mount refer to block devices; they want a pathname
for a block special file, like /dev/hda1.

If we want to use a block device on the initial boot image, for example because
we want to mount it, we need to know the pathname that the device has.
The tricky part is that there are different tools that can create the pathname
for a device, and they all have different ideas of what is a good pathname.
Different tools can use different names for the same kind of device.
Here's an overview of tools that make block devices on initial boot images:

* mknod.  In the simple case, we do our own mknod after loading the modules
that activate the device.  We have a simple convention here: for a device
that shows up in /sys/block/hda, we create /dev/hda.

* lvm2 and cryptsetup.  These are both based on libdevmapper, and produce
a device file such as /dev/mapper/vg0-root; lvm2 adds a bit of sugar with
a symlink from /dev/vg0/root to /dev/mapper.

* mdadm.  Produces /dev/md0  [unless the configuration file fouls things up]

* evms.  This has its own library that puts pathnames in /dev/evms.

* udev.  We don't currently use that, but it can generate pathnames
such as /dev/disk/by-label/root, that remain stable even if you change
the hardware.  (Or it can be configured to produce a completely random
pathname; udev is *very* flexible)

For yaird this means that when we create a device pathname, we must
remember the tool we use.  Simplyfying a bit:

	my $abd = ActiveBlockDevTab::findByDevno("254:0");
	...
	$actions->add ("vgchange", $vgnam);
	...
	$abd->setCreatedBy ("lvm");

And it means that when we mount we need a function that 

	my $abd = ActiveBlockDevTab::findByDevno("254:0");
	...
	my $yspecial = $abd->yspecial();
	...
	$actions->add ("mount", $mountPoint, device => $yspecial);

Here the function yspecial() returns the pathname to use for a device; it
needs to take into account the tool that was used to create the device:
if it was created by lvm, use /dev/mapper/something, if it was created
by evms, use /dev/evms/something.

Note that there are some consistency checks that we can add:
if we ask for a name with yspecial() before any tool created the
pathname, we have a bug in yaird.  If the same device is marked
as created by first lvm, then later as created by mknod, that also
suggests a bug.


Note that the above is as it should be, not as it currently is implemented.

Regards,
Erik