[ANNOUNCE] multipath-tools-0.2.9

[ANNOUNCE] multipath-tools-0.2.9

[christophe varoqui]

Hello,

here goes multipath-tools-0.2.9

The ChangeLog is pretty big this time : changes accumulated while
waiting for scsi_id-0.6 and while background-battling with an IA64
compilation glitch.

In short :

	* compiles on IA64
	* implement the alias OSDL CGL preconisation
	* more work on single path devices and JBOD handling

Regression testing is even lighter than the previous release, because I
temporarily lost access to my favorite SAN.

Full ChangeLog for the release :

        * [multipathd] finally tame the clone compilation glitch on IA64
          move from sys_clone to __clone / __clone2
        * [kpartx] rework from Stephan Bader, IBM :
                * handle s390x arch
                * endianness fixes
                * push the partname string size to handle wwwids
                * quieten implicit cast warnings
        * [multipath] add an 'alias' multipath keyword for friendlier
	  device
          names. This was "asked" by OSDL' CGL board of secret reviewers
        * [multipath] last pass with JBOD and parallel SCSI support :
          hard-code scsi_id as a fallback when disk strings doesn't
	  match any hwtable entry
        * [multipath & multipathd] change the parser to not coalesce
          consecutive spaces (Patrick Mansfield)
        * [multipath] remove the [UN]: output prefix, so that stdout can
	  be easily fed to a tool like dmsetup
        * [multipathd] DEBUG=3 logs more readable/usefull
        * [multipathd] add a multipath_tool config keyword
        * [multipathd] move to execute_program() like multipath already
          did
        * [multipath] don't print the "no path" msg in quiet mode
        * [multipathd] include linux/unistd.h for _syscall2
          definition on RedHat systems. Remove superfluous
          asm/unistd.h include
        * [libsysfs] forked : last version uses mntent, which
          klibc doesn't provide. That, plus the fact we use
          only 1/3 of the lib, pushed me to freeze the version
          and strip all unused stuff.
        * [multipathd] prepare_namespace() cleanup : no more "multipath"
          special casing since we push it to binvec vector, like the
          other callouts detected in the config file.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.2.9

[christophe varoqui]

Hello,

here goes multipath-tools-0.2.9

The ChangeLog is pretty big this time : changes accumulated while
waiting for scsi_id-0.6 and while background-battling with an IA64
compilation glitch.

In short :

	* compiles on IA64
	* implement the alias OSDL CGL preconisation
	* more work on single path devices and JBOD handling

Regression testing is even lighter than the previous release, because I
temporarily lost access to my favorite SAN.

Full ChangeLog for the release :

        * [multipathd] finally tame the clone compilation glitch on IA64
          move from sys_clone to __clone / __clone2
        * [kpartx] rework from Stephan Bader, IBM :
                * handle s390x arch
                * endianness fixes
                * push the partname string size to handle wwwids
                * quieten implicit cast warnings
        * [multipath] add an 'alias' multipath keyword for friendlier
	  device
          names. This was "asked" by OSDL' CGL board of secret reviewers
        * [multipath] last pass with JBOD and parallel SCSI support :
          hard-code scsi_id as a fallback when disk strings doesn't
	  match any hwtable entry
        * [multipath & multipathd] change the parser to not coalesce
          consecutive spaces (Patrick Mansfield)
        * [multipath] remove the [UN]: output prefix, so that stdout can
	  be easily fed to a tool like dmsetup
        * [multipathd] DEBUG=3 logs more readable/usefull
        * [multipathd] add a multipath_tool config keyword
        * [multipathd] move to execute_program() like multipath already
          did
        * [multipath] don't print the "no path" msg in quiet mode
        * [multipathd] include linux/unistd.h for _syscall2
          definition on RedHat systems. Remove superfluous
          asm/unistd.h include
        * [libsysfs] forked : last version uses mntent, which
          klibc doesn't provide. That, plus the fact we use
          only 1/3 of the lib, pushed me to freeze the version
          and strip all unused stuff.
        * [multipathd] prepare_namespace() cleanup : no more "multipath"
          special casing since we push it to binvec vector, like the
          other callouts detected in the config file.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.0

Faster release cycle.
Big things for some people out there.
Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
and kill your devmap_name rule in udev.rules (we use a separate rules.d file
now)

In short :


* easy multipath-aware initrds on Debian SID
	* fully fonctionnal with direct-attached SCSI disks (single-path)

Full ChangeLog for the release :

        * first cut at making scripts to create multipath-aware initrds
	  those scripts are tested on Debian SID, and must be copied into
	  /etc/mkinitrd/scripts. it works here.
	* [multipath] verify presence of the /sys/block/... node before
	  reading sysfs attributes. Avoids libsysfs and scsi_id stderr
	  garbage
	* [multipath] move down the stderr close (Ake Sandgren at umu.se)
	* [multipath] don't care about 0-sized mp (Ake Sandgren at umu.se)
	* [multipath] bump mp size field to ulong (Ake Sandgren at umu.se)
	* [multipath] replace quiet/verbose flags by a verbosity one.
	  introduce a new verbosity level : 1 == print only devmap names
	  thus we can feed kpartx with that output
	* [multipath] update man page to reflect the hotplug.d -> dev.d
	  transition and replace the obsolete group_by_tur policy by the
	  forgotten group_by_prio
	* [multipath] provide a /etc/udev/rules.d/multipath.rules for
	  multipath devices naming. Cleaner than the previously suggested
	  rule addition in the main udev.rules
	* [multipath] move out of hotplug.d to dev.d : kill synchronisation
	  problems between device node creation and multipath execution.
	  Incidentally the unfriendly $DEVPATH param become a friendly
	  $DEVNAME (simply /dev/sdb)
	* [multipath] rework the iopolicies name-to-id & id-to-name
	  translations. kills the last compilation warning here too
	* [kpartx] kill last compilation warnings
	* bump klibc to 0.181
	* add the debian/ packaging dir (make deb)
	* prototype __clone & __clone2 (kills compilation warning)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.0

Faster release cycle.
Big things for some people out there.
Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
and kill your devmap_name rule in udev.rules (we use a separate rules.d file
now)

In short :


* easy multipath-aware initrds on Debian SID
	* fully fonctionnal with direct-attached SCSI disks (single-path)

Full ChangeLog for the release :

        * first cut at making scripts to create multipath-aware initrds
	  those scripts are tested on Debian SID, and must be copied into
	  /etc/mkinitrd/scripts. it works here.
	* [multipath] verify presence of the /sys/block/... node before
	  reading sysfs attributes. Avoids libsysfs and scsi_id stderr
	  garbage
	* [multipath] move down the stderr close (Ake Sandgren at umu.se)
	* [multipath] don't care about 0-sized mp (Ake Sandgren at umu.se)
	* [multipath] bump mp size field to ulong (Ake Sandgren at umu.se)
	* [multipath] replace quiet/verbose flags by a verbosity one.
	  introduce a new verbosity level : 1 = print only devmap names
	  thus we can feed kpartx with that output
	* [multipath] update man page to reflect the hotplug.d -> dev.d
	  transition and replace the obsolete group_by_tur policy by the
	  forgotten group_by_prio
	* [multipath] provide a /etc/udev/rules.d/multipath.rules for
	  multipath devices naming. Cleaner than the previously suggested
	  rule addition in the main udev.rules
	* [multipath] move out of hotplug.d to dev.d : kill synchronisation
	  problems between device node creation and multipath execution.
	  Incidentally the unfriendly $DEVPATH param become a friendly
	  $DEVNAME (simply /dev/sdb)
	* [multipath] rework the iopolicies name-to-id & id-to-name
	  translations. kills the last compilation warning here too
	* [kpartx] kill last compilation warnings
	* bump klibc to 0.181
	* add the debian/ packaging dir (make deb)
	* prototype __clone & __clone2 (kills compilation warning)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Lars Marowsky-Bree]

On 2004-10-06T11:22:53, christophe.varoqui@free.fr wrote:

> here goes multipath-tools-0.3.0
> 
> Faster release cycle.
> Big things for some people out there.
> Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
> and kill your devmap_name rule in udev.rules (we use a separate rules.d file
> now)

Hi Christophe, do you still plan further configuration file changes in
the immediate future or will the format of the configuration settle down
now?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Lars Marowsky-Bree]

On 2004-10-06T11:22:53, christophe.varoqui@free.fr wrote:

> here goes multipath-tools-0.3.0
> 
> Faster release cycle.
> Big things for some people out there.
> Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
> and kill your devmap_name rule in udev.rules (we use a separate rules.d file
> now)

Hi Christophe, do you still plan further configuration file changes in
the immediate future or will the format of the configuration settle down
now?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Lars Marowsky-Bree <lmb@suse.de>:
> > Upgrade will need you to manualy remove your
> > /etc/udev/rules.d/multipath.rules
> > and kill your devmap_name rule in udev.rules (we use a separate rules.d
> > file now)
>
> Hi Christophe, do you still plan further configuration file changes in
> the immediate future or will the format of the configuration settle down
> now?
>
It all depends on the satisfaction of the testers.

Let's review the current situation with regards to files touched by the package
:

* /etc/multipathd.conf :

optional
you only need to create one if you use multipath aliases or have hardware not
known internaly
its synthax is not yet fully stabilized : for example, I may decide to move from

multipath {
  wwid = 00000acdefg123456ff
  alias = system
}

to

multipath 00000acdefg123456ff {
  alias = system
}

also expect a few keyword additions to cover the new reinstate feature of the
kernel driver.

* /etc/hotplug.d/scsi/multipath

dead and to be removed from 0.3.0 and up

* /etc/dev.d/block/multipath.dev

optional
this is where we call multipath and kpartx when nodes appear in /sys/block
this one should not change too much, but I expect more feedback from testers

* /etc/udev/udev.rules

from 0.3.0 and up, we don't touch it anymore

* /etc/udev/rules.d/multipath

maybe misnamed. I may rename it to device-mapper.
this is where I drop the devmap_name rule to alias dm-* devmaps with the devmap
name as shown by dmsetup

* /etc/mkinitrd/scripts/01_udev
  /etc/mkinitrd/scripts/02_multipath

optional, debian specific, but should be portable to other distribs

these copy udev, multipath tools and config files to initrd when mkinitrd is
launched.
01_udev also creates a script to fire up udevstart from initrd.
udevstart triggers the hotplug chain-reaction that leads to multipaths being
created.

this certainly needs refining, and I expect distrib packagers to show interest
in taking them over. Do you ?



hope it clarify things,
regards,
cvaroqui

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Lars Marowsky-Bree <lmb@suse.de>:
> > Upgrade will need you to manualy remove your
> > /etc/udev/rules.d/multipath.rules
> > and kill your devmap_name rule in udev.rules (we use a separate rules.d
> > file now)
>
> Hi Christophe, do you still plan further configuration file changes in
> the immediate future or will the format of the configuration settle down
> now?
>
It all depends on the satisfaction of the testers.

Let's review the current situation with regards to files touched by the package
:

* /etc/multipathd.conf :

optional
you only need to create one if you use multipath aliases or have hardware not
known internaly
its synthax is not yet fully stabilized : for example, I may decide to move from

multipath {
  wwid = 00000acdefg123456ff
  alias = system
}

to

multipath 00000acdefg123456ff {
  alias = system
}

also expect a few keyword additions to cover the new reinstate feature of the
kernel driver.

* /etc/hotplug.d/scsi/multipath

dead and to be removed from 0.3.0 and up

* /etc/dev.d/block/multipath.dev

optional
this is where we call multipath and kpartx when nodes appear in /sys/block
this one should not change too much, but I expect more feedback from testers

* /etc/udev/udev.rules

from 0.3.0 and up, we don't touch it anymore

* /etc/udev/rules.d/multipath

maybe misnamed. I may rename it to device-mapper.
this is where I drop the devmap_name rule to alias dm-* devmaps with the devmap
name as shown by dmsetup

* /etc/mkinitrd/scripts/01_udev
  /etc/mkinitrd/scripts/02_multipath

optional, debian specific, but should be portable to other distribs

these copy udev, multipath tools and config files to initrd when mkinitrd is
launched.
01_udev also creates a script to fire up udevstart from initrd.
udevstart triggers the hotplug chain-reaction that leads to multipaths being
created.

this certainly needs refining, and I expect distrib packagers to show interest
in taking them over. Do you ?



hope it clarify things,
regards,
cvaroqui


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Lars Marowsky-Bree]

On 2004-10-06T12:18:40, christophe.varoqui@free.fr wrote:

Sorry for the late reply, I was somewhat busy, but I'm going to be
working on multipathing during the next couple of days / weeks again.

> It all depends on the satisfaction of the testers.
> 
> Let's review the current situation with regards to files touched by
> the package :

> 
> * /etc/multipathd.conf :
> 
> optional
> you only need to create one if you use multipath aliases or have hardware not
> known internaly

This is a good point. If we can make it work out of the box, then that's
of course best.

> its synthax is not yet fully stabilized : for example, I may decide to move from
> 
> multipath {
>   wwid = 00000acdefg123456ff
>   alias = system
> }
> 
> to
> 
> multipath 00000acdefg123456ff {
>   alias = system
> }

I'd probably leave it in the first form, as a multipath array might be
identified not only by the wwid but by other means in the future too,
no?

> also expect a few keyword additions to cover the new reinstate feature
> of the kernel driver.

Ok.

> * /etc/hotplug.d/scsi/multipath
> 
> dead and to be removed from 0.3.0 and up

Ok.

> * /etc/dev.d/block/multipath.dev
> 
> optional
> this is where we call multipath and kpartx when nodes appear in /sys/block
> this one should not change too much, but I expect more feedback from testers

I don't think this one will need to be touched by admins on the systems,
so it's not really a configuration file...

> * /etc/udev/udev.rules
> 
> from 0.3.0 and up, we don't touch it anymore

That's very good indeed and actually makes configuration easier! Which
udev version do you require though?

> these copy udev, multipath tools and config files to initrd when
> mkinitrd is launched.

Yes. I'm not yet sure how/if we are going to support booting from
multipath root fs in SLES9, so this doesn't really affect me for the
time being.

I first will need to do a gap analysis and figure out where to go today
;-)

> this certainly needs refining, and I expect distrib packagers to show
> interest in taking them over. Do you ?

We'll certainly need to pull them into our own mkinitrd tools and make
distribution specific adjustments, and of course where applicable give
them back to you.

My main job right now is to extend multipath to work with the
active/passive scenarios, where a special path activation command needs
to be send down before a new path group can be used. Anything else I can
solve as I go along that one is welcome but optional to me.

Thanks for the explanations, I'll now go and have a real closer look at
the tools and modules...


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Lars Marowsky-Bree]

On 2004-10-06T12:18:40, christophe.varoqui@free.fr wrote:

Sorry for the late reply, I was somewhat busy, but I'm going to be
working on multipathing during the next couple of days / weeks again.

> It all depends on the satisfaction of the testers.
> 
> Let's review the current situation with regards to files touched by
> the package :

> 
> * /etc/multipathd.conf :
> 
> optional
> you only need to create one if you use multipath aliases or have hardware not
> known internaly

This is a good point. If we can make it work out of the box, then that's
of course best.

> its synthax is not yet fully stabilized : for example, I may decide to move from
> 
> multipath {
>   wwid = 00000acdefg123456ff
>   alias = system
> }
> 
> to
> 
> multipath 00000acdefg123456ff {
>   alias = system
> }

I'd probably leave it in the first form, as a multipath array might be
identified not only by the wwid but by other means in the future too,
no?

> also expect a few keyword additions to cover the new reinstate feature
> of the kernel driver.

Ok.

> * /etc/hotplug.d/scsi/multipath
> 
> dead and to be removed from 0.3.0 and up

Ok.

> * /etc/dev.d/block/multipath.dev
> 
> optional
> this is where we call multipath and kpartx when nodes appear in /sys/block
> this one should not change too much, but I expect more feedback from testers

I don't think this one will need to be touched by admins on the systems,
so it's not really a configuration file...

> * /etc/udev/udev.rules
> 
> from 0.3.0 and up, we don't touch it anymore

That's very good indeed and actually makes configuration easier! Which
udev version do you require though?

> these copy udev, multipath tools and config files to initrd when
> mkinitrd is launched.

Yes. I'm not yet sure how/if we are going to support booting from
multipath root fs in SLES9, so this doesn't really affect me for the
time being.

I first will need to do a gap analysis and figure out where to go today
;-)

> this certainly needs refining, and I expect distrib packagers to show
> interest in taking them over. Do you ?

We'll certainly need to pull them into our own mkinitrd tools and make
distribution specific adjustments, and of course where applicable give
them back to you.

My main job right now is to extend multipath to work with the
active/passive scenarios, where a special path activation command needs
to be send down before a new path group can be used. Anything else I can
solve as I go along that one is welcome but optional to me.

Thanks for the explanations, I'll now go and have a real closer look at
the tools and modules...


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Lars Marowsky-Bree <lmb@suse.de>:

> > * /etc/udev/udev.rules
> >
> > from 0.3.0 and up, we don't touch it anymore
>
> That's very good indeed and actually makes configuration easier! Which
> udev version do you require though?
>
034+, because of scsi_id-0.6 dependancy
if scsi_id is packaged separately in Suse, min version goes down as low as dev.d
introduction (I don't know precisely what the number is).

> > these copy udev, multipath tools and config files to initrd when
> > mkinitrd is launched.
>
> Yes. I'm not yet sure how/if we are going to support booting from
> multipath root fs in SLES9, so this doesn't really affect me for the
> time being.
>
> I first will need to do a gap analysis and figure out where to go today
> ;-)
>
yes,
the hard decision is wether you want to rely on kpartx.

regards,
cvaroqui

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Lars Marowsky-Bree <lmb@suse.de>:

> > * /etc/udev/udev.rules
> >
> > from 0.3.0 and up, we don't touch it anymore
>
> That's very good indeed and actually makes configuration easier! Which
> udev version do you require though?
>
034+, because of scsi_id-0.6 dependancy
if scsi_id is packaged separately in Suse, min version goes down as low as dev.d
introduction (I don't know precisely what the number is).

> > these copy udev, multipath tools and config files to initrd when
> > mkinitrd is launched.
>
> Yes. I'm not yet sure how/if we are going to support booting from
> multipath root fs in SLES9, so this doesn't really affect me for the
> time being.
>
> I first will need to do a gap analysis and figure out where to go today
> ;-)
>
yes,
the hard decision is wether you want to rely on kpartx.

regards,
cvaroqui


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Dave Olien]

Christophe,

I downloaded your new multipath tools, and they seem to have solved a problem
I was having with the previous version.

The only difficulty I had was with the new klibc version (klibc-0.181).
For i386 architecture, it compiles by default with -mregparm=3, to
pass arguments in registers.

