Soliciting feature requests for development of an LVM library / API

[Kay Sievers]

On Sat, Dec 13, 2008 at 02:30, Dave Wysochanski <dwysocha at redhat.com> wrote:
> Thanks for your emails last week.  I'm working through them.  Ok, so
> maybe what you need does not really apply to an LVM library, but you
> need some LVM features.  Let's focus on scanning a PV for basic
> information when a device is added.
>
> On Fri, 2008-12-05 at 17:20 +0100, Kay Sievers wrote:
>>   - dm/LVM tools export information about dm/LVM devices
>>      in <KEY>=<value>\n format, not other format will work
>>
>
> I'm assuming by this, you're meaning something similar to what David
> mentioned in his email about the information that is today available in
> pvdisplay (or pvs) - you want that info in the udev database.
>
> Does this BZ capture all that you need?
> http://bugzilla.redhat.com/show_bug.cgi?id=438604

Yeah, that's what we mean. There is already an earlier comment from me
in that bug regarding this. I replied now to your recent post the bug.

> Note that by scanning a single PV we may not be able to answer
> definitively what VG it is in or what LVs it may contain.  So provided
> we go this route with putting into the udev database all needed
> information that today you get from pv/vg/lvdisplay commands, something
> else will have to put together individual PV information to get an
> accurate picture of the VG / LV info in the system.

Sure, that's fine, and can not be avoided in some cases, I guess. As
long as it limited to scanning "directly related" devices, and not
"all" volumes, or brute-forcre scanning /dev, it should be all fine.

For various reasons we can not afford to open any "unknown" device
from these tools or the library, because we need to support setups
which may have devices active, that do not respond properly, and we
may block in the kernel until timeouts happen. On boxes with hundreds
or thousands of block devices this is not unlikely, and we may block
for hours here in sequentially searching (failing) devices which are
not even involved in the actual volume we request information for.

Thanks,
Kay