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