But with my version of compiler (gcc 3.2.2), the rest of the multipath
libraries and utilities were compiled to pass arguments on the stack.
So the resulting binaries segfault the first time they call a klibc library.

I modified the klibc/klibc/arch/i386/MCONFIG file to compile with
stack argument passing, and everything works great.

Is there a compiler version now that by default passes arguments
in registers?

Thanks!
Dave Olien

On Wed, Oct 06, 2004 at 11:22:53AM +0200, christophe.varoqui@free.fr wrote:
> Hello,
> 
> here goes multipath-tools-0.3.0
> 
> Faster release cycle.
> Big things for some people out there.
> Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
> and kill your devmap_name rule in udev.rules (we use a separate rules.d file
> now)
> 
> In short :
> 
> 
> * easy multipath-aware initrds on Debian SID
> 	* fully fonctionnal with direct-attached SCSI disks (single-path)
> 
> Full ChangeLog for the release :
> 
>         * first cut at making scripts to create multipath-aware initrds
> 	  those scripts are tested on Debian SID, and must be copied into
> 	  /etc/mkinitrd/scripts. it works here.
> 	* [multipath] verify presence of the /sys/block/... node before
> 	  reading sysfs attributes. Avoids libsysfs and scsi_id stderr
> 	  garbage
> 	* [multipath] move down the stderr close (Ake Sandgren at umu.se)
> 	* [multipath] don't care about 0-sized mp (Ake Sandgren at umu.se)
> 	* [multipath] bump mp size field to ulong (Ake Sandgren at umu.se)
> 	* [multipath] replace quiet/verbose flags by a verbosity one.
> 	  introduce a new verbosity level : 1 == print only devmap names
> 	  thus we can feed kpartx with that output
> 	* [multipath] update man page to reflect the hotplug.d -> dev.d
> 	  transition and replace the obsolete group_by_tur policy by the
> 	  forgotten group_by_prio
> 	* [multipath] provide a /etc/udev/rules.d/multipath.rules for
> 	  multipath devices naming. Cleaner than the previously suggested
> 	  rule addition in the main udev.rules
> 	* [multipath] move out of hotplug.d to dev.d : kill synchronisation
> 	  problems between device node creation and multipath execution.
> 	  Incidentally the unfriendly $DEVPATH param become a friendly
> 	  $DEVNAME (simply /dev/sdb)
> 	* [multipath] rework the iopolicies name-to-id & id-to-name
> 	  translations. kills the last compilation warning here too
> 	* [kpartx] kill last compilation warnings
> 	* bump klibc to 0.181
> 	* add the debian/ packaging dir (make deb)
> 	* prototype __clone & __clone2 (kills compilation warning)
> 
> As usual, doc and download at :
> http://christophe.varoqui.free.fr/
> 
> regards,
> --
> christophe varoqui <christophe.varoqui@free.fr>
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[Dave Olien]

Christophe,

I downloaded your new multipath tools, and they seem to have solved a problem
I was having with the previous version.

The only difficulty I had was with the new klibc version (klibc-0.181).
For i386 architecture, it compiles by default with -mregparm=3, to
pass arguments in registers.

But with my version of compiler (gcc 3.2.2), the rest of the multipath
libraries and utilities were compiled to pass arguments on the stack.
So the resulting binaries segfault the first time they call a klibc library.

I modified the klibc/klibc/arch/i386/MCONFIG file to compile with
stack argument passing, and everything works great.

Is there a compiler version now that by default passes arguments
in registers?

Thanks!
Dave Olien

On Wed, Oct 06, 2004 at 11:22:53AM +0200, christophe.varoqui@free.fr wrote:
> Hello,
> 
> here goes multipath-tools-0.3.0
> 
> Faster release cycle.
> Big things for some people out there.
> Upgrade will need you to manualy remove your /etc/udev/rules.d/multipath.rules
> and kill your devmap_name rule in udev.rules (we use a separate rules.d file
> now)
> 
> In short :
> 
> 
> * easy multipath-aware initrds on Debian SID
> 	* fully fonctionnal with direct-attached SCSI disks (single-path)
> 
> Full ChangeLog for the release :
> 
>         * first cut at making scripts to create multipath-aware initrds
> 	  those scripts are tested on Debian SID, and must be copied into
> 	  /etc/mkinitrd/scripts. it works here.
> 	* [multipath] verify presence of the /sys/block/... node before
> 	  reading sysfs attributes. Avoids libsysfs and scsi_id stderr
> 	  garbage
> 	* [multipath] move down the stderr close (Ake Sandgren at umu.se)
> 	* [multipath] don't care about 0-sized mp (Ake Sandgren at umu.se)
> 	* [multipath] bump mp size field to ulong (Ake Sandgren at umu.se)
> 	* [multipath] replace quiet/verbose flags by a verbosity one.
> 	  introduce a new verbosity level : 1 = print only devmap names
> 	  thus we can feed kpartx with that output
> 	* [multipath] update man page to reflect the hotplug.d -> dev.d
> 	  transition and replace the obsolete group_by_tur policy by the
> 	  forgotten group_by_prio
> 	* [multipath] provide a /etc/udev/rules.d/multipath.rules for
> 	  multipath devices naming. Cleaner than the previously suggested
> 	  rule addition in the main udev.rules
> 	* [multipath] move out of hotplug.d to dev.d : kill synchronisation
> 	  problems between device node creation and multipath execution.
> 	  Incidentally the unfriendly $DEVPATH param become a friendly
> 	  $DEVNAME (simply /dev/sdb)
> 	* [multipath] rework the iopolicies name-to-id & id-to-name
> 	  translations. kills the last compilation warning here too
> 	* [kpartx] kill last compilation warnings
> 	* bump klibc to 0.181
> 	* add the debian/ packaging dir (make deb)
> 	* prototype __clone & __clone2 (kills compilation warning)
> 
> As usual, doc and download at :
> http://christophe.varoqui.free.fr/
> 
> regards,
> --
> christophe varoqui <christophe.varoqui@free.fr>
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Dave Olien <dmo@osdl.org>:

>
> Christophe,
>
> I downloaded your new multipath tools, and they seem to have solved a problem
> I was having with the previous version.
>
> The only difficulty I had was with the new klibc version (klibc-0.181).
> For i386 architecture, it compiles by default with -mregparm=3, to
> pass arguments in registers.
>
good catch.

I think the correct fix is to follow the klibc rules, ie :
CFLAGS += ${OPTFLAGS} in Makefile.inc

I'll release a new tarball soon to correct this.

thanks,
cvaroqui
--

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.3.0

[christophe.varoqui]

Selon Dave Olien <dmo@osdl.org>:

>
> Christophe,
>
> I downloaded your new multipath tools, and they seem to have solved a problem
> I was having with the previous version.
>
> The only difficulty I had was with the new klibc version (klibc-0.181).
> For i386 architecture, it compiles by default with -mregparm=3, to
> pass arguments in registers.
>
good catch.

I think the correct fix is to follow the klibc rules, ie :
CFLAGS += ${OPTFLAGS} in Makefile.inc

I'll release a new tarball soon to correct this.

thanks,
cvaroqui
--


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.1

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.1

Early release, to fix a important i386 breakage due to regparm switch in klibc.
Release focuses on undusting kpartx.
ia64 and woody testers, please redo your thing : I may have got it right this
time.

Full ChangeLog for the release :

        * [kpartx] move back to getopt, originaly removed from the
          original partx because of lack of implementation in klibc
        * [kpartx] don't map extended partitions
        * [kpartx] add a -p command flag to allow admin to force a
          delimiting string between disk name and part number. When
          specified always use it, when unspecified use 'p' as a delim
          when last char of disk name is a digit, NUL otherwise.
        * [kpartx] clean up
        * bump klibc to 0.182
        * one step further : use klibc MCONFIG for all klibc specific
          FLAGS definitions, ie massive Makefile.inc cleanup
        * follow the klibc compilation rules by appending its OPTFLAGS
          to multipath-tools' CFLAGS. This corrects the segfaults seen
          on i386 where klibc is built with regparm=3 and tools are not
        * [multipathd] fall back to fork when clone not available
          like in Debian Woody
        * [kpartx] move .start and .size from uint to ulong (Ake)
        * briefly document system-disk-on-multipath in the FAQ file

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.3.1

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.1

Early release, to fix a important i386 breakage due to regparm switch in klibc.
Release focuses on undusting kpartx.
ia64 and woody testers, please redo your thing : I may have got it right this
time.

Full ChangeLog for the release :

        * [kpartx] move back to getopt, originaly removed from the
          original partx because of lack of implementation in klibc
        * [kpartx] don't map extended partitions
        * [kpartx] add a -p command flag to allow admin to force a
          delimiting string between disk name and part number. When
          specified always use it, when unspecified use 'p' as a delim
          when last char of disk name is a digit, NUL otherwise.
        * [kpartx] clean up
        * bump klibc to 0.182
        * one step further : use klibc MCONFIG for all klibc specific
          FLAGS definitions, ie massive Makefile.inc cleanup
        * follow the klibc compilation rules by appending its OPTFLAGS
          to multipath-tools' CFLAGS. This corrects the segfaults seen
          on i386 where klibc is built with regparm=3 and tools are not
        * [multipathd] fall back to fork when clone not available
          like in Debian Woody
        * [kpartx] move .start and .size from uint to ulong (Ake)
        * briefly document system-disk-on-multipath in the FAQ file

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.3.1

[Dave Olien]

Christophe,

I compiled and installed your new tarball.  It looks good so far on i386.
Thanks for the update!

Dave

On Mon, Oct 11, 2004 at 01:50:16PM +0200, christophe.varoqui@free.fr wrote:
> Hello,
> 
> here goes multipath-tools-0.3.1
> 
> Early release, to fix a important i386 breakage due to regparm switch in klibc.
> Release focuses on undusting kpartx.
> ia64 and woody testers, please redo your thing : I may have got it right this
> time.
> 
> Full ChangeLog for the release :
> 
>         * [kpartx] move back to getopt, originaly removed from the
>           original partx because of lack of implementation in klibc
>         * [kpartx] don't map extended partitions
>         * [kpartx] add a -p command flag to allow admin to force a
>           delimiting string between disk name and part number. When
>           specified always use it, when unspecified use 'p' as a delim
>           when last char of disk name is a digit, NUL otherwise.
>         * [kpartx] clean up
>         * bump klibc to 0.182
>         * one step further : use klibc MCONFIG for all klibc specific
>           FLAGS definitions, ie massive Makefile.inc cleanup
>         * follow the klibc compilation rules by appending its OPTFLAGS
>           to multipath-tools' CFLAGS. This corrects the segfaults seen
>           on i386 where klibc is built with regparm=3 and tools are not
>         * [multipathd] fall back to fork when clone not available
>           like in Debian Woody
>         * [kpartx] move .start and .size from uint to ulong (Ake)
>         * briefly document system-disk-on-multipath in the FAQ file
> 
> As usual, doc and download at :
> http://christophe.varoqui.free.fr/
> 
> regards,
> --
> christophe varoqui <christophe.varoqui@free.fr>
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.3.1

[Dave Olien]

Christophe,

I compiled and installed your new tarball.  It looks good so far on i386.
Thanks for the update!

Dave

On Mon, Oct 11, 2004 at 01:50:16PM +0200, christophe.varoqui@free.fr wrote:
> Hello,
> 
> here goes multipath-tools-0.3.1
> 
> Early release, to fix a important i386 breakage due to regparm switch in klibc.
> Release focuses on undusting kpartx.
> ia64 and woody testers, please redo your thing : I may have got it right this
> time.
> 
> Full ChangeLog for the release :
> 
>         * [kpartx] move back to getopt, originaly removed from the
>           original partx because of lack of implementation in klibc
>         * [kpartx] don't map extended partitions
>         * [kpartx] add a -p command flag to allow admin to force a
>           delimiting string between disk name and part number. When
>           specified always use it, when unspecified use 'p' as a delim
>           when last char of disk name is a digit, NUL otherwise.
>         * [kpartx] clean up
>         * bump klibc to 0.182
>         * one step further : use klibc MCONFIG for all klibc specific
>           FLAGS definitions, ie massive Makefile.inc cleanup
>         * follow the klibc compilation rules by appending its OPTFLAGS
>           to multipath-tools' CFLAGS. This corrects the segfaults seen
>           on i386 where klibc is built with regparm=3 and tools are not
>         * [multipathd] fall back to fork when clone not available
>           like in Debian Woody
>         * [kpartx] move .start and .size from uint to ulong (Ake)
>         * briefly document system-disk-on-multipath in the FAQ file
> 
> As usual, doc and download at :
> http://christophe.varoqui.free.fr/
> 
> regards,
> --
> christophe varoqui <christophe.varoqui@free.fr>
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

multipath-tools-0.3.2

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.2

This one will need you to upgrade to latest -udm patchset to support the
new path reinstate feature.
Lots of bugfixes from Suse review.

Full ChangeLog for the release :

	* [multipath] add path reinstate logic :
		* if a path is given as multipath arg
		* if the map containing that path already exists
		* if this map is the same as the that would be
		  created by this multipath run
		* THEN reinstate the path
	  multipathd is is thus unchanged, while now supporting
	  reinstate
	* audit and ensafe all sprintf usage
	* [multipath] fix the annoying \n after each dev_t in
	  params string reporting
	* [multipath] print out devmaps in "-v2 -d" mode
	* [kpartx] bump up the params string size (lmb at suse)
	* [kpartx] replace sprintf by snprintf (lmb at suse)
	* [kpartx] initialize some more vars (lmb at suse)
	* [multipath] mp->pg == NULL safety net before calling
	  assemble_map() (for Andy who happen to hit the bug)
	* [multipath] last rampant bug in map CREATE or UPDATE switch
	  logic due to the device alias feature
	* [kpartx] zeroe "struct slice all" (lmb at suse)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

multipath-tools-0.3.2

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.2

This one will need you to upgrade to latest -udm patchset to support the
new path reinstate feature.
Lots of bugfixes from Suse review.

Full ChangeLog for the release :

	* [multipath] add path reinstate logic :
		* if a path is given as multipath arg
		* if the map containing that path already exists
		* if this map is the same as the that would be
		  created by this multipath run
		* THEN reinstate the path
	  multipathd is is thus unchanged, while now supporting
	  reinstate
	* audit and ensafe all sprintf usage
	* [multipath] fix the annoying \n after each dev_t in
	  params string reporting
	* [multipath] print out devmaps in "-v2 -d" mode
	* [kpartx] bump up the params string size (lmb at suse)
	* [kpartx] replace sprintf by snprintf (lmb at suse)
	* [kpartx] initialize some more vars (lmb at suse)
	* [multipath] mp->pg = NULL safety net before calling
	  assemble_map() (for Andy who happen to hit the bug)
	* [multipath] last rampant bug in map CREATE or UPDATE switch
	  logic due to the device alias feature
	* [kpartx] zeroe "struct slice all" (lmb at suse)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.3

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.3

Suse and OSDL reviews continue, keeping the flow of changes high.
Early release to keep interested people in sync.

Full ChangeLog for the release :

	* [checkers] add the emc_clariion path checker (lmb at Suse)
	* [multipath] introduce safe_snprintf macro to complement the
	  safe_sprintf. Needed to cover the sizeof(pointer) cases
	  pointed by Dave Olien at OSDL
	* [multipath] move to the common libchecker framework and
	  activate the selector
	* [multipath] fix an iopolicy selector bug (initialized lun
	  iopolicy overrode controler-wide iopolicy)
	* [multipathd] cleanly separate out the checker selector, as
	  done with iopolicy selector
	* [multipathd] move out the checkers into a common libcheckers
	* [multipath] fix the anti-parallel-exec logic : use a write
	  lease for the task. From Dave Olien at osdl.
	* [multipath] fix reinstate : pass a devt, not a devname

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

[ANNOUNCE] multipath-tools-0.3.3

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.3

Suse and OSDL reviews continue, keeping the flow of changes high.
Early release to keep interested people in sync.

Full ChangeLog for the release :

	* [checkers] add the emc_clariion path checker (lmb at Suse)
	* [multipath] introduce safe_snprintf macro to complement the
	  safe_sprintf. Needed to cover the sizeof(pointer) cases
	  pointed by Dave Olien at OSDL
	* [multipath] move to the common libchecker framework and
	  activate the selector
	* [multipath] fix an iopolicy selector bug (initialized lun
	  iopolicy overrode controler-wide iopolicy)
	* [multipathd] cleanly separate out the checker selector, as
	  done with iopolicy selector
	* [multipathd] move out the checkers into a common libcheckers
	* [multipath] fix the anti-parallel-exec logic : use a write
	  lease for the task. From Dave Olien at osdl.
	* [multipath] fix reinstate : pass a devt, not a devname

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.4

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.4

Many structural change, consequences of the Suse review.
Highlights are :

	* glibc compilation, uses system libraries where possible
	* multipath & multipathd now use the same path checkers.
	  Consequence being multipath now need sg loaded
	* checkers now can return more than UP or DOWN and they take
	  2 more arguments :
		* msg : to let the checker pass log mesg to the core
		* context : a persistent data store the checkers can
		  use at discretion
	* multipath pgpolicies rework : I broke the group_by_serial
	  LUN balancing. This is volontary : I'd like someone affected
	  to come up with a callout binary to do the balancing based on
	  the priority framework.

Full ChangeLog for the release :

	* [multipathd] exec multipath precisely : pass in the path
	  or the devmap to update. No more full reconfiguration, and
	  really use the reinstate feature of multipath.
	* [multipathd] check all paths, not only failed ones. Path
	  checker now trigger on state change (formerly triggred on
	  state == UP condition)
	* [multipathd] incremental updatepaths() instead of scrap /
	  refresh all logic.
	* [multipathd] path checkers now take *msg and *context
	  params. consensus w/ lmb at suse. tur.c modified as example
	* [multipath] assemble maps in PG vector descending order to
	  fit the layered policies design
	* [multipath] stop playing with strings in pgpolicies, as it
	  uses more memory and looses info for no gain
	* [multipath] remove lk2.4 scsi ioctl scsi_type remnant
	* [multipath] layered pgpolicies : (see pgpolicies.c)
		* group_by_status
		* group_by_serial | multibus | failover | group_by_prio
		* sort_pg_by_summed_prio
	  thus remove duplicated failedpath logic in pgpolicies
	* [checkers] framework for arbitrate checkers return values
	* [multipathd] scrap yet another reinvented wheel in the 
	  name of the LOG macro :  learn the existance of setloglevel
	  and LOG_UPTO macro
	* glibc make with "make BUILD=glibc", asked by lmb at suse

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

