[dm-devel] [Notice] multipath-tools changes upstream

[Christophe Varoqui]

In fact, the main incentive for this patchset is the netapp bug tracked on bugzilla (multipathed root device with a transient no-path situation, and no way to exec a paged prio callout).

Ben chose to resurrect the ramfs callout cache trick. But I feel much more comfortable with the mem-locked shared objects.

About your concern for static-only early userspace, I'm confident it is no longer a problem. Guido, from the Debian project, already aknowledged the changeset and did not react to this change. But maybe now he will ...

Thanks for your input.
cvaroqui

----- Original message -----
Hi Christophe and all,

Sorry for the late reply.
I took a quick look at the patch series and got some concerns.
Please see below for details.

On Tue, 15 Apr 2008 19:02:08 +0200, Christophe Varoqui wrote:
> please take notice I updated the upstream git tree for the
> multipath-tools project. This tree includes lots of code shuffling :
>
> 1) prioritizers as dlopen'ed shared libs (/lib/libmultipath/libprio*.so)
> 2) checkers as dlopen'ed shared libs (/lib/libmultipath/libcheck*.so)

Dynamic loading is a nice feature for out-of-tree prioritizers
and checkers.
But I think it's better to avoid using dlopen for in-tree
prioritizers and checkers.
(Or at least provide configuration option to build them as built-in.)


I believe most distros want to use multipath-tools on installer
environment and initrd environment for root volume multipathing.
However, some distros may not be supporting dynamic loading
on such environments, and such distros are using static linked
binaries.
This change prevents such distros from using root volume multipath,
since the change dropped static build capability completely.

Does the change come from my comment below?
(http://marc.info/?l=dm-devel&m=119817423831745&w=2)

On Thu, 20 Dec 2007 13:10:39 -0500 (EST), Kiyoshi Ueda wrote:
> I would like to note that we lost the priority callout feature
> completely to fix the stall problem of root multipath.
>
> Although below is just my humble opinion, I guess it was useful
> for people who want to use new prioritizers on official distro's
> environments until an update package including the prioritizer
> is released.
> So if such a case often happens, adding other ways to use external
> prioritizers (perhaps dynamic loading library module like LVM2)
> would be required in the near future.

If so, I apologize very much for confusing you.
What I meant on the comment above was:
  o stay all in-tree codes as built-in
  o add a new dynamic loading feature for out-of-tree codes

My exact image is like crash command (http://people.redhat.com/anderson/).
It has many built-in sub-commands for kernel core components
(e.g. bt, list).  And it has 'extend' sub-command to load a shared
library and to add extra sub-commands.

In multipath-tools, I thought we could specify shared libraries
in multipath.conf like below:
    defaults {
            extention  new_prioritizer1.so
            extention  new_prioritizer2.so
    }



Anyway, if all distros support dynamic loading on initrd environment
like Fedora, the patch series shouldn't matter.  But I'm not sure.
If there are such distros, we should take the approach above or
another solution like:
  o specify at build time whether in-tree prioritizers/checkers
    are built into the binary or built as shared libraries
  o they are built as shared libraries by default to minimize
    the binary size of multipath/multipathd commands

Thanks,
Kiyoshi Ueda


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20080514/e186ba2f/attachment.htm>