On 2004-10-06T12:18:40, christophe.varoqui@xxxxxxx 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@xxxxxxx>
--
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