[ANNOUNCE] multipath-tools-0.3.4

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.4

Many structural change, consequences of the Suse review.
Highlights are :

	* glibc compilation, uses system libraries where possible
	* multipath & multipathd now use the same path checkers.
	  Consequence being multipath now need sg loaded
	* checkers now can return more than UP or DOWN and they take
	  2 more arguments :
		* msg : to let the checker pass log mesg to the core
		* context : a persistent data store the checkers can
		  use at discretion
	* multipath pgpolicies rework : I broke the group_by_serial
	  LUN balancing. This is volontary : I'd like someone affected
	  to come up with a callout binary to do the balancing based on
	  the priority framework.

Full ChangeLog for the release :

	* [multipathd] exec multipath precisely : pass in the path
	  or the devmap to update. No more full reconfiguration, and
	  really use the reinstate feature of multipath.
	* [multipathd] check all paths, not only failed ones. Path
	  checker now trigger on state change (formerly triggred on
	  state = UP condition)
	* [multipathd] incremental updatepaths() instead of scrap /
	  refresh all logic.
	* [multipathd] path checkers now take *msg and *context
	  params. consensus w/ lmb at suse. tur.c modified as example
	* [multipath] assemble maps in PG vector descending order to
	  fit the layered policies design
	* [multipath] stop playing with strings in pgpolicies, as it
	  uses more memory and looses info for no gain
	* [multipath] remove lk2.4 scsi ioctl scsi_type remnant
	* [multipath] layered pgpolicies : (see pgpolicies.c)
		* group_by_status
		* group_by_serial | multibus | failover | group_by_prio
		* sort_pg_by_summed_prio
	  thus remove duplicated failedpath logic in pgpolicies
	* [checkers] framework for arbitrate checkers return values
	* [multipathd] scrap yet another reinvented wheel in the 
	  name of the LOG macro :  learn the existance of setloglevel
	  and LOG_UPTO macro
	* glibc make with "make BUILD=glibc", asked by lmb at suse

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.3.4

[Arjan van de Ven]

On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:

> 	* multipath & multipathd now use the same path checkers.
> 	  Consequence being multipath now need sg loaded

why sg and not using SG_IO on the actual devices ?
mp-tools are 2.6 only anyway, right ?
-- 

Re: [ANNOUNCE] multipath-tools-0.3.4

[Arjan van de Ven]

On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:

> 	* multipath & multipathd now use the same path checkers.
> 	  Consequence being multipath now need sg loaded

why sg and not using SG_IO on the actual devices ?
mp-tools are 2.6 only anyway, right ?
-- 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.3.4

[christophe.varoqui]

Selon Arjan van de Ven <arjan@infradead.org>:

> On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:
>
> > 	* multipath & multipathd now use the same path checkers.
> > 	  Consequence being multipath now need sg loaded
>
> why sg and not using SG_IO on the actual devices ?
> mp-tools are 2.6 only anyway, right ?
>
Glad you notice :)

In fact all the sg stuff I use is done with the SG_IO ioctl (see
libcheckers/*.c)
But somehow, it doesn't work as expected. I don't remember how exactly it failed
in my tests but it did ... I remembered receiving bad path status and
experiencing blocked checkers.

I would really like someone experienced put his nose in this stuff. If you want,
I can code up a flag to switch the mp-tools ioctl submission between blockdev
and sgdev.

Note you don't need to have real multipathed hardware to run and test the thing
: parallel SCSI hw suffice and is seen as monopath.

regards,
cvaroqui
--

Re: [ANNOUNCE] multipath-tools-0.3.4

[christophe.varoqui]

Selon Arjan van de Ven <arjan@infradead.org>:

> On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:
>
> > 	* multipath & multipathd now use the same path checkers.
> > 	  Consequence being multipath now need sg loaded
>
> why sg and not using SG_IO on the actual devices ?
> mp-tools are 2.6 only anyway, right ?
>
Glad you notice :)

In fact all the sg stuff I use is done with the SG_IO ioctl (see
libcheckers/*.c)
But somehow, it doesn't work as expected. I don't remember how exactly it failed
in my tests but it did ... I remembered receiving bad path status and
experiencing blocked checkers.

I would really like someone experienced put his nose in this stuff. If you want,
I can code up a flag to switch the mp-tools ioctl submission between blockdev
and sgdev.

Note you don't need to have real multipathed hardware to run and test the thing
: parallel SCSI hw suffice and is seen as monopath.

regards,
cvaroqui
--


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.3.4

[Douglas Gilbert]

christophe.varoqui@free.fr wrote:
> Selon Arjan van de Ven <arjan@infradead.org>:
> 
> 
>>On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:
>>
>>
>>>	* multipath & multipathd now use the same path checkers.
>>>	  Consequence being multipath now need sg loaded
>>
>>why sg and not using SG_IO on the actual devices ?
>>mp-tools are 2.6 only anyway, right ?
>>
> 
> Glad you notice :)
> 
> In fact all the sg stuff I use is done with the SG_IO ioctl (see
> libcheckers/*.c)
> But somehow, it doesn't work as expected. I don't remember how exactly it failed
> in my tests but it did ... I remembered receiving bad path status and
> experiencing blocked checkers.
> 
> I would really like someone experienced put his nose in this stuff. If you want,
> I can code up a flag to switch the mp-tools ioctl submission between blockdev
> and sgdev.
> 
> Note you don't need to have real multipathed hardware to run and test the thing
> : parallel SCSI hw suffice and is seen as monopath.

A significant patch from Patrick Mansfield concerning the
error reporting of the block layer SG_IO ioctl is present
in lk 2.6.10-rc1 . It was not present in lk 2.6.9 and earlier.

Doug Gilbert

Re: [ANNOUNCE] multipath-tools-0.3.4

[Douglas Gilbert]

christophe.varoqui@free.fr wrote:
> Selon Arjan van de Ven <arjan@infradead.org>:
> 
> 
>>On Mon, 2004-10-25 at 00:14 +0200, christophe varoqui wrote:
>>
>>
>>>	* multipath & multipathd now use the same path checkers.
>>>	  Consequence being multipath now need sg loaded
>>
>>why sg and not using SG_IO on the actual devices ?
>>mp-tools are 2.6 only anyway, right ?
>>
> 
> Glad you notice :)
> 
> In fact all the sg stuff I use is done with the SG_IO ioctl (see
> libcheckers/*.c)
> But somehow, it doesn't work as expected. I don't remember how exactly it failed
> in my tests but it did ... I remembered receiving bad path status and
> experiencing blocked checkers.
> 
> I would really like someone experienced put his nose in this stuff. If you want,
> I can code up a flag to switch the mp-tools ioctl submission between blockdev
> and sgdev.
> 
> Note you don't need to have real multipathed hardware to run and test the thing
> : parallel SCSI hw suffice and is seen as monopath.

A significant patch from Patrick Mansfield concerning the
error reporting of the block layer SG_IO ioctl is present
in lk 2.6.10-rc1 . It was not present in lk 2.6.9 and earlier.

Doug Gilbert



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] Re: [ANNOUNCE] multipath-tools-0.3.4

[Lars Marowsky-Bree]

On 2004-10-25T11:38:43, christophe.varoqui@free.fr wrote:

> In fact all the sg stuff I use is done with the SG_IO ioctl (see
> libcheckers/*.c) But somehow, it doesn't work as expected. I don't
> remember how exactly it failed in my tests but it did ... I remembered
> receiving bad path status and experiencing blocked checkers.

Can you please clarify the error you saw? I didn't experience that yet
with the SG_IO ioctl().


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] Re: [ANNOUNCE] multipath-tools-0.3.4

[Lars Marowsky-Bree]

On 2004-10-25T11:38:43, christophe.varoqui@free.fr wrote:

> In fact all the sg stuff I use is done with the SG_IO ioctl (see
> libcheckers/*.c) But somehow, it doesn't work as expected. I don't
> remember how exactly it failed in my tests but it did ... I remembered
> receiving bad path status and experiencing blocked checkers.

Can you please clarify the error you saw? I didn't experience that yet
with the SG_IO ioctl().


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] Re: [ANNOUNCE] multipath-tools-0.3.4

[Mike Christie]

Lars Marowsky-Bree wrote:

> On 2004-10-25T11:38:43, christophe.varoqui@free.fr wrote:
> 
> 
>>In fact all the sg stuff I use is done with the SG_IO ioctl (see
>>libcheckers/*.c) But somehow, it doesn't work as expected. I don't
>>remember how exactly it failed in my tests but it did ... I remembered
>>receiving bad path status and experiencing blocked checkers.
> 
> 
> Can you please clarify the error you saw? I didn't experience that yet
> with the SG_IO ioctl().
> 

I think it was because of this bug
http://marc.theaimsgroup.com/?l=linux-scsi&m=108617935710955&w=2

If you are using qla2xxx and you unplug the cable, the qlogic driver
will return did_not_connect in the host byte. If you used
the block layer sg io code you will then not get the host bytes
returned to you, and the checker will always think the patch
is back up.


> Sincerely,
>     Lars Marowsky-Brée <lmb@suse.de>
> 



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click

Re: [dm-devel] Re: [ANNOUNCE] multipath-tools-0.3.4

[Mike Christie]

Lars Marowsky-Bree wrote:

> On 2004-10-25T11:38:43, christophe.varoqui@free.fr wrote:
> 
> 
>>In fact all the sg stuff I use is done with the SG_IO ioctl (see
>>libcheckers/*.c) But somehow, it doesn't work as expected. I don't
>>remember how exactly it failed in my tests but it did ... I remembered
>>receiving bad path status and experiencing blocked checkers.
> 
> 
> Can you please clarify the error you saw? I didn't experience that yet
> with the SG_IO ioctl().
> 

I think it was because of this bug
http://marc.theaimsgroup.com/?l=linux-scsi&m\x108617935710955&w=2

If you are using qla2xxx and you unplug the cable, the qlogic driver
will return did_not_connect in the host byte. If you used
the block layer sg io code you will then not get the host bytes
returned to you, and the checker will always think the patch
is back up.


> Sincerely,
>     Lars Marowsky-Brée <lmb@suse.de>
> 



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.5

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.5

As expected, 0.3.4 was still cutting at the edges, so this is a bugfix oriented
release. Thanks for the feedback so far.

Note the changes to udev config files : they need updating
Note the unproven 2.6.10-rc1+ new dependency for SG_IO ioctl on bdevs.

Full ChangeLog for the release :

	* [multipathd] fix broken test for path going up or shaky
	  that kept executing multipath when it shouldn't
	* change multipath.dev to exit early when udev' DEVNAME is
	  a devmap (/dev/dm-*). This avoids a recursion case when
	  the kernel devmapper keeps removing a map after multipath
	  configures it.
	* change multipath.rules to follow the new -D synthax
	* [multipath] "-D major minor" synthax changed to
	  "-D major:minor" to match the sysfs attribute value.
	  This change removes a few translations in multipath and
	  multipathd.
	* [multipath] fix segfault in test if conf->dev is a devmap
	  (the one forwarded by MikeAnd)
	* SG_IO ioctl seem to work in lk 2.6.10+, so remove all sg
	  device knowledge and advertise (here) the new dependency.
	* [multipath] remove unused do_tur()
	* [multipath] fix sort_pg_by_summed_prio(), and don't add up
	  failed path priority

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.3.5

[christophe.varoqui]

Hello,

here goes multipath-tools-0.3.5

As expected, 0.3.4 was still cutting at the edges, so this is a bugfix oriented
release. Thanks for the feedback so far.

Note the changes to udev config files : they need updating
Note the unproven 2.6.10-rc1+ new dependency for SG_IO ioctl on bdevs.

Full ChangeLog for the release :

	* [multipathd] fix broken test for path going up or shaky
	  that kept executing multipath when it shouldn't
	* change multipath.dev to exit early when udev' DEVNAME is
	  a devmap (/dev/dm-*). This avoids a recursion case when
	  the kernel devmapper keeps removing a map after multipath
	  configures it.
	* change multipath.rules to follow the new -D synthax
	* [multipath] "-D major minor" synthax changed to
	  "-D major:minor" to match the sysfs attribute value.
	  This change removes a few translations in multipath and
	  multipathd.
	* [multipath] fix segfault in test if conf->dev is a devmap
	  (the one forwarded by MikeAnd)
	* SG_IO ioctl seem to work in lk 2.6.10+, so remove all sg
	  device knowledge and advertise (here) the new dependency.
	* [multipath] remove unused do_tur()
	* [multipath] fix sort_pg_by_summed_prio(), and don't add up
	  failed path priority

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
--
christophe varoqui <christophe.varoqui@free.fr>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.6

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.6

Another round of changes and bugfixes. A step further to actually use
the priority framework.

I'm glad to announce Patrick Caulfield agreed to take care of Debian
packaging, thanks again.

Thanks to LTP people too : if only I had noticed before they provide
nice example of clone usage, I would have saved me a lot of headache.
Still, there are bugreports left in this area.

Full ChangeLog for the release :

	* Patrick Caulfield took over debian packaging. Showing
	  evident expertise, his first wish is to see debian/
	  disappear. :) So be it.
	* [libmultipath] add a vector_foreach_slot macro. Still
	  needs an iterator but saves 1 line per loop occurence and
	  tame this UPPERCASE MACROS bad taste.
	* [multipathd] don't load sg anymore on multipathd startup
	* [multipathd] change killall for kill `cat $PIDFILE` in
	  init script (Jaime Peñalba & Cesar Solera)
	* [multipathd] the fork fallback was borked (just exiting)
	  noticed by Jaime Peñalba & Cesar Solera
	* [multipathd] try without the FLOATING_STACKS flag. Does
	  it matter anyway ?
	* [multipathd] merge clone_platform.h from LTP and cover
	  the hppa special case.
	* [multipath] since we will be able to create a devmap with
	  paths too small, don't rely anymore on the first path's
	  size blindly : verify the path is up, before assigning its
	  size to the multipath
	* [priority] add a path priority fetcher to balance LU accross
	  controlers based on the controler serial detection. Untested
	  but provides a good example of what can be done with the
	  priority framework.
	* [priority] create subdir and drop a test pp_random
	* [multipath] add dev_t reporting to print_path() to ease
	  devmap decoding by humans
	* [multipath] change default path priority to 1
	* [multipath] add wits to the sort_by_prio policy, so that
	  sort_pathvec_by_prio() is now useless. Remove it.
	* [multipath] invert sort_pg_by_summed_prio sort order :
	  highest prio leftmost
	* [libmultipath] add vector_del_slot
	* revert multipath.rules change : devmap_name still takes
	  "major minor" and not "major:minor" as argument
	* Makefile refinement : you can now enter any tool directory
	  and build from here, deps are solved

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] multipath-tools-0.3.6

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.6

Another round of changes and bugfixes. A step further to actually use
the priority framework.

I'm glad to announce Patrick Caulfield agreed to take care of Debian
packaging, thanks again.

Thanks to LTP people too : if only I had noticed before they provide
nice example of clone usage, I would have saved me a lot of headache.
Still, there are bugreports left in this area.

Full ChangeLog for the release :

	* Patrick Caulfield took over debian packaging. Showing
	  evident expertise, his first wish is to see debian/
	  disappear. :) So be it.
	* [libmultipath] add a vector_foreach_slot macro. Still
	  needs an iterator but saves 1 line per loop occurence and
	  tame this UPPERCASE MACROS bad taste.
	* [multipathd] don't load sg anymore on multipathd startup
	* [multipathd] change killall for kill `cat $PIDFILE` in
	  init script (Jaime Peñalba & Cesar Solera)
	* [multipathd] the fork fallback was borked (just exiting)
	  noticed by Jaime Peñalba & Cesar Solera
	* [multipathd] try without the FLOATING_STACKS flag. Does
	  it matter anyway ?
	* [multipathd] merge clone_platform.h from LTP and cover
	  the hppa special case.
	* [multipath] since we will be able to create a devmap with
	  paths too small, don't rely anymore on the first path's
	  size blindly : verify the path is up, before assigning its
	  size to the multipath
	* [priority] add a path priority fetcher to balance LU accross
	  controlers based on the controler serial detection. Untested
	  but provides a good example of what can be done with the
	  priority framework.
	* [priority] create subdir and drop a test pp_random
	* [multipath] add dev_t reporting to print_path() to ease
	  devmap decoding by humans
	* [multipath] change default path priority to 1
	* [multipath] add wits to the sort_by_prio policy, so that
	  sort_pathvec_by_prio() is now useless. Remove it.
	* [multipath] invert sort_pg_by_summed_prio sort order :
	  highest prio leftmost
	* [libmultipath] add vector_del_slot
	* revert multipath.rules change : devmap_name still takes
	  "major minor" and not "major:minor" as argument
	* Makefile refinement : you can now enter any tool directory
	  and build from here, deps are solved

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.7

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.7

Resync before commencing adjusting for new kernel driver rules.
Note, the default build is now "glibc" to ease packagers work.
Important bugfixes from Suse.

Full ChangeLog for the release :

	* [libmultipath] make the config file parser play nice
	  with the stack (Hannes, Suse)
	* [multipathd] fix off by one memory allocation (Hannes,
	  Suse)
	* [multipathd] introduce a default callout handler that
	  just remembers to put the callout in ramfs, even if the
	  daemon has no direct use of them. multipath need some
	  that where forgotten, so parse them and use that default
	  handler.
	* [libcheckers] emc_clariion checker update (heinz, Suse)
	* [build] exit build process on failure (heinz, Suse)
	* [kpartx] exit early if DM prereq not met
	* [multipath] exit early if DM prereq not met
	* [libmultipath] new dm_prereq() fn to check out if all DM
	  prerequisites are met
	* [libmultipath] move callout.[ch] function in there.
	  multipath and multipathd impacted
	* [libmultipath] move dm_* function in there. kpartx,
	  multipath are impacted
	* [priority] pp_balance_lun should use DM_DEVICE_TABLE ioctl
	  instead of DM_DEVICE_STATUS to find out paths from the
	  primary path groups.
	* [klibc] drop in "Stable" version 0.190
	* [build] add manpages for kpartx and multipathd (Patrick
	  Caulfield)
	* [build] use system's sysfs for multipathd linking
	* [build] make glibc the default build
	* [build] "make BUILD=klibc" is enough, deprecate the 
	  "make BUILD=klibc klibc" synthax

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

[ANNOUNCE] multipath-tools-0.3.7

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.7

Resync before commencing adjusting for new kernel driver rules.
Note, the default build is now "glibc" to ease packagers work.
Important bugfixes from Suse.

Full ChangeLog for the release :

	* [libmultipath] make the config file parser play nice
	  with the stack (Hannes, Suse)
	* [multipathd] fix off by one memory allocation (Hannes,
	  Suse)
	* [multipathd] introduce a default callout handler that
	  just remembers to put the callout in ramfs, even if the
	  daemon has no direct use of them. multipath need some
	  that where forgotten, so parse them and use that default
	  handler.
	* [libcheckers] emc_clariion checker update (heinz, Suse)
	* [build] exit build process on failure (heinz, Suse)
	* [kpartx] exit early if DM prereq not met
	* [multipath] exit early if DM prereq not met
	* [libmultipath] new dm_prereq() fn to check out if all DM
	  prerequisites are met
	* [libmultipath] move callout.[ch] function in there.
	  multipath and multipathd impacted
	* [libmultipath] move dm_* function in there. kpartx,
	  multipath are impacted
	* [priority] pp_balance_lun should use DM_DEVICE_TABLE ioctl
	  instead of DM_DEVICE_STATUS to find out paths from the
	  primary path groups.
	* [klibc] drop in "Stable" version 0.190
	* [build] add manpages for kpartx and multipathd (Patrick
	  Caulfield)
	* [build] use system's sysfs for multipathd linking
	* [build] make glibc the default build
	* [build] "make BUILD=klibc" is enough, deprecate the 
	  "make BUILD=klibc klibc" synthax

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.8

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.8

This is just getting too big a ChangeLog.
This release was lighly tested, expect some glitches. Let's call that a
developer release.

Warning, there are config file synthax changes :
* in the callouts declarations (item 1)
* new keyword : prio_callout in the device block

The path_priority example is getting usable.

A new "-F" command line flag, to flush all multipath maps.

You will need 2.6.10-rc*-udm for this release : the map synthax is
updated but still not the logic to avoid map reloads.

Full ChangeLog for the release :

	* [priority] teach multipath to read callout keywords
	  formatted as /sbin/scsi_id -g -u -s /block/%n
	  Apply one substitutions out of :
		* %n : blockdev basename (ie sdb)
		* %d : blockdev major:minor string (ie 8:16)
	  update sample config files
	* [priority] fix find_controler(). Now works, verified
	  on IBM T200 at OSDL (thanks again, Dave). Add to the
	  main build process
	* [multipath] add a controler specific "prio_callout"
	  keyword. Noticed by Ake
	* [multipath] normalize the debug ouput
	* [multipath] add select_getuid(). De-spaghetti
	  devinfo() thanks to that helper.
	* [libmultipath] add VECTOR_LAST_SLOT macro.
	  multipath/dict.h now use it heavily.
	* [multipath] policies selectors speedup and cleanup
	  (pgpolicy, features, hwhandler, selector)
	* [multipath] new "flush" command flag
	* [libmultipath] add dm_type() and dm_flush_maps()
	* [multipath] move dm_get_map() to libmultipath
	* [multipath] rename iopolicy to pgpolicy everywhere.
	  Dual terminology was getting confusing.
	* [multipath] assemble_map() to always set next_pg to 1
	  for now.
	* [multipath] update config file to show new keywords.
	  Add an IBM array tested at OSDL.
	* [multipath] fork select_iopolicy() from setup_map()
	* [multipath] introduce select_features() and 
	  select_hwhandler(). Should merge select_* one day ...
	* [multipath] add features and hardware_handler keywords
	  and use them in the map setup
	* [build] make clean really clean. Noticed by Dave Olien,
	  OSDL
	* [multipath] group_by_serial bugfix
	* [multipath] dm_addmap() return value fix. Now multipath
	  really creates the maps
	* [multipath] try dm_log_init_verbose() instead of dup()
	  + close() to silence libdevmapper (Ake at umu)
	* [libcheckers] remove checkpath() wrapper, obsoleted by
	  the "fd in context" changes
	* [multipathd] let pathcheckers allocate their context.
	  No more over or unneeded allocation.  Suggested by Lars,
	  Suse
	* [multipathd] store the pathcheckers fd in their context.
	  No more open / close on each check. Suggested by Lars,
	  Suse

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

[ANNOUNCE] multipath-tools-0.3.8

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.8

This is just getting too big a ChangeLog.
This release was lighly tested, expect some glitches. Let's call that a
developer release.

Warning, there are config file synthax changes :
* in the callouts declarations (item 1)
* new keyword : prio_callout in the device block

The path_priority example is getting usable.

A new "-F" command line flag, to flush all multipath maps.

You will need 2.6.10-rc*-udm for this release : the map synthax is
updated but still not the logic to avoid map reloads.

Full ChangeLog for the release :

	* [priority] teach multipath to read callout keywords
	  formatted as /sbin/scsi_id -g -u -s /block/%n
	  Apply one substitutions out of :
		* %n : blockdev basename (ie sdb)
		* %d : blockdev major:minor string (ie 8:16)
	  update sample config files
	* [priority] fix find_controler(). Now works, verified
	  on IBM T200 at OSDL (thanks again, Dave). Add to the
	  main build process
	* [multipath] add a controler specific "prio_callout"
	  keyword. Noticed by Ake
	* [multipath] normalize the debug ouput
	* [multipath] add select_getuid(). De-spaghetti
	  devinfo() thanks to that helper.
	* [libmultipath] add VECTOR_LAST_SLOT macro.
	  multipath/dict.h now use it heavily.
	* [multipath] policies selectors speedup and cleanup
	  (pgpolicy, features, hwhandler, selector)
	* [multipath] new "flush" command flag
	* [libmultipath] add dm_type() and dm_flush_maps()
	* [multipath] move dm_get_map() to libmultipath
	* [multipath] rename iopolicy to pgpolicy everywhere.
	  Dual terminology was getting confusing.
	* [multipath] assemble_map() to always set next_pg to 1
	  for now.
	* [multipath] update config file to show new keywords.
	  Add an IBM array tested at OSDL.
	* [multipath] fork select_iopolicy() from setup_map()
	* [multipath] introduce select_features() and 
	  select_hwhandler(). Should merge select_* one day ...
	* [multipath] add features and hardware_handler keywords
	  and use them in the map setup
	* [build] make clean really clean. Noticed by Dave Olien,
	  OSDL
	* [multipath] group_by_serial bugfix
	* [multipath] dm_addmap() return value fix. Now multipath
	  really creates the maps
	* [multipath] try dm_log_init_verbose() instead of dup()
	  + close() to silence libdevmapper (Ake at umu)
	* [libcheckers] remove checkpath() wrapper, obsoleted by
	  the "fd in context" changes
	* [multipathd] let pathcheckers allocate their context.
	  No more over or unneeded allocation.  Suggested by Lars,
	  Suse
	* [multipathd] store the pathcheckers fd in their context.
	  No more open / close on each check. Suggested by Lars,
	  Suse

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.3.9

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.9

This release implements the new kernel multipath policies : 
      * no table reload when possible 
      * use of "switch_group" and "reinstate_path" DM messages instead

A much improved and informational output format too.
And a new '-l' flag to list current multipath topology 

Full ChangeLog for the release :

        * [multipath] add a "-l" flag to list the current
          multipath maps and their status info
        * [priority] zalloc controler to avoid random path_count
          at allocation time
        * [multipath] add configlet pointers in struct multipath
          to avoid searching for an entry over and over again
        * [multipath] new reinstate policy : on multipath exec,
          reinstate all failed paths the checkers report as ready
          if they belong to enabled path groups (not disabled, not
          active path group)
        * [multipath] fork a print_mp() out of print_all_mp()
        * [multipath] introduce PG priority, which is the sum of
          its path priorities. Set first_pg in the map string to
          the highest prio PG index.
        * [multipath] assemble maps scaning PG top down now that
          PG vector is unsorted
        * [multipath] move select_*() to propsel.c
        * [multipath] move devinfo() to devinfo.c
        * [multipath] move h/b/t/l fetching to sysfs_devinfo()
        * [multipath] move devt2devname() to devinfo.c so we can
          use it from dmparser.c too
        * [multipath] introduce select_alias() and clarify a bit
          of code
        * [multipath] don't sort PG anymore. We want the map as
          static as possible.
        * [multipath] fix a segfault in apply_format() triggered
          when no config file found.
        * [multipath] kill unused vars all over the place
        * [multipath] add a struct pathgroup in struct multipath
          Store the pathvec in it. We now have a place to store
          PG status, etc ...
        * [multipath] new dmparser.c, with disassemble_map(),
          disassemble_status()
        * [multipath] suppress *selector_args keywords. Merge
          in the selector string. Update config file templates.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.3.9

[christophe varoqui]

Hello,

here goes multipath-tools-0.3.9

This release implements the new kernel multipath policies : 
      * no table reload when possible 
      * use of "switch_group" and "reinstate_path" DM messages instead

A much improved and informational output format too.
And a new '-l' flag to list current multipath topology 

Full ChangeLog for the release :

        * [multipath] add a "-l" flag to list the current
          multipath maps and their status info
        * [priority] zalloc controler to avoid random path_count
          at allocation time
        * [multipath] add configlet pointers in struct multipath
          to avoid searching for an entry over and over again
        * [multipath] new reinstate policy : on multipath exec,
          reinstate all failed paths the checkers report as ready
          if they belong to enabled path groups (not disabled, not
          active path group)
        * [multipath] fork a print_mp() out of print_all_mp()
        * [multipath] introduce PG priority, which is the sum of
          its path priorities. Set first_pg in the map string to
          the highest prio PG index.
        * [multipath] assemble maps scaning PG top down now that
          PG vector is unsorted
        * [multipath] move select_*() to propsel.c
        * [multipath] move devinfo() to devinfo.c
        * [multipath] move h/b/t/l fetching to sysfs_devinfo()
        * [multipath] move devt2devname() to devinfo.c so we can
          use it from dmparser.c too
        * [multipath] introduce select_alias() and clarify a bit
          of code
        * [multipath] don't sort PG anymore. We want the map as
          static as possible.
        * [multipath] fix a segfault in apply_format() triggered
          when no config file found.
        * [multipath] kill unused vars all over the place
        * [multipath] add a struct pathgroup in struct multipath
          Store the pathvec in it. We now have a place to store
          PG status, etc ...
        * [multipath] new dmparser.c, with disassemble_map(),
          disassemble_status()
        * [multipath] suppress *selector_args keywords. Merge
          in the selector string. Update config file templates.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.4.0

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.0

This is bugfix release.
An important checker file descriptor leak fix, and checker context
allocation size fix. 
Don't print unchanged maps anymore and display adaptative human friendly
map size units.


Full ChangeLog for the release :

        * [checkers] forgot to return back to caller the newly
          allocated context. Lead to fd leak notably.
        * [checkers] heavy check logic fix
        * [checkers] really malloc the checker context size,
          not the pointer size (stupidy may kill)
        * [multipathd] check more sysfs calls return values
        * [multipathd] search for sysfs mount point only once,
          not on each updatepaths() iteration
        * [multipathd] plug (char *) leak in the daemon
        * [multipath] change pgcmp logic : we want to reload a
          map only if a path is in computed map but not in cur
          map (ie accept to load a map if it brings more paths)
        * [multipath] undust coalesce_paths()
        * [multipath] don't print unchanged multipath
        * [multipath] store the action to take in the multipath
          struct
        * [multipath] print mp size with kB, MB, GB or TB units
        * [multipath] compilation fix for merge_words() (Andy)
        * [multipath] don't feed the kernel DM maps with paths of
          different sizes : DM fails and we end up with an empty
          map ... not fun
        * [multipath] cover a new corner case : path listed in
          status string but disappeared from sysfs
        * [multipath] remove the "-D" command line flag : now
          we can pass major:minor directly as last argument, like
          device names or device map names. Update multipathd
          accordingly.
        * [multipath] try reinstate again paths after a switchpg
        * [multipath] reinstate condition change :

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.4.0

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.0

This is bugfix release.
An important checker file descriptor leak fix, and checker context
allocation size fix. 
Don't print unchanged maps anymore and display adaptative human friendly
map size units.


Full ChangeLog for the release :

        * [checkers] forgot to return back to caller the newly
          allocated context. Lead to fd leak notably.
        * [checkers] heavy check logic fix
        * [checkers] really malloc the checker context size,
          not the pointer size (stupidy may kill)
        * [multipathd] check more sysfs calls return values
        * [multipathd] search for sysfs mount point only once,
          not on each updatepaths() iteration
        * [multipathd] plug (char *) leak in the daemon
        * [multipath] change pgcmp logic : we want to reload a
          map only if a path is in computed map but not in cur
          map (ie accept to load a map if it brings more paths)
        * [multipath] undust coalesce_paths()
        * [multipath] don't print unchanged multipath
        * [multipath] store the action to take in the multipath
          struct
        * [multipath] print mp size with kB, MB, GB or TB units
        * [multipath] compilation fix for merge_words() (Andy)
        * [multipath] don't feed the kernel DM maps with paths of
          different sizes : DM fails and we end up with an empty
          map ... not fun
        * [multipath] cover a new corner case : path listed in
          status string but disappeared from sysfs
        * [multipath] remove the "-D" command line flag : now
          we can pass major:minor directly as last argument, like
          device names or device map names. Update multipathd
          accordingly.
        * [multipath] try reinstate again paths after a switchpg
        * [multipath] reinstate condition change :

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

ISCSI

[Guy]

I have a SCSI tape drive on my Linux system.  I want to use the tape drive
from another system with another (evil) OS.  I have found more than 1 source
forge project related to ISCSI.  These projects seem to only talk about disk
access (SAN), not tape access.  I can't determine which I should use, if
any.

Does anyone know which is best?
I have kernel 2.4.28, but would be willing to attempt an upgrade if needed.

Thanks,
Guy

Re: ISCSI

[Ming Zhang]

i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
you needs. IET will support a bypass interface later.

Ming

On Sun, 2004-12-12 at 13:08, Guy wrote:
> I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> from another system with another (evil) OS.  I have found more than 1 source
> forge project related to ISCSI.  These projects seem to only talk about disk
> access (SAN), not tape access.  I can't determine which I should use, if
> any.
> 
> Does anyone know which is best?
> I have kernel 2.4.28, but would be willing to attempt an upgrade if needed.
> 
> Thanks,
> Guy
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ISCSI

[Guy]

As suggested, I am attempting to install UNH iSCSI, but having some
problems.

Readme says:
- The appropriate way to install this package is :
   1. mkdir <name> ; tar -zxf <tarball>
   2. cd <name>/unh_iscsi/src/
   3. ./Configure
   4. make rpm
   5. rpm -ivh  /usr/src/redhat/RPMS/i386/unh_iscsi-1.5-0X.i386.rpm

When I do "make rpm" I get this error:
tar cf /usr/src/redhat/SOURCES/unh_iscsi.tar  .
tar: /usr/src/redhat/SOURCES/unh_iscsi.tar: Cannot open: No such file or
directory
tar: Error is not recoverable: exiting now
make: *** [rpm] Error 2

Are there some prerequisites that are needed?
Or am I just doing something wrong.

Also, could you give me a link to SCST?  Or is this included in UNH iSCSI?

Thanks,
Guy


-----Original Message-----
From: Ming Zhang [mailto:mingz@ele.uri.edu] 
Sent: Sunday, December 12, 2004 1:55 PM
To: Guy
Cc: linux-scsi
Subject: Re: ISCSI

i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
you needs. IET will support a bypass interface later.

Ming

On Sun, 2004-12-12 at 13:08, Guy wrote:
> I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> from another system with another (evil) OS.  I have found more than 1
source
> forge project related to ISCSI.  These projects seem to only talk about
disk
> access (SAN), not tape access.  I can't determine which I should use, if
> any.
> 
> Does anyone know which is best?
> I have kernel 2.4.28, but would be willing to attempt an upgrade if
needed.
> 
> Thanks,
> Guy
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ISCSI

[Ming Zhang]

for scst, go http://scst.sourceforge.net/

for questions about unh iscsi, pls go and ask at
http://sourceforge.net/forum/forum.php?forum_id=265256

ming

On Sun, 2004-12-12 at 16:07, Guy wrote:
> As suggested, I am attempting to install UNH iSCSI, but having some
> problems.
> 
> Readme says:
> - The appropriate way to install this package is :
>    1. mkdir <name> ; tar -zxf <tarball>
>    2. cd <name>/unh_iscsi/src/
>    3. ./Configure
>    4. make rpm
>    5. rpm -ivh  /usr/src/redhat/RPMS/i386/unh_iscsi-1.5-0X.i386.rpm
> 
> When I do "make rpm" I get this error:
> tar cf /usr/src/redhat/SOURCES/unh_iscsi.tar  .
> tar: /usr/src/redhat/SOURCES/unh_iscsi.tar: Cannot open: No such file or
> directory
> tar: Error is not recoverable: exiting now
> make: *** [rpm] Error 2
> 
> Are there some prerequisites that are needed?
> Or am I just doing something wrong.
> 
> Also, could you give me a link to SCST?  Or is this included in UNH iSCSI?
> 
> Thanks,
> Guy
> 
> 
> -----Original Message-----
> From: Ming Zhang [mailto:mingz@ele.uri.edu] 
> Sent: Sunday, December 12, 2004 1:55 PM
> To: Guy
> Cc: linux-scsi
> Subject: Re: ISCSI
> 
> i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
> you needs. IET will support a bypass interface later.
> 
> Ming
> 
> On Sun, 2004-12-12 at 13:08, Guy wrote:
> > I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> > from another system with another (evil) OS.  I have found more than 1
> source
> > forge project related to ISCSI.  These projects seem to only talk about
> disk
> > access (SAN), not tape access.  I can't determine which I should use, if
> > any.
> > 
> > Does anyone know which is best?
> > I have kernel 2.4.28, but would be willing to attempt an upgrade if
> needed.
> > 
> > Thanks,
> > Guy
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.1

Another round of bugfixes.
People are starting to report sane behaviour.

If someone at IBM (or knowledgeable enough) is listening, we need a
method to check a path status on a T200 that don't trigger a controler
bounce. Is it possible at all ?

Full ChangeLog for the release :

        * [multipath] bump SERIAL_SIZE to 19
        * [multipath] add a new group_by_node_name pgpolicy
        * [multipath] move getopt policy parser to
          get_policy_id()
        * [multipath] remove get_evpd_wwid()
        * [checkers] fix the wwn_set test in emc checker
          (Hergen Lange)
        * [checkers] treat the emc checker in the name to
          index translator function (Hergen Lange)
        * [multipath] print to stderr DM unmet requirement
          (Guido Guenther)
        * [multipath] fix realloc return value store not
          propagated to caller by merge_word() (Nicola Ranaldo)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.1

Another round of bugfixes.
People are starting to report sane behaviour.

If someone at IBM (or knowledgeable enough) is listening, we need a
method to check a path status on a T200 that don't trigger a controler
bounce. Is it possible at all ?

Full ChangeLog for the release :

        * [multipath] bump SERIAL_SIZE to 19
        * [multipath] add a new group_by_node_name pgpolicy
        * [multipath] move getopt policy parser to
          get_policy_id()
        * [multipath] remove get_evpd_wwid()
        * [checkers] fix the wwn_set test in emc checker
          (Hergen Lange)
        * [checkers] treat the emc checker in the name to
          index translator function (Hergen Lange)
        * [multipath] print to stderr DM unmet requirement
          (Guido Guenther)
        * [multipath] fix realloc return value store not
          propagated to caller by merge_word() (Nicola Ranaldo)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.4.2

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.2

The focuses of this release are :
1) bugfixing and stabilization after the DM synthax change
2) code factorizing between the configurator and the daemon

Full ChangeLog for the release :

        * [libmultipath] add symmetrix controler family to the
          hwtable. Edward Goggin, EMC
        * [libmultipath] factorize core structs (path, ...)
          and defaults (pidfile, configfile, ...). Convert
          callers.
        * [multipath] fix dmparser to properly fetch non-default
          hwhandler. Edward Goggin, EMC
        * [multipath] fix devt2devname matching 8:1 with 8:10
          for example. Edward Goggin, EMC
        * [multipath] switch_pg upon devmap create or reload
          Noticed by Ake.
        * [libmultipath] move find_hw() the library. Convert
          users. Now multipathd understand '*' as a product
          string
        * [multipath] dissaemble_map() fix to avoid to
          interpret 'D' as a disable PG (not 'F'). Edward
          Goggin, EMC
        * [multipath] find_path() fix to avoid matching 8:1
          with 8:10 for example. Edward Goggin, EMC
        * [libmultipath] move some sysfs fetching routines
          to library, under sysfs_devinfo.[ch]. Convert
          callers.
        * [multipath] fix -v0 : avoids the daemon waiting
          for the initial multipath run to complete, which
          will never happen because of a flooded pipe
        * [multipathd] add scsi_id to default binvec
        * [libmultipath] move hwtable related logic to the
          library. Convert multipath and multipathd
        * [multipath] move first blacklist call down after
          setup_default_blist()
        * [libmultipath] move basename() to the lib. Convert
          multipath and multipathd.
        * [libmultipath] move blacklist related logic to the
          library. Convert multipath and multipathd
        * [multipath] fix bug in the default hardware table
          matching logic (Lars M-B, Suse)
        * [multipath] allow "*" as scsi model string wildcard
          (Lars M-B, Suse)
        * [multipath] provide a macro to fill all hwe fields,
          use it to declare Clariion models (Lars M-B, Suse)
        * [multipath] use DEFAULT_GETUID instead of hardcoded
          *and* incorrect "/bin/scsi_id -g -s" (Lars M-B, Suse)
        * [multipath] kill superfluous suspend before table
          reload. The code was unsafe, as spotted by Edward
          Goggin (EMC)
        * [multipath] exit early if device parameter is
          blacklisted
        * [multipath] don't check for prefix in initrd's
          multipath.dev : this is the tool responsability to
          exit early based on its blacklist.
        * [multipath] don't signal the daemon in initrd
          (Guido Guenther, Debian tracker)
        * [multipath] better fail to run kpartx in initrd
          than crashing the whole system. So don't sleep
          waiting for udev to create the DM node. Maybe udev
          has made progress I this regard ... (noticed by
          Paul Wagland, Debian tracker)
        * [multipath] don't reinstate when listing, ie list
          implies dry_run
        * [checkers] fix the emc checker (Hergen Lange)
        * [multipath] node_name fetching shouldn't exit on
          error. FC SAN are not the only multipathed context
          (noticed by Ramesh Caushik)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

[ANNOUNCE] multipath-tools-0.4.2

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.2

The focuses of this release are :
1) bugfixing and stabilization after the DM synthax change
2) code factorizing between the configurator and the daemon

Full ChangeLog for the release :

        * [libmultipath] add symmetrix controler family to the
          hwtable. Edward Goggin, EMC
        * [libmultipath] factorize core structs (path, ...)
          and defaults (pidfile, configfile, ...). Convert
          callers.
        * [multipath] fix dmparser to properly fetch non-default
          hwhandler. Edward Goggin, EMC
        * [multipath] fix devt2devname matching 8:1 with 8:10
          for example. Edward Goggin, EMC
        * [multipath] switch_pg upon devmap create or reload
          Noticed by Ake.
        * [libmultipath] move find_hw() the library. Convert
          users. Now multipathd understand '*' as a product
          string
        * [multipath] dissaemble_map() fix to avoid to
          interpret 'D' as a disable PG (not 'F'). Edward
          Goggin, EMC
        * [multipath] find_path() fix to avoid matching 8:1
          with 8:10 for example. Edward Goggin, EMC
        * [libmultipath] move some sysfs fetching routines
          to library, under sysfs_devinfo.[ch]. Convert
          callers.
        * [multipath] fix -v0 : avoids the daemon waiting
          for the initial multipath run to complete, which
          will never happen because of a flooded pipe
        * [multipathd] add scsi_id to default binvec
        * [libmultipath] move hwtable related logic to the
          library. Convert multipath and multipathd
        * [multipath] move first blacklist call down after
          setup_default_blist()
        * [libmultipath] move basename() to the lib. Convert
          multipath and multipathd.
        * [libmultipath] move blacklist related logic to the
          library. Convert multipath and multipathd
        * [multipath] fix bug in the default hardware table
          matching logic (Lars M-B, Suse)
        * [multipath] allow "*" as scsi model string wildcard
          (Lars M-B, Suse)
        * [multipath] provide a macro to fill all hwe fields,
          use it to declare Clariion models (Lars M-B, Suse)
        * [multipath] use DEFAULT_GETUID instead of hardcoded
          *and* incorrect "/bin/scsi_id -g -s" (Lars M-B, Suse)
        * [multipath] kill superfluous suspend before table
          reload. The code was unsafe, as spotted by Edward
          Goggin (EMC)
        * [multipath] exit early if device parameter is
          blacklisted
        * [multipath] don't check for prefix in initrd's
          multipath.dev : this is the tool responsability to
          exit early based on its blacklist.
        * [multipath] don't signal the daemon in initrd
          (Guido Guenther, Debian tracker)
        * [multipath] better fail to run kpartx in initrd
          than crashing the whole system. So don't sleep
          waiting for udev to create the DM node. Maybe udev
          has made progress I this regard ... (noticed by
          Paul Wagland, Debian tracker)
        * [multipath] don't reinstate when listing, ie list
          implies dry_run
        * [checkers] fix the emc checker (Hergen Lange)
        * [multipath] node_name fetching shouldn't exit on
          error. FC SAN are not the only multipathed context
          (noticed by Ramesh Caushik)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.4.3

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.3

This is a bugfix and features release.

Things noticable from users' perspective :

      * dropped klibc from the package : now an external dependency.
        Those interested in building the tools with klcc will want to
        download klibc from http://www.kernel.org/pub/linux/libs/klibc/
        or the nearest mirror.
      * optimization work in the multipath tool : shorter code paths and
        less memory utilisation
      * new "multipath -v2 -l $devmap" synthax to limit the scope of the
        list
      * new rr_min_io keyword in the config file
      * allow longer devmaps (256 to 1024 chars)
      * "multipath -F" will no longer flush maps with partitions
        attached

Full ChangeLog for the release :

        * [libmultipath] rename find_[mp|hw] to find_[mp|hw]e and
          introduce a real find_mp().
        * [priority] provison for recursive compilation of prio
          subdirs, in preparation of merging more signicant
          prioritizers. Stephan Bader, IBM
        * [libmultipath] add a netapp controler to the hwtable
        * [libmultipath] blacklist() not to discard sda[0-9]*
          when sda is blacklisted
        * [multipath] add a rr_min_io keyword in config file.
          Suggested by Igor Feoktistov, NetApp
        * [multipath] stop trying to avoid running in parallel
        * [multipath] bump up params size to 1024
        * [multipathd] put prio callouts in to ramfs. Stephan
          Bader, IBM
        * [multipath] simplify multibus pgpolicy : no need to
          copy mp->paths into mp->pg->paths then free source :
          just copy the ptr and set source to NULL.
        * [multipath] sort PG by descending prio value in
          group_by_prio. Stephan Bader, IBM
        * [multipath] fix a bug in group_by_prio that lead to
          creation of multiple PG for a single prio value
        * [multipath] don't store multipaths in a vector anymore :
          free the "struct multipath" after usage.
        * [multipath] multiple optimizations in the exec plan
        * [multipath] allow "multipath -l -v2 [mapname|wwid]"
        * [build] rip off klibc and move to klcc, at last.
          Good job hpa. multipath-tools now depend on klibc
          > 1.0 to build with BUILD=klibc flag.
        * [multipath] never reload a map if no path is up in the
          computed new map
        * [multipath] don't flush maps with open count != 0
        * [libmultipath] add "int *dm_get_opencount(char *map)"
          to devmapper.c
        * [multipath] plug leaks and optimize devinfo.c. From
          Edward Goggin, EMC
        * [multipath] fix the multipath.dev hotplug script to not
          do kpartx stuff in the same run as multipath stuff.
        * [multipath] fix the multipath.dev hotplug script to not
          do kpartx stuff in the same run as multipath stuff.
          Igor Feoktistov, NetApp, noted the devmap symlink was
          not yet present for kpartx to use.
        * [devmap_name] accept major:minor synthax
        * [libmultipath] add "char *dm_mapname(int maj, int min)",
          needed to fail paths from checker thread
        * [libmultipath] move dm_reinstate() in the lib, and add
          dm_fail_path()
        * [multipathd] mark failed path as failed upon DM
          event. This should fix the design bug noticed by
          Ramesh Caushik, Intel, where the daemon didn't run
          multipath when a path went down and up in between 2
          checks.
        * [libmultipath] allow NULL as a pathvec in disassemble_map
          as is passed only for memory optimization
        * [libmultipath] add structs.c to store alloc_*() and
          free_*()
        * [libmultipath] move dmparser.[ch] to the lib.
          remove devinfo.[ch] dependency.
        * [build] fix compilation glitch with BUILD=klibc,
          flags to force use of local libs, remove the link
          dependency in klibc, try to guess kernel sources
          and build dirs. Stefan Bader, IBM
        * [libmultipath] find_hw matching logic to take str
          lengths in account. Noticed by Ramesh Caushik, Intel
        * [multipath] select_action matching logic to take str
          length in account.
        * [multipath] lookup mp alias name earlier (in coalesce)
          Edward Goggin, EMC, noticed we tried to use it before
          it was set up.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.4.3

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.3

This is a bugfix and features release.

Things noticable from users' perspective :

      * dropped klibc from the package : now an external dependency.
        Those interested in building the tools with klcc will want to
        download klibc from http://www.kernel.org/pub/linux/libs/klibc/
        or the nearest mirror.
      * optimization work in the multipath tool : shorter code paths and
        less memory utilisation
      * new "multipath -v2 -l $devmap" synthax to limit the scope of the
        list
      * new rr_min_io keyword in the config file
      * allow longer devmaps (256 to 1024 chars)
      * "multipath -F" will no longer flush maps with partitions
        attached

Full ChangeLog for the release :

        * [libmultipath] rename find_[mp|hw] to find_[mp|hw]e and
          introduce a real find_mp().
        * [priority] provison for recursive compilation of prio
          subdirs, in preparation of merging more signicant
          prioritizers. Stephan Bader, IBM
        * [libmultipath] add a netapp controler to the hwtable
        * [libmultipath] blacklist() not to discard sda[0-9]*
          when sda is blacklisted
        * [multipath] add a rr_min_io keyword in config file.
          Suggested by Igor Feoktistov, NetApp
        * [multipath] stop trying to avoid running in parallel
        * [multipath] bump up params size to 1024
        * [multipathd] put prio callouts in to ramfs. Stephan
          Bader, IBM
        * [multipath] simplify multibus pgpolicy : no need to
          copy mp->paths into mp->pg->paths then free source :
          just copy the ptr and set source to NULL.
        * [multipath] sort PG by descending prio value in
          group_by_prio. Stephan Bader, IBM
        * [multipath] fix a bug in group_by_prio that lead to
          creation of multiple PG for a single prio value
        * [multipath] don't store multipaths in a vector anymore :
          free the "struct multipath" after usage.
        * [multipath] multiple optimizations in the exec plan
        * [multipath] allow "multipath -l -v2 [mapname|wwid]"
        * [build] rip off klibc and move to klcc, at last.
          Good job hpa. multipath-tools now depend on klibc
          > 1.0 to build with BUILD=klibc flag.
        * [multipath] never reload a map if no path is up in the
          computed new map
        * [multipath] don't flush maps with open count != 0
        * [libmultipath] add "int *dm_get_opencount(char *map)"
          to devmapper.c
        * [multipath] plug leaks and optimize devinfo.c. From
          Edward Goggin, EMC
        * [multipath] fix the multipath.dev hotplug script to not
          do kpartx stuff in the same run as multipath stuff.
        * [multipath] fix the multipath.dev hotplug script to not
          do kpartx stuff in the same run as multipath stuff.
          Igor Feoktistov, NetApp, noted the devmap symlink was
          not yet present for kpartx to use.
        * [devmap_name] accept major:minor synthax
        * [libmultipath] add "char *dm_mapname(int maj, int min)",
          needed to fail paths from checker thread
        * [libmultipath] move dm_reinstate() in the lib, and add
          dm_fail_path()
        * [multipathd] mark failed path as failed upon DM
          event. This should fix the design bug noticed by
          Ramesh Caushik, Intel, where the daemon didn't run
          multipath when a path went down and up in between 2
          checks.
        * [libmultipath] allow NULL as a pathvec in disassemble_map
          as is passed only for memory optimization
        * [libmultipath] add structs.c to store alloc_*() and
          free_*()
        * [libmultipath] move dmparser.[ch] to the lib.
          remove devinfo.[ch] dependency.
        * [build] fix compilation glitch with BUILD=klibc,
          flags to force use of local libs, remove the link
          dependency in klibc, try to guess kernel sources
          and build dirs. Stefan Bader, IBM
        * [libmultipath] find_hw matching logic to take str
          lengths in account. Noticed by Ramesh Caushik, Intel
        * [multipath] select_action matching logic to take str
          length in account.
        * [multipath] lookup mp alias name earlier (in coalesce)
          Edward Goggin, EMC, noticed we tried to use it before
          it was set up.

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ANNOUNCE] multipath-tools-0.4.4

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.4

This release seems sane enough to enter enterprise distros, thanks to
all reviewers for their hard work.

Worth noting :

	* 2 new path prioritizers : pp_alua and pp_emc
	* devmap_name can now filter by target_type (-t flag).
	  For example, no output if not "multipath" type.
	* the daemon sets /proc/self/oom_adj to -17, hence is 
	  protected from the oom killer. Watch out for leaks.
	* libdevmapper 1.01.01 or newer is now recquired
	* blacklist synthax is now regex based. Update your config
	  files. The packaged templates are up to date.
	* you can now set wwid in the blacklist
	* multipathd gained a "-v" flag to tune verbosity
	* daemon logging is now staged and asynchronous to avoid
	  syslogd possible hangs
	* droped local klibc, libsysfs and libdevmapper
	* multipath caches path info. Cache expire in 5sec.
	* "multipath -l" accepts a devname or dev_t filter


Full ChangeLog for the release :

        * [path_prio] clarify pp_alua licensing. Stefan Bader, IBM.
        * [devmap_name] add a target_type filter (suggested by Hannes)
          and set DM task device by major:minor rather than parsing
          the full map list.
        * [libmultipath] propagate an error on getprio callout
          failures, so that multipath can mark the map as immutable.
          Reported by Lars Marowsky-Bré, Suse.
        * [libmultipath] move push_callout() from dict.c to config.c
          Use it in store_hwe() to get in multipathd's ramfs the
          callout defined in hwtable.c when no config file is used.
          Reported by Lars Marowsky-Bré, Suse.
        * [checkers] zero sense buffers before use in EMC checker.
          Lars Marowsky-Bré, Suse.
        * [all] pre-release bugfixing effort from Alasdair, Hannes,
          Lars, Benjamin Marzinski
        * [multipathd] set oom_adj to -17 when kernel permits.
          Immune to OOM killer ? agk says : watch out for mem
          leaks :/
        * [multipathd] safety nets from udevd : exit early if
          not root, chdir to / to avoid pining a mount.
        * [multipathd] multipathd could loose events coming from
          sighup or DM waitev. Add a pending_event counter to
          track that.
        * [path_prio] add pp_emc from Lars M Bree, Suse.
        * [path_prio] add pp_alua from Stefan Bader, IBM.
        * [libmultipath] add config.c:load_config(), which sucks
          a big chunk of code out of multipath/main.c.
        * [libmultipath] don't allocate memory in :
                * devmapper.c:dm_get_map()
                * devmapper.c:dm_get_status()
        * [libmultipath] devinfo() a la carte fetching
        * [libmultipath] merge keepalived memory audit framework
          (Thanks again, M. Cassen). Already found and fixed a
          couple of leaks.
        * [libmultipath] flatten/optimize dm_map_present() and
          dm_mapname(). Inspired by Alasdair Kergon, RedHat.
        * [kpartx] dm_map_name() free before use bugfix. Kiyoshi
          Ueda, NEC
        * [kpartx] add hotplug mode. To enable name the binary
          "kpartx.dev". Kiyoshi Ueda, NEC
        * [multipathd] don't loose events in event waiter thread.
          Suggested and prototyped by Edward Goggin, EMC
        * [libmultipath] add return values to vector manipulation
          fonctions. Mem alloc return code audit.
        * [libmultipath] Use "config->udev_dir + path->dev" as
          a path devnode to open instead of mknod'ing for each
          one. Fix some DoS issues regarding usage of /tmp in
          libmultipath/discovery.c:opennode(). Kill unlinknode()
        * [multipathd] merged the redhat init script and stop
          installing one on "make install"
        * [libmultipath] fold safe_sprintf.h into util.h
        * [libmultipath] move blacklist to a real regex matcher
          Example config files updated : check yours !!
        * [multipath] fix path group compare logic to not stop
          comparing at first path in each PG.
        * [multipathd] check if pidfile is a dead remnent of a
          crashed daemon. If so, overwrite it. Suggested by
          Alasdair Kergon, RedHat. Code heavily based on work
          by Andrew Tridgell, Samba Fame.
        * [build] dropped libdevmapper/ and libsysfs/ from the
          package. klibc build is now broken until distributors
          provide klibc compiled static libraries in their
          respective packages.
        * [libmultipath] dm_task_no_open_count() before each DM
          ioctl. Not doing that is reported to cause deadlocks
          in kernel-space. Reported by Edward Goggin, EMC, fix
          suggested by Alasdair Kergon, RedHat
          Note minimal libdevmapper version bumped up to 1.01.
        * [multipath] switched to condlog(). "make DEBUG=N" is
          deprecated. Debug is spat with "-v3" or more.
        * [multipathd] "multipathd -vN" cmdline arg to control
          daemon verbosity. 0 < N < 4. "make LOGLEVEL=N" is
          deprecated.
        * [libmultipath] provide a common condlog() primitive to
          switch lib messages to syslog or stdout depending on
          who uses the lib (daemon or tool).
        * [kpartx] give kpartx a private, slim copy of devmap.[ch]
        * [multipath] allow wwid in blacklist{} config section.
          Kiyoshi Ueda, NEC.
        * [multipathd] set mode value before use (S_IRWXU). Fixes
          RedHat Bugzilla Bug 150665.
        * [all] add ->fd to "struct path *". remove fd from all
          checker context declaration. remove lots of duplicate
          logic. Now a fd is opened only once for path. It should
          also bring a bit safety in contended memory scenarii
        * [libcheckers] remove redundant sg_include.h
        * [libmultipath] merge multipath:dict.[ch] with
          multipathd:dict.[ch] into libmultipath/. move config.h
          there too, add some helper functions to alloc/free
          "struct config *" in a new config.c. Start using a
          config in the daemon.
        * [libmultipath] move dm_geteventnr(), dm_get_maps() and
          dm_switchgroup() in devmapper.[ch]
        * [libmultipath] move path discovery logic in
          libmultipath. merge devinfo.[ch] and sysfs_devinfo.[ch]
          into discovery.[ch]
        * [libmultipath] move config.h in libmultipath. Move
          find_[mp|hw]e in a new config.c. Move "struct hwtable"
          declaration in config.h. Move propsel.[ch] in the
          lib too.
        * [multipathd] use libmultipath:dm_type() instead of
          duplacate and bogus devmap discovery code.
        * [multipathd] asynchronous & non-blocking logger
          thread. Implementation split into a generic log
          lib and a pthread wrapper for locking and events.
          An ipc wrapper could be easily created by
          interested parties.
        * [multipath] add "multipath -l -v2 [devname|devt]"
          support in complement to [mapname|wwid]
        * [kpartx] suppress loop.h private copy. Should fix
          the reported build problems
        * [multipath] do sysfs_get_mnt_path() only one time
          and store in a global var.
        * [multipath] further path discovery optimzation
        * [multipath] purge superfluous includes in main.c
        * [libmultipath] introduce a cache file. expiry set
          to 5 secondes to covert the hotplug event storms.
        * [multipath] split get_pathvec_sysfs(). Introduce
          get_refwwid() and filter_pathvec()


As usual, doc and download at :
http://christophe.varoqui.free.fr/

Archive mirror at ftp://sources.redhat.com/pub/dm/multipath-tools/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

[ANNOUNCE] multipath-tools-0.4.4

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.4

This release seems sane enough to enter enterprise distros, thanks to
all reviewers for their hard work.

Worth noting :

	* 2 new path prioritizers : pp_alua and pp_emc
	* devmap_name can now filter by target_type (-t flag).
	  For example, no output if not "multipath" type.
	* the daemon sets /proc/self/oom_adj to -17, hence is 
	  protected from the oom killer. Watch out for leaks.
	* libdevmapper 1.01.01 or newer is now recquired
	* blacklist synthax is now regex based. Update your config
	  files. The packaged templates are up to date.
	* you can now set wwid in the blacklist
	* multipathd gained a "-v" flag to tune verbosity
	* daemon logging is now staged and asynchronous to avoid
	  syslogd possible hangs
	* droped local klibc, libsysfs and libdevmapper
	* multipath caches path info. Cache expire in 5sec.
	* "multipath -l" accepts a devname or dev_t filter


Full ChangeLog for the release :

        * [path_prio] clarify pp_alua licensing. Stefan Bader, IBM.
        * [devmap_name] add a target_type filter (suggested by Hannes)
          and set DM task device by major:minor rather than parsing
          the full map list.
        * [libmultipath] propagate an error on getprio callout
          failures, so that multipath can mark the map as immutable.
          Reported by Lars Marowsky-Bré, Suse.
        * [libmultipath] move push_callout() from dict.c to config.c
          Use it in store_hwe() to get in multipathd's ramfs the
          callout defined in hwtable.c when no config file is used.
          Reported by Lars Marowsky-Bré, Suse.
        * [checkers] zero sense buffers before use in EMC checker.
          Lars Marowsky-Bré, Suse.
        * [all] pre-release bugfixing effort from Alasdair, Hannes,
          Lars, Benjamin Marzinski
        * [multipathd] set oom_adj to -17 when kernel permits.
          Immune to OOM killer ? agk says : watch out for mem
          leaks :/
        * [multipathd] safety nets from udevd : exit early if
          not root, chdir to / to avoid pining a mount.
        * [multipathd] multipathd could loose events coming from
          sighup or DM waitev. Add a pending_event counter to
          track that.
        * [path_prio] add pp_emc from Lars M Bree, Suse.
        * [path_prio] add pp_alua from Stefan Bader, IBM.
        * [libmultipath] add config.c:load_config(), which sucks
          a big chunk of code out of multipath/main.c.
        * [libmultipath] don't allocate memory in :
                * devmapper.c:dm_get_map()
                * devmapper.c:dm_get_status()
        * [libmultipath] devinfo() a la carte fetching
        * [libmultipath] merge keepalived memory audit framework
          (Thanks again, M. Cassen). Already found and fixed a
          couple of leaks.
        * [libmultipath] flatten/optimize dm_map_present() and
          dm_mapname(). Inspired by Alasdair Kergon, RedHat.
        * [kpartx] dm_map_name() free before use bugfix. Kiyoshi
          Ueda, NEC
        * [kpartx] add hotplug mode. To enable name the binary
          "kpartx.dev". Kiyoshi Ueda, NEC
        * [multipathd] don't loose events in event waiter thread.
          Suggested and prototyped by Edward Goggin, EMC
        * [libmultipath] add return values to vector manipulation
          fonctions. Mem alloc return code audit.
        * [libmultipath] Use "config->udev_dir + path->dev" as
          a path devnode to open instead of mknod'ing for each
          one. Fix some DoS issues regarding usage of /tmp in
          libmultipath/discovery.c:opennode(). Kill unlinknode()
        * [multipathd] merged the redhat init script and stop
          installing one on "make install"
        * [libmultipath] fold safe_sprintf.h into util.h
        * [libmultipath] move blacklist to a real regex matcher
          Example config files updated : check yours !!
        * [multipath] fix path group compare logic to not stop
          comparing at first path in each PG.
        * [multipathd] check if pidfile is a dead remnent of a
          crashed daemon. If so, overwrite it. Suggested by
          Alasdair Kergon, RedHat. Code heavily based on work
          by Andrew Tridgell, Samba Fame.
        * [build] dropped libdevmapper/ and libsysfs/ from the
          package. klibc build is now broken until distributors
          provide klibc compiled static libraries in their
          respective packages.
        * [libmultipath] dm_task_no_open_count() before each DM
          ioctl. Not doing that is reported to cause deadlocks
          in kernel-space. Reported by Edward Goggin, EMC, fix
          suggested by Alasdair Kergon, RedHat
          Note minimal libdevmapper version bumped up to 1.01.
        * [multipath] switched to condlog(). "make DEBUG=N" is
          deprecated. Debug is spat with "-v3" or more.
        * [multipathd] "multipathd -vN" cmdline arg to control
          daemon verbosity. 0 < N < 4. "make LOGLEVEL=N" is
          deprecated.
        * [libmultipath] provide a common condlog() primitive to
          switch lib messages to syslog or stdout depending on
          who uses the lib (daemon or tool).
        * [kpartx] give kpartx a private, slim copy of devmap.[ch]
        * [multipath] allow wwid in blacklist{} config section.
          Kiyoshi Ueda, NEC.
        * [multipathd] set mode value before use (S_IRWXU). Fixes
          RedHat Bugzilla Bug 150665.
        * [all] add ->fd to "struct path *". remove fd from all
          checker context declaration. remove lots of duplicate
          logic. Now a fd is opened only once for path. It should
          also bring a bit safety in contended memory scenarii
        * [libcheckers] remove redundant sg_include.h
        * [libmultipath] merge multipath:dict.[ch] with
          multipathd:dict.[ch] into libmultipath/. move config.h
          there too, add some helper functions to alloc/free
          "struct config *" in a new config.c. Start using a
          config in the daemon.
        * [libmultipath] move dm_geteventnr(), dm_get_maps() and
          dm_switchgroup() in devmapper.[ch]
        * [libmultipath] move path discovery logic in
          libmultipath. merge devinfo.[ch] and sysfs_devinfo.[ch]
          into discovery.[ch]
        * [libmultipath] move config.h in libmultipath. Move
          find_[mp|hw]e in a new config.c. Move "struct hwtable"
          declaration in config.h. Move propsel.[ch] in the
          lib too.
        * [multipathd] use libmultipath:dm_type() instead of
          duplacate and bogus devmap discovery code.
        * [multipathd] asynchronous & non-blocking logger
          thread. Implementation split into a generic log
          lib and a pthread wrapper for locking and events.
          An ipc wrapper could be easily created by
          interested parties.
        * [multipath] add "multipath -l -v2 [devname|devt]"
          support in complement to [mapname|wwid]
        * [kpartx] suppress loop.h private copy. Should fix
          the reported build problems
        * [multipath] do sysfs_get_mnt_path() only one time
          and store in a global var.
        * [multipath] further path discovery optimzation
        * [multipath] purge superfluous includes in main.c
        * [libmultipath] introduce a cache file. expiry set
          to 5 secondes to covert the hotplug event storms.
        * [multipath] split get_pathvec_sysfs(). Introduce
          get_refwwid() and filter_pathvec()


As usual, doc and download at :
http://christophe.varoqui.free.fr/

Archive mirror at ftp://sources.redhat.com/pub/dm/multipath-tools/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] multipath-tools-0.4.4

[Lars Marowsky-Bree]

On 2005-04-25T00:26:58, christophe varoqui <christophe.varoqui@free.fr> wrote:

> 	* the daemon sets /proc/self/oom_adj to -17, hence is 
> 	  protected from the oom killer. Watch out for leaks.

I just cross-checked this. Quoting /usr/src/linux/fs/proc/base.c:
static ssize_t oom_adjust_write(struct file * file, const char * buf,
                                size_t count, loff_t *ppos)
{
        struct task_struct *task = proc_task(file->f_dentry->d_inode);
        char buffer[8], *end;
        int oom_adjust;

        if (!capable(CAP_SYS_RESOURCE))
                return -EPERM;
        memset(buffer, 0, 8);   
        if (count > 6)
                count = 6;
        if (copy_from_user(buffer, buf, count)) 
                return -EFAULT;
        oom_adjust = simple_strtol(buffer, &end, 0);
        if (oom_adjust < -16 || oom_adjust > 15)
                return -EINVAL;
        if (*end == '\n')
                end++;
        task->oomkilladj = oom_adjust;
        if (end - buffer == 0) 
                return -EIO;
        return end - buffer;
}

I doubt that set_oom_adj() has ever worked, unless your kernel is different
from mine in this regard... Checking the return value on fprintf()/fclose()
might have caught this earlier.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

iSCSI

[Harald Hoyer]

with the new iSCSI module I was able to do the block testcase over iSCSI
that means:

root filesystem on an encrypted LVM PV over ISCSI

I used:
"root=/dev/dracut/root rw 
iscsiroot=192.168.2.2::::iqn.2004-04.com.qnap:TS-439:iSCSI.test.8CCAFA ip=dhcp"

to create the encrypted LVM PV on a iscsi disk and boot from it.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iSCSI

[Harald Hoyer]

On 06/02/2009 01:25 PM, Harald Hoyer wrote:
> with the new iSCSI module I was able to do the block testcase over iSCSI
> that means:
>
> root filesystem on an encrypted LVM PV over ISCSI
>
> I used:
> "root=/dev/dracut/root rw
> iscsiroot=192.168.2.2::::iqn.2004-04.com.qnap:TS-439:iSCSI.test.8CCAFA
> ip=dhcp"
>
> to create the encrypted LVM PV on a iscsi disk and boot from it.
>

Oh, actually that was a LVM on an encrypted RAID-5 on a iSCSI disk..
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: iSCSI

[Ian Pratt]

> Is there a introducing comparison of the different network 
> blockdevice techniques like NBD/ENBD/GNBD, DRDB or iSCSI? You 
> seem to prefer iSCSI
> - why?

GNBD is definitely the best of the *NBD's. 

DRDB is good for network mirroring.

iSCSI is the preferred option if you have access to a hardware target,
otherwise you might use GNBD.
 
> Is network blockdevice sharing (that's meant with 
> "multipath", right?) necessary for "xm migrate"?

You don't require multipath for migration, e.g. if your rootfs is
available via GNBD or iSCSI. If you're trying to do something fancy with
network mirroring then DRDB works OK, but true in-kernel mutipath
support would probably be better.

> > BTW: gnbd works great, but I wish it used checksums over 
> and above the 
> > ip csum / ethernet crc32.
> 
> As the ethernet checksum is (afaik) over the hole frame it 
> should be ok as long as GNDB is done within a L2 segment, correct?

Depends how paranoid you are.
Having block-level CRCs makes me feel safer.

Ian

Re: iSCSI

[Mark Williamson]

> You don't require multipath for migration, e.g. if your rootfs is
> available via GNBD or iSCSI. If you're trying to do something fancy with
> network mirroring then DRDB works OK, but true in-kernel mutipath
> support would probably be better.

Didn't a patch for in kernel multipath get submitted recently?  I thought it 
was being merged fairly soon (i.e. I thought it was in Linus' tree).

> > As the ethernet checksum is (afaik) over the hole frame it
> > should be ok as long as GNDB is done within a L2 segment, correct?
>
> Depends how paranoid you are.
> Having block-level CRCs makes me feel safer.

It's not paranoia if they are out to get you ;-)

Cheers,
Mark

RE: iSCSI

[James Harper]

> 
> Anyone have pointers on an uptodate iscsi target?  Most I find are
old.
> 

I'm using the 'Enterprise Target'
(http://sourceforge.net/projects/iscsitarget) which is the only one I've
found that makes claims to greatness. The only other one I'm aware of is
the unh target but according to the docs that target was only created to
test the unh initiator against.

I've had no problems with it in terms of reliability, but haven't really
measured performance. I'm only using gigabit ethernet though.

James

RE: iSCSI

[Adam Heath]

On Mon, 11 Apr 2005, James Harper wrote:

> I'm using the 'Enterprise Target'
> (http://sourceforge.net/projects/iscsitarget) which is the only one I've
> found that makes claims to greatness. The only other one I'm aware of is
> the unh target but according to the docs that target was only created to
> test the unh initiator against.

Hmm, yeah, that seems easy to get going.  I'll make a debian package.

RE: iSCSI

[James Harper]

> 
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/

I'd never even heard of it, and I've looked hard for iscsi initiators...
my search skills obviously aren't what they used to be!!!

> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

I'm using the cisco stack too, remote boot is a PITA but otherwise it
runs well, and I can even do a reboot of the target (iet) and
linux-iscsi picks up the pieces quite nicely.

The unh initiator remote boots very nicely but I couldn't make it play
with iet, and it didn't cope with the target going down and coming back
up again.

I'll download and build the open-iscsi initiator now!

James

iSCSI

[Ian Pratt]

Has anyone got any experience using the new 'open-iscsi' initiator?
(either on Xen or native) http://www.open-iscsi.org/

We've been using the cisco iscsi stack
http://linux-iscsi.sourceforge.net/ for some time, but the performance
isn't great. open-iscsi claims good performance, so it might be worth
switching over.

BTW: gnbd works great, but I wish it used checksums over and above the
ip csum / ethernet crc32. 

Cheers,
Ian

Re: iSCSI

[Mike Christie]

Ian Pratt wrote:
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.
>


You will need to switch sooner or later since the cisco driver as you
know it is about to die.

What help is needed in this area?

> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32. 
> 
> Cheers,
> Ian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: iSCSI

[Adam Heath]

On Sun, 10 Apr 2005, Mike Christie wrote:

> Ian Pratt wrote:
> > Has anyone got any experience using the new 'open-iscsi' initiator?
> > (either on Xen or native) http://www.open-iscsi.org/
> >
> > We've been using the cisco iscsi stack
> > http://linux-iscsi.sourceforge.net/ for some time, but the performance
> > isn't great. open-iscsi claims good performance, so it might be worth
> > switching over.
> >
>
>
> You will need to switch sooner or later since the cisco driver as you
> know it is about to die.

Odd, seeing as how it's now part of 2.6.11.

(yes, I know you are listed at the author)

Re: iSCSI

[Mike Christie]

Adam Heath wrote:
> On Sun, 10 Apr 2005, Mike Christie wrote:
> 
> 
>>Ian Pratt wrote:
>>
>>>Has anyone got any experience using the new 'open-iscsi' initiator?
>>>(either on Xen or native) http://www.open-iscsi.org/
>>>
>>>We've been using the cisco iscsi stack
>>>http://linux-iscsi.sourceforge.net/ for some time, but the performance
>>>isn't great. open-iscsi claims good performance, so it might be worth
>>>switching over.
>>>
>>
>>
>>You will need to switch sooner or later since the cisco driver as you
>>know it is about to die.
> 
> 
> Odd, seeing as how it's now part of 2.6.11.
> 

The cisco driver should not be in there. What filename?
The iSCSI transport class is in 2.6.11. That is just common
code though.

open-iscsi is in some -mm versions.


> (yes, I know you are listed at the author)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: iSCSI

[Kip Macy]

I've looked at it, but had some issues building it. If the cisco
initiator is going away I'll definitely give it a spin this week.

                            -Kip

On Apr 10, 2005 12:04 PM, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.
> 
> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32.
> 
> Cheers,
> Ian
>

Re: iSCSI

[Adam Heath]

On Sun, 10 Apr 2005, Ian Pratt wrote:

>
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
>
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

Anyone have pointers on an uptodate iscsi target?  Most I find are old.

Re: iSCSI

[Jacob Gorm Hansen]

Adam Heath wrote:
> 
> Anyone have pointers on an uptodate iscsi target?  Most I find are old.

How about: http://iscsitarget.sourceforge.net/

It's been about six months since I used it last, but back then it worked 
really well.

Best regards,
Jacob

Re: iSCSI

[Nils Toedtmann]

Am Sonntag, den 10.04.2005, 20:04 +0100 schrieb Ian Pratt:
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

Is there a introducing comparison of the different network blockdevice
techniques like NBD/ENBD/GNBD, DRDB or iSCSI? You seem to prefer iSCSI 
- why?

Is network blockdevice sharing (that's meant with "multipath", right?)
necessary for "xm migrate"?


> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32. 

As the ethernet checksum is (afaik) over the hole frame it should be ok
as long as GNDB is done within a L2 segment, correct?

/nils.

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[James.Smart]

I know that the driver in the kernel.org tree supports the fc_transport, at least the part relative to the discussion below (I made the mods).  I can't speak for their other driver sets.

-- james

> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com]On
> Behalf Of Caushik, Ramesh
> Sent: Wednesday, December 22, 2004 4:55 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org;
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> 
> The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 
> and later do not support the fc_transport class. The support 
> is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to 
> wait till they support this for newer kernels. Meanwhile I 
> can work with a patched version of multipath tools. Thanks 
> for feedback. 
> 
> Ramesh.   
> 
> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
> Sent: Wednesday, December 22, 2004 3:31 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org; 
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> James, thank you for the clarification (and I didn't mean to string
> anyone :).
> 
> Ramesh, I don't feel like going through the hassle of supporting
> multiple synthax until the multipath target has made its way into the
> standard kernel, so I'll keep guessing the node_name in
> behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
> the node_name fetch.
> 
> ok with you ?
> 
> regards,
> cvaroqui
> 
> Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
> écrit :
> > Qlogic shouldn't be strung out. It wasn't them....
> > 
> > As part of a change that went into the FC transport - the 
> device reported under this directory was moved from the LUN 
> device to the Target device - thus the change in name format 
> (it killed replication of target data that was being done for 
> all luns). The attributes underneath remain the same. I 
> believe this change occurred in the first rc1 patch to 2.6.9.
> > 
> > As to the grand plan - you should be fine if you :
> >  pre-2.6.10: it's the older name format 
> "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
> >  2.6.10 and later : it's the new format 
> "/sys/class/fc_transport/target<host>:<channel>:<target>"
> > 
> >  and the folks running a patched 2.6.9 have to live by the 
> new format.
> > 
> > --
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[James.Smart]

I know that the driver in the kernel.org tree supports the fc_transport, at least the part relative to the discussion below (I made the mods).  I can't speak for their other driver sets.

-- james

> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com]On
> Behalf Of Caushik, Ramesh
> Sent: Wednesday, December 22, 2004 4:55 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org;
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> 
> The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 
> and later do not support the fc_transport class. The support 
> is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to 
> wait till they support this for newer kernels. Meanwhile I 
> can work with a patched version of multipath tools. Thanks 
> for feedback. 
> 
> Ramesh.   
> 
> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
> Sent: Wednesday, December 22, 2004 3:31 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org; 
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> James, thank you for the clarification (and I didn't mean to string
> anyone :).
> 
> Ramesh, I don't feel like going through the hassle of supporting
> multiple synthax until the multipath target has made its way into the
> standard kernel, so I'll keep guessing the node_name in
> behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
> the node_name fetch.
> 
> ok with you ?
> 
> regards,
> cvaroqui
> 
> Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
> écrit :
> > Qlogic shouldn't be strung out. It wasn't them....
> > 
> > As part of a change that went into the FC transport - the 
> device reported under this directory was moved from the LUN 
> device to the Target device - thus the change in name format 
> (it killed replication of target data that was being done for 
> all luns). The attributes underneath remain the same. I 
> believe this change occurred in the first rc1 patch to 2.6.9.
> > 
> > As to the grand plan - you should be fine if you :
> >  pre-2.6.10: it's the older name format 
> "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
> >  2.6.10 and later : it's the new format 
> "/sys/class/fc_transport/target<host>:<channel>:<target>"
> > 
> >  and the folks running a patched 2.6.9 have to live by the 
> new format.
> > 
> > --
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 and later do not support the fc_transport class. The support is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to wait till they support this for newer kernels. Meanwhile I can work with a patched version of multipath tools. Thanks for feedback. 

Ramesh.   

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
Sent: Wednesday, December 22, 2004 3:31 PM
To: device-mapper development
Cc: linux-raid@vger.kernel.org; linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

James, thank you for the clarification (and I didn't mean to string
anyone :).

Ramesh, I don't feel like going through the hassle of supporting
multiple synthax until the multipath target has made its way into the
standard kernel, so I'll keep guessing the node_name in
behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
the node_name fetch.

ok with you ?

regards,
cvaroqui

Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
écrit :
> Qlogic shouldn't be strung out. It wasn't them....
> 
> As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.
> 
> As to the grand plan - you should be fine if you :
>  pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
>  2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"
> 
>  and the folks running a patched 2.6.9 have to live by the new format.
> 
> --


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 and later do not support the fc_transport class. The support is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to wait till they support this for newer kernels. Meanwhile I can work with a patched version of multipath tools. Thanks for feedback. 

Ramesh.   

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
Sent: Wednesday, December 22, 2004 3:31 PM
To: device-mapper development
Cc: linux-raid@vger.kernel.org; linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

James, thank you for the clarification (and I didn't mean to string
anyone :).

Ramesh, I don't feel like going through the hassle of supporting
multiple synthax until the multipath target has made its way into the
standard kernel, so I'll keep guessing the node_name in
behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
the node_name fetch.

ok with you ?

regards,
cvaroqui

Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
écrit :
> Qlogic shouldn't be strung out. It wasn't them....
> 
> As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.
> 
> As to the grand plan - you should be fine if you :
>  pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
>  2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"
> 
>  and the folks running a patched 2.6.9 have to live by the new format.
> 
> --


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Christoph Hellwig]

On Wed, Dec 22, 2004 at 01:54:45PM -0800, Caushik, Ramesh wrote:
> The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 and later do not support the fc_transport class. The support is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to wait till they support this for newer kernels. Meanwhile I can work with a patched version of multipath tools. Thanks for feedback. 

It's supported in the mainline driver.  The qlogic drivers do lots of silly
things and you shouldn't use them.

Re: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Christoph Hellwig]

On Wed, Dec 22, 2004 at 01:54:45PM -0800, Caushik, Ramesh wrote:
> The newer Qlogic (qla2xxx) driver for kernel versions 2.6.9 and later do not support the fc_transport class. The support is #ifdefed for kernels > 2.6.6 & < 2.6.9. So I will have to wait till they support this for newer kernels. Meanwhile I can work with a patched version of multipath tools. Thanks for feedback. 

It's supported in the mainline driver.  The qlogic drivers do lots of silly
things and you shouldn't use them.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[James.Smart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3064 bytes --]

Qlogic shouldn't be strung out. It wasn't them....

As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.

As to the grand plan - you should be fine if you :
 pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
 2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"

 and the folks running a patched 2.6.9 have to live by the new format.

-- James S.

> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com]On
> Behalf Of christophe varoqui
> Sent: Wednesday, December 22, 2004 4:53 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org;
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> 
> Le mercredi 22 d?embre 2004 à 11:26 -0800, Caushik, Ramesh a écrit :
> > On my system I have a Qlogic 2310 driver running on a 2.6.9 
> kernel. The fc_transport 
> > directory in sysfs looks like 
> > 
> > ls -ll /sys/class/fc_transport/
> > total 0
> > drwxr-xr-x   6 root root 0 Dec 16 13:59 .
> > drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  
> > 
> > The patch addresses only this format. So please disregard 
> the patch, and sorry about the confusion.
> > 
> ...
> > [root@cl039 multipath]# ll /sys/class/fc_transport/
> > total 0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3
> > 
> Can someone, maybe from Qlogic, comment on these differences ?
> Is there a grant unified plan for driver objects 
> representation through
> sysfs, and if so which is the right path name to fetch the node_name.
> 
> regards,
> -- 
> christophe varoqui <christophe.varoqui@free.fr>
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 
HW¦j)b²ÊhžÊ+yÖòN\x17ˆLúèvç-\x1aèy\x17šv\x1a'zË\jwbv·¯‰ì,¢xnÚÞvÊ\x1f!3ë¡Ûœ¶Çë¢jÞj[¬z»\x03ŠÇ(½êð†'!¦º\x1d¹Ël¶»¥ÊX¯zêm¢Ø^‡*^JÖ«¶·šv)àžŒ!¶Ú\x7fþšèvç-‚èz+fjv z»#¢êçjW(›

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[James.Smart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3207 bytes --]

Qlogic shouldn't be strung out. It wasn't them....

As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.

As to the grand plan - you should be fine if you :
 pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
 2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"

 and the folks running a patched 2.6.9 have to live by the new format.

-- James S.

> -----Original Message-----
> From: dm-devel-bounces@redhat.com 
> [mailto:dm-devel-bounces@redhat.com]On
> Behalf Of christophe varoqui
> Sent: Wednesday, December 22, 2004 4:53 PM
> To: device-mapper development
> Cc: linux-raid@vger.kernel.org;
> linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
> Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1
> 
> 
> Le mercredi 22 d?embre 2004 à 11:26 -0800, Caushik, Ramesh a écrit :
> > On my system I have a Qlogic 2310 driver running on a 2.6.9 
> kernel. The fc_transport 
> > directory in sysfs looks like 
> > 
> > ls -ll /sys/class/fc_transport/
> > total 0
> > drwxr-xr-x   6 root root 0 Dec 16 13:59 .
> > drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
> > drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  
> > 
> > The patch addresses only this format. So please disregard 
> the patch, and sorry about the confusion.
> > 
> ...
> > [root@cl039 multipath]# ll /sys/class/fc_transport/
> > total 0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
> > drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
> > drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3
> > 
> Can someone, maybe from Qlogic, comment on these differences ?
> Is there a grant unified plan for driver objects 
> representation through
> sysfs, and if so which is the right path name to fetch the node_name.
> 
> regards,
> -- 
> christophe varoqui <christophe.varoqui@free.fr>
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> 
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ\x15隊X¬²š'²ŠÞu¼ÿN\x17ˆLúèvç-\x1aèy\x17šv\x1a'zËÿq©Ý‰ÚÞ¾'°²‰áºwkyÛ(|„Ï®‡nrÛ\x1f®‰«y©n±êìü8¬r‹Þ¯\bbr\x1ak¡Ûœ¶Ëkº\¥Š÷®¦Ú-…èr¥ïÒµªí­æŠx'£\x0fá¶Úÿÿúk¡Ûœ¶\v¢uïâ¶f§j\a«²:.®v¥ýÊ&ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.)îÇøh¶™nƒ÷^½éfj)bž	b²Øm¶ŸÿþX§»\x1fá¢Úeº\x0fì¢êÜyú+ïçzÒâžìÿ†‹i–èÿuëÞ—ùb²Ûÿ²‹«qçè®\aÿëa¶ÚlÿÿåŠËlþÊ.­ÇŸ¢¸\x1eþw­þX¬¶ÏåŠËbú?–)îÇøh¶™nƒ÷^

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

James, thank you for the clarification (and I didn't mean to string
anyone :).

Ramesh, I don't feel like going through the hassle of supporting
multiple synthax until the multipath target has made its way into the
standard kernel, so I'll keep guessing the node_name in
behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
the node_name fetch.

ok with you ?

regards,
cvaroqui

Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
écrit :
> Qlogic shouldn't be strung out. It wasn't them....
> 
> As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.
> 
> As to the grand plan - you should be fine if you :
>  pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
>  2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"
> 
>  and the folks running a patched 2.6.9 have to live by the new format.
> 
> --




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

James, thank you for the clarification (and I didn't mean to string
anyone :).

Ramesh, I don't feel like going through the hassle of supporting
multiple synthax until the multipath target has made its way into the
standard kernel, so I'll keep guessing the node_name in
behing /sys/class/fc_transport/target<host>:<channel>:<target> or skip
the node_name fetch.

ok with you ?

regards,
cvaroqui

Le mercredi 22 d?embre 2004 à 16:05 -0500, James.Smart@Emulex.Com a
écrit :
> Qlogic shouldn't be strung out. It wasn't them....
> 
> As part of a change that went into the FC transport - the device reported under this directory was moved from the LUN device to the Target device - thus the change in name format (it killed replication of target data that was being done for all luns). The attributes underneath remain the same. I believe this change occurred in the first rc1 patch to 2.6.9.
> 
> As to the grand plan - you should be fine if you :
>  pre-2.6.10: it's the older name format "/sys/class/fc_transport/<host>:<channel>:<target>:<lun>"
>  2.6.10 and later : it's the new format "/sys/class/fc_transport/target<host>:<channel>:<target>"
> 
>  and the folks running a patched 2.6.9 have to live by the new format.
> 
> --


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

On my system I have a Qlogic 2310 driver running on a 2.6.9 kernel. The fc_transport 
directory in sysfs looks like 

ls -ll /sys/class/fc_transport/
total 0
drwxr-xr-x   6 root root 0 Dec 16 13:59 .
drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  

The patch addresses only this format. So please disregard the patch, and sorry about the confusion.

Ramesh.



-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
Sent: Tuesday, December 21, 2004 5:26 PM
To: device-mapper development
Cc: linux-raid@vger.kernel.org; linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

Le mercredi 22 d?embre 2004 à 02:09 +0100, christophe varoqui a écrit :
> Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> > The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> > in the code to get the node_name attr in the fc_transport sysfs entry.
> > Path below should fix it. BTW why does a failure to get a node_name
> > attribute, result in failure of multipath discovery (because devinfo
> > returns failure)even if the "group_by_node_name" policy is not used ?
> > Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> > routine and fail the group_by_node_name routine if that policy was
> > chosen ? That is what happened in my case. Multipath discovery failed
> > due to above reason even though node_name grouping was not specified. 
> > 
> You are absolutely right.
> 
> I was aware that introducing that FC-ism would break for iSCSI and other
> transports. I just thought I'll get that right in a next release because
> I wasn't aware someone was using the thing in such an "exotic"
> environment.
> 
> I would gladly get a description of your topology, by the way.
> It would help to get it right in the future.
> 
> Anyway, I'll fix that for 0.4.2
> 
That response was for the premature exit when the FC-ism is out of
place.

Concerning the patch itself, I don't see the problem it adresses :

[root@cl039 multipath]# ll /sys/class/fc_transport/
total 0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3

[root@cl039 multipath]# ll /sys/class/fc_transport/target2\:0\:0
total 0
lrwxrwxrwx    1 root     root            0 Dec 14 16:26 device
-> ../../../devices/pci0000:00/0000:00:09.0/0000:03:04.0/host2/target2:0:0
-r--r--r--    1 root     root         4096 Dec 14 16:26 node_name
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_id
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_name

This is with Qlogic hardware, but I'm not aware of HBA driver specifics
in the area. If there is, I'm all for resolving the delta at the device
driver level.

> regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

On my system I have a Qlogic 2310 driver running on a 2.6.9 kernel. The fc_transport 
directory in sysfs looks like 

ls -ll /sys/class/fc_transport/
total 0
drwxr-xr-x   6 root root 0 Dec 16 13:59 .
drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  

The patch addresses only this format. So please disregard the patch, and sorry about the confusion.

Ramesh.



-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of christophe varoqui
Sent: Tuesday, December 21, 2004 5:26 PM
To: device-mapper development
Cc: linux-raid@vger.kernel.org; linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

Le mercredi 22 d?embre 2004 à 02:09 +0100, christophe varoqui a écrit :
> Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> > The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> > in the code to get the node_name attr in the fc_transport sysfs entry.
> > Path below should fix it. BTW why does a failure to get a node_name
> > attribute, result in failure of multipath discovery (because devinfo
> > returns failure)even if the "group_by_node_name" policy is not used ?
> > Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> > routine and fail the group_by_node_name routine if that policy was
> > chosen ? That is what happened in my case. Multipath discovery failed
> > due to above reason even though node_name grouping was not specified. 
> > 
> You are absolutely right.
> 
> I was aware that introducing that FC-ism would break for iSCSI and other
> transports. I just thought I'll get that right in a next release because
> I wasn't aware someone was using the thing in such an "exotic"
> environment.
> 
> I would gladly get a description of your topology, by the way.
> It would help to get it right in the future.
> 
> Anyway, I'll fix that for 0.4.2
> 
That response was for the premature exit when the FC-ism is out of
place.

Concerning the patch itself, I don't see the problem it adresses :

[root@cl039 multipath]# ll /sys/class/fc_transport/
total 0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3

[root@cl039 multipath]# ll /sys/class/fc_transport/target2\:0\:0
total 0
lrwxrwxrwx    1 root     root            0 Dec 14 16:26 device
-> ../../../devices/pci0000:00/0000:00:09.0/0000:03:04.0/host2/target2:0:0
-r--r--r--    1 root     root         4096 Dec 14 16:26 node_name
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_id
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_name

This is with Qlogic hardware, but I'm not aware of HBA driver specifics
in the area. If there is, I'm all for resolving the delta at the device
driver level.

> regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mercredi 22 d?embre 2004 à 11:26 -0800, Caushik, Ramesh a écrit :
> On my system I have a Qlogic 2310 driver running on a 2.6.9 kernel. The fc_transport 
> directory in sysfs looks like 
> 
> ls -ll /sys/class/fc_transport/
> total 0
> drwxr-xr-x   6 root root 0 Dec 16 13:59 .
> drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  
> 
> The patch addresses only this format. So please disregard the patch, and sorry about the confusion.
> 
...
> [root@cl039 multipath]# ll /sys/class/fc_transport/
> total 0
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3
> 
Can someone, maybe from Qlogic, comment on these differences ?
Is there a grant unified plan for driver objects representation through
sysfs, and if so which is the right path name to fetch the node_name.

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mercredi 22 d?embre 2004 à 11:26 -0800, Caushik, Ramesh a écrit :
> On my system I have a Qlogic 2310 driver running on a 2.6.9 kernel. The fc_transport 
> directory in sysfs looks like 
> 
> ls -ll /sys/class/fc_transport/
> total 0
> drwxr-xr-x   6 root root 0 Dec 16 13:59 .
> drwxr-xr-x  20 root root 0 Dec 15 14:31 ..
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:0:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:1:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:2:0
> drwxr-xr-x   2 root root 0 Dec 16 13:59 2:0:3:0  
> 
> The patch addresses only this format. So please disregard the patch, and sorry about the confusion.
> 
...
> [root@cl039 multipath]# ll /sys/class/fc_transport/
> total 0
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
> drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
> drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3
> 
Can someone, maybe from Qlogic, comment on these differences ?
Is there a grant unified plan for driver objects representation through
sysfs, and if so which is the right path name to fetch the node_name.

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
in the code to get the node_name attr in the fc_transport sysfs entry.
Path below should fix it. BTW why does a failure to get a node_name
attribute, result in failure of multipath discovery (because devinfo
returns failure)even if the "group_by_node_name" policy is not used ?
Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
routine and fail the group_by_node_name routine if that policy was
chosen ? That is what happened in my case. Multipath discovery failed
due to above reason even though node_name grouping was not specified. 

***************

diff new_multipath/devinfo.c old_multipath/devinfo.c
349c349
<
"%s/class/fc_transport/target%i:%i:%i/node_name",
---
> 			"%s/class/fc_transport/%i:%i:%i:%i/node_name",
353c353,354
< 			curpath->sg_id.scsi_id)) {
---
> 			curpath->sg_id.scsi_id,
> 			curpath->sg_id.lun)) {

***********

Ramesh.    

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of christophe varoqui
Sent: Monday, December 20, 2004 8:01 AM
To: device-mapper development
Cc: linux-raid@vger.kernel.org;
linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

Hello,

here goes multipath-tools-0.4.1

Another round of bugfixes.
People are starting to report sane behaviour.

If someone at IBM (or knowledgeable enough) is listening, we need a
method to check a path status on a T200 that don't trigger a controler
bounce. Is it possible at all ?

Full ChangeLog for the release :

        * [multipath] bump SERIAL_SIZE to 19
        * [multipath] add a new group_by_node_name pgpolicy
        * [multipath] move getopt policy parser to
          get_policy_id()
        * [multipath] remove get_evpd_wwid()
        * [checkers] fix the wwn_set test in emc checker
          (Hergen Lange)
        * [checkers] treat the emc checker in the name to
          index translator function (Hergen Lange)
        * [multipath] print to stderr DM unmet requirement
          (Guido Guenther)
        * [multipath] fix realloc return value store not
          propagated to caller by merge_word() (Nicola Ranaldo)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[Caushik, Ramesh]

The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
in the code to get the node_name attr in the fc_transport sysfs entry.
Path below should fix it. BTW why does a failure to get a node_name
attribute, result in failure of multipath discovery (because devinfo
returns failure)even if the "group_by_node_name" policy is not used ?
Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
routine and fail the group_by_node_name routine if that policy was
chosen ? That is what happened in my case. Multipath discovery failed
due to above reason even though node_name grouping was not specified. 

***************

diff new_multipath/devinfo.c old_multipath/devinfo.c
349c349
<
"%s/class/fc_transport/target%i:%i:%i/node_name",
---
> 			"%s/class/fc_transport/%i:%i:%i:%i/node_name",
353c353,354
< 			curpath->sg_id.scsi_id)) {
---
> 			curpath->sg_id.scsi_id,
> 			curpath->sg_id.lun)) {

***********

Ramesh.    

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of christophe varoqui
Sent: Monday, December 20, 2004 8:01 AM
To: device-mapper development
Cc: linux-raid@vger.kernel.org;
linux-hotplug-devel@lists.sourceforge.net; linux-scsi@vger.kernel.org
Subject: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

Hello,

here goes multipath-tools-0.4.1

Another round of bugfixes.
People are starting to report sane behaviour.

If someone at IBM (or knowledgeable enough) is listening, we need a
method to check a path status on a T200 that don't trigger a controler
bounce. Is it possible at all ?

Full ChangeLog for the release :

        * [multipath] bump SERIAL_SIZE to 19
        * [multipath] add a new group_by_node_name pgpolicy
        * [multipath] move getopt policy parser to
          get_policy_id()
        * [multipath] remove get_evpd_wwid()
        * [checkers] fix the wwn_set test in emc checker
          (Hergen Lange)
        * [checkers] treat the emc checker in the name to
          index translator function (Hergen Lange)
        * [multipath] print to stderr DM unmet requirement
          (Guido Guenther)
        * [multipath] fix realloc return value store not
          propagated to caller by merge_word() (Nicola Ranaldo)

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> in the code to get the node_name attr in the fc_transport sysfs entry.
> Path below should fix it. BTW why does a failure to get a node_name
> attribute, result in failure of multipath discovery (because devinfo
> returns failure)even if the "group_by_node_name" policy is not used ?
> Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> routine and fail the group_by_node_name routine if that policy was
> chosen ? That is what happened in my case. Multipath discovery failed
> due to above reason even though node_name grouping was not specified. 
> 
You are absolutely right.

I was aware that introducing that FC-ism would break for iSCSI and other
transports. I just thought I'll get that right in a next release because
I wasn't aware someone was using the thing in such an "exotic"
environment.

I would gladly get a description of your topology, by the way.
It would help to get it right in the future.

Anyway, I'll fix that for 0.4.2

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> in the code to get the node_name attr in the fc_transport sysfs entry.
> Path below should fix it. BTW why does a failure to get a node_name
> attribute, result in failure of multipath discovery (because devinfo
> returns failure)even if the "group_by_node_name" policy is not used ?
> Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> routine and fail the group_by_node_name routine if that policy was
> chosen ? That is what happened in my case. Multipath discovery failed
> due to above reason even though node_name grouping was not specified. 
> 
You are absolutely right.

I was aware that introducing that FC-ism would break for iSCSI and other
transports. I just thought I'll get that right in a next release because
I wasn't aware someone was using the thing in such an "exotic"
environment.

I would gladly get a description of your topology, by the way.
It would help to get it right in the future.

Anyway, I'll fix that for 0.4.2

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mercredi 22 d?embre 2004 à 02:09 +0100, christophe varoqui a écrit :
> Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> > The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> > in the code to get the node_name attr in the fc_transport sysfs entry.
> > Path below should fix it. BTW why does a failure to get a node_name
> > attribute, result in failure of multipath discovery (because devinfo
> > returns failure)even if the "group_by_node_name" policy is not used ?
> > Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> > routine and fail the group_by_node_name routine if that policy was
> > chosen ? That is what happened in my case. Multipath discovery failed
> > due to above reason even though node_name grouping was not specified. 
> > 
> You are absolutely right.
> 
> I was aware that introducing that FC-ism would break for iSCSI and other
> transports. I just thought I'll get that right in a next release because
> I wasn't aware someone was using the thing in such an "exotic"
> environment.
> 
> I would gladly get a description of your topology, by the way.
> It would help to get it right in the future.
> 
> Anyway, I'll fix that for 0.4.2
> 
That response was for the premature exit when the FC-ism is out of
place.

Concerning the patch itself, I don't see the problem it adresses :

[root@cl039 multipath]# ll /sys/class/fc_transport/
total 0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3

[root@cl039 multipath]# ll /sys/class/fc_transport/target2\:0\:0
total 0
lrwxrwxrwx    1 root     root            0 Dec 14 16:26 device
-> ../../../devices/pci0000:00/0000:00:09.0/0000:03:04.0/host2/target2:0:0
-r--r--r--    1 root     root         4096 Dec 14 16:26 node_name
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_id
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_name

This is with Qlogic hardware, but I'm not aware of HBA driver specifics
in the area. If there is, I'm all for resolving the delta at the device
driver level.

> regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: [dm-devel] [ANNOUNCE] multipath-tools-0.4.1

[christophe varoqui]

Le mercredi 22 d?embre 2004 à 02:09 +0100, christophe varoqui a écrit :
> Le mardi 21 d?embre 2004 à 14:02 -0800, Caushik, Ramesh a écrit :
> > The devinfo.c file in the multipath-tools-0.4.1 appears to have a typo
> > in the code to get the node_name attr in the fc_transport sysfs entry.
> > Path below should fix it. BTW why does a failure to get a node_name
> > attribute, result in failure of multipath discovery (because devinfo
> > returns failure)even if the "group_by_node_name" policy is not used ?
> > Can't we just NULL out the tgt_node_name string in the sysfs_devinfo
> > routine and fail the group_by_node_name routine if that policy was
> > chosen ? That is what happened in my case. Multipath discovery failed
> > due to above reason even though node_name grouping was not specified. 
> > 
> You are absolutely right.
> 
> I was aware that introducing that FC-ism would break for iSCSI and other
> transports. I just thought I'll get that right in a next release because
> I wasn't aware someone was using the thing in such an "exotic"
> environment.
> 
> I would gladly get a description of your topology, by the way.
> It would help to get it right in the future.
> 
> Anyway, I'll fix that for 0.4.2
> 
That response was for the premature exit when the FC-ism is out of
place.

Concerning the patch itself, I don't see the problem it adresses :

[root@cl039 multipath]# ll /sys/class/fc_transport/
total 0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:26 target2:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target2:0:3
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:0
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:1
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:2
drwxr-xr-x    2 root     root            0 Dec 14 16:27 target3:0:3

[root@cl039 multipath]# ll /sys/class/fc_transport/target2\:0\:0
total 0
lrwxrwxrwx    1 root     root            0 Dec 14 16:26 device
-> ../../../devices/pci0000:00/0000:00:09.0/0000:03:04.0/host2/target2:0:0
-r--r--r--    1 root     root         4096 Dec 14 16:26 node_name
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_id
-r--r--r--    1 root     root         4096 Dec 14 16:26 port_name

This is with Qlogic hardware, but I'm not aware of HBA driver specifics
in the area. If there is, I'm all for resolving the delta at the device
driver level.

> regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iscsi

[Jan van Rensburg]

Hi Ian,

What kind of timeframes are we talking, more or less, to get the ring-1 
I/O model stable? In what branch of Xen does this development happen, 
1.3?

Thanks,
Jan

On 22 Jan 2004, at 6:04 AM, xen-devel-request@lists.sourceforge.net 
wrote:

> Fortunately, this kind of thing is going to be quite a bit easier
> under the ring-1 I/O model. I think the performance will be
> pretty good -- we'll never copy data, and attempt to minimize the
> number of protection domain switches through pipelining.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: iscsi

[Ian Pratt]

> What kind of timeframes are we talking, more or less, to get the ring-1 
> I/O model stable? In what branch of Xen does this development happen, 
> 1.3?

The work is just starting, and will occur in the 1.3 unstable
branch. I don't think it will take too long (4-8 weeks) to get
equivalent functionality to 1.2, but bells and whistles will take
longer...

Ian 




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: iscsi

[Rolf Neugebauer]

On Tue, 2004-01-20 at 19:34, Kip Macy wrote:
> > I've just added the SCSI menu option from arch/i386/config.in
> > (see attached), and built a xenolinux with SCSI and SCSI disk
> > support compiled in. I'm not sure how you enable iSCSI support
> > (of indeed if the standard kernel even has iSCSI support).
> 
> Great - thanks. There is no stock support of iSCSI in Linux.
> The Redhat and Suse distributions both have one. I've always used
> the one from Cisco on sourceforge. The question is what do you do
> for a target? I believe that one has been written for Linux, but
> have never used it. I've written one for FreeBSD that could be easily
> ported to Linux. If the company that I've done it for doesn't pay me
> for the last bit of work I've done, I'd probably rather open-source
> it than take the time and energy to pursue the more common alternative.

it was pointed out to me yesterday that the Intel iSCSI code for Linux
(http://sourceforge.net/projects/intel-iscsi/) has a target driver. a
quick glance through the readme suggests that the the target can be
either a ram disk or a raw disk device (in which case the target driver
runs in userland), I have never used this software so can't comment on
completeness nor performance.

> >
> > Exporting disks to domains via iSCSI would be cool. There's
> > always the alternative of the much simpler 'enbd', but iSCSI
> > sounds nicer. I wander if there's support for iSCSI root devices?
> > (if not, it's possible something could be bodged with an initrd
> > initial ramdisk).
> 
> iSCSI is the more general of the two. DataOnTap now supports exporting
> LUNs over FCP and iSCSI. One can create a LUN as "golden image" and
> clone it arbitrarily many times. Thanks to the COW nature of WAFL the
> only additional space required by the cloned LUNs is for modifications.

to clarify, you are talking about netapp solutions here not generic
iSCSI features, right? as i understand it you can configure block-level
networked access to virtual disks on a netapp filer via iSCSI, and the
filer can be configured to do COW for these virtual disks.

if this is correct why don't you not just configure each domain to talk
iSCSI to the filer directly via their virtual network interfaces instead
of exporting the virtual disks (LUNs) through VBDs from dom0 as your
initial email seem to indicate? or is the root partition problem the
issue?

Cheers
Rolf

> The only way for an iSCSI root to work out of the box is to have an
> initiator with a BIOS, none that I know of currently do. One could
> play clever tricks by initially having a ramdisk and then switching.
> 
> My intention is to have domain 0 boot from local disk, but have all of
> the non-privileged domains boot off of iscsi backed VBDs.
> 
> 			-Kip
> 
> 
> >
> >
> > xenolinux-2.4.24-sparse/arch/xeno/config.in: 1.12 1.13 iap10 04/01/20
> 18:24:17 (modified, needs delta)
> >
> > @@ -108,6 +108,17 @@
> >
> >  endmenu
> >
> > +mainmenu_option next_comment
> > +comment 'SCSI support'
> > +
> > +tristate 'SCSI support' CONFIG_SCSI
> > +
> > +if [ "$CONFIG_SCSI" != "n" ]; then
> > +   source drivers/scsi/Config.in
> > +fi
> > +endmenu
> > +
> > +
> >  if [ "$CONFIG_NET" = "y" ]; then
> >     source net/Config.in
> >  fi
> >
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: iscsi

[Kip Macy]

>
> to clarify, you are talking about netapp solutions here not generic
> iSCSI features, right? as i understand it you can configure block-level
> networked access to virtual disks on a netapp filer via iSCSI, and the
> filer can be configured to do COW for these virtual disks.

Correct.

>
> if this is correct why don't you not just configure each domain to talk
> iSCSI to the filer directly via their virtual network interfaces instead
> of exporting the virtual disks (LUNs) through VBDs from dom0 as your
> initial email seem to indicate? or is the root partition problem the
> issue?
>

For the first pass where I'm only running Linux that will, at least in
principle, work. There are a couple of issues that make that approach
more work. From a configuration standpoint I want the virtual machines
that act as sandboxes for developers to look like a normal machine.
This entails the iSCSI backing looking like a normal disk for all
intents and purposes. Second, I want to be able to map a developer to a
LUN and then build a domain backed by that on an arbitrary physical
machine. This would have the additional benefit of fully anonymizing the
hardware.

In the near future I want to be able to run other operating systems that
do not have iscsi initiator support, nor ever will, in virtual machines.
For this NFS/RAMDISK root is not an option. Thus I need to take the LUN
mapping approach. I'll just have to hope that I can pull the Adaptec
iSCSI HW initator driver into Xen, and that all the configuration tools
will work.


			-Kip


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: iscsi

[Ian Pratt]

> In the near future I want to be able to run other operating systems that
> do not have iscsi initiator support, nor ever will, in virtual machines.
> For this NFS/RAMDISK root is not an option. Thus I need to take the LUN
> mapping approach. I'll just have to hope that I can pull the Adaptec
> iSCSI HW initator driver into Xen, and that all the configuration tools
> will work.

On a more general note, Xen currently assumes that all vbds are
backed by local disk. We need a mechanism to 'plumb' a specified
vbd such that read/write requests go to another domain (where
arbitrary processing can be performed) rather than out to local
disk.

We need this for a whole bunch of different applications people
want to use Xen for (honeypots, debugging, fault injection,
hardware transparency etc.).

Fortunately, this kind of thing is going to be quite a bit easier
under the ring-1 I/O model. I think the performance will be
pretty good -- we'll never copy data, and attempt to minimize the
number of protection domain switches through pipelining.

Ian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: iscsi

[Keir Fraser]

> On a more general note, Xen currently assumes that all vbds are
> backed by local disk. We need a mechanism to 'plumb' a specified
> vbd such that read/write requests go to another domain (where
> arbitrary processing can be performed) rather than out to local
> disk.
> 
> We need this for a whole bunch of different applications people
> want to use Xen for (honeypots, debugging, fault injection,
> hardware transparency etc.).
> 
> Fortunately, this kind of thing is going to be quite a bit easier
> under the ring-1 I/O model. I think the performance will be
> pretty good -- we'll never copy data, and attempt to minimize the
> number of protection domain switches through pipelining.

Exactly. VBD requests will go directly to the domain containign teh
device driver (via some shared memory comms model). That domain can
implement whatever it needs without having to bloat Xen at all (e.g.,
you could run a full-blown OS, with a TCP stack and anything else you
need). 

In future I don't think that any of the block-device or network code
(not even the VBD interface) will reside in Xen -- it can all be done
in driver domains.

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: iscsi

[Williamson, Mark A]

If you wanted to get something up and running straight away, you might
also want to look at unfsd (runs in user space, so can re-export the
LUNs you import with iSCSI - I don't think kernel NFSd will).

To ease the pain of using NFS to manage multiple machines, you could try
ClusterNFS (an enhancement of unfsd to make it easier to manage clusters
- may be useful for you - this was mentioned by Bin Ren in an earlier
thread).  Also, the user level copy-on-write nfsd (mentioned by Ian
Pratt in another thread) might be good although I don't know who's doing
that or when it'll be ready...

Mark

> -----Original Message-----
> From: Kip Macy [mailto:kmacy@fsmware.com] 
> Sent: 20 January 2004 20:03
> To: Williamson, Mark A
> Cc: xen-devel@lists.sourceforge.net
> Subject: RE: [Xen-devel] iscsi 
> 
> 
> >
> > To re-export iSCSI drives from dom0, I think you'd 
> currently need to use
> > NFS or something similar - to re-export them appearing as 
> "just another
> > VBD" to the guest would require extra code.
> 
> And extra layers + latency etc.
> 
> 
> >
> > Is this relevant or do I have the wrong end of the stick?
> 
> What you're saying sounds exactly right. Plus we can't stick a SW
> initiator in Xen without a TCP stack. My only hope would be a HW
> initiator. How annoying. I wonder how much work it would be to
> support what I'm thinking about? Managing NFS root for n virtual
> machines is much more annoying to manage. It would also make this
> a much harder sell internally.
> 
> 			-Kip
> 
> 
> 


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: iscsi

[Jacob Gorm Hansen]

On Wed, 2004-01-21 at 12:05, Williamson, Mark A wrote:
> If you wanted to get something up and running straight away, you might
> also want to look at unfsd (runs in user space, so can re-export the
> LUNs you import with iSCSI - I don't think kernel NFSd will).
> 
> To ease the pain of using NFS to manage multiple machines, you could try
> ClusterNFS (an enhancement of unfsd to make it easier to manage clusters
> - may be useful for you - this was mentioned by Bin Ren in an earlier
> thread).  Also, the user level copy-on-write nfsd (mentioned by Ian
> Pratt in another thread) might be good although I don't know who's doing
> that or when it'll be ready...

The debian 'diskless' packages used to be good for this task too, but I
do not know if they are still being kept alive.

Jacob



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn