[Notice] multipath-tools changes upstream

[Notice] multipath-tools changes upstream

[Christophe Varoqui]

Hi,

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)

Consequences :
The multipath tool is about to get shot for good
The klibc build is gone

Please review, and comment.

Regards,
cvaroqui

Re: [Notice] multipath-tools changes upstream

[Benjamin Marzinski]

On Tue, Apr 15, 2008 at 07:02:08PM +0200, Christophe Varoqui wrote:
> Hi,
> 
> 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)
> 
> Consequences :
> The multipath tool is about to get shot for good
> The klibc build is gone
> 
> Please review, and comment.

I'm not able to update my copy of the repository, or clone a new one.
Am I the only one?

-Ben
 
> Regards,
> cvaroqui
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: [Notice] multipath-tools changes upstream

[Mike Anderson]

Benjamin Marzinski <bmarzins@redhat.com> wrote:
> On Tue, Apr 15, 2008 at 07:02:08PM +0200, Christophe Varoqui wrote:
> > Hi,
> > 
> > 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)
> > 
> > Consequences :
> > The multipath tool is about to get shot for good
> > The klibc build is gone
> > 
> > Please review, and comment.
> 
> I'm not able to update my copy of the repository, or clone a new one.
> Am I the only one?
> 

It is working for me.

I just pulled the other day post the email.

git-head on my tree is currently at:
e22cda64d35235a2b6511cfb589710c3bd3202e0

I just did a git-pull and it indicated that I was up to date.

I am pulling from: 
remote.origin.url=git://git.kernel.org/pub/scm/linux/storage/multipath-tools/.git

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com

Re: [Notice] multipath-tools changes upstream

[Hannes Reinecke]

Hi Christophe,

Christophe Varoqui wrote:
> Hi,
> 
> 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)
Maybe /lib/multipath is more appropriate; eventually something more might
be stored in there.

> 
> Consequences :
> The multipath tool is about to get shot for good
About time :-)
But: how do I get the topology output?
I hope not via the 'multipathd -k' option?
Maybe we should just have it symlinked to multipathd
and print out the appropriate output ...

> The klibc build is gone
Even better.

Oh, and I do have some fixes queued which I need to polish up
and post here. Just as a reminder if you thought of doing
a release or somesuch ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [Notice] multipath-tools changes upstream

[Kiyoshi Ueda]

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

Re: [Notice] multipath-tools changes upstream

[Christophe Varoqui]

[-- Attachment #1.1: Type: text/plain, Size: 3613 bytes --]

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



[-- Attachment #1.2: Type: text/html, Size: 4915 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]