On 2004-10-29T23:23:02, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > Multipath work in progress, containing bugs, known and unknown. > Patches 38 onwards haven't been tidied. Hi Alasdair, thanks for all the good work. I'll be merging those tomorrow... > So what else ought to be changed before freezing the interfaces? > [One change I intend to make is struct path to void in dm-hw-handler.h > and dm-path-selector.h] Makes at least sense for the dm-hw-handler, but the path-selector may have some good reasons for keeping some data on a per-path basis. > I'm not convinced of the need for a per-path initialisation function yet. > But a table load flag to suppress the device size checks does sound OK. The idea was simply that if we have hardware-specific handlers already anyway, moving such stuff over there would make sense and be consistent. Table format and status looks good. > Messages: [dmsetup message <devname> <sector> <message>] > disable_group / enable_group - toggle PG priority > Disabled PGs are only used after all paths in enabled PGs have failed. > fail_path / reinstate_path - toggle path status Makes sense. > e.g. dmsetup message mp3 0 fail_if_no_path > > queue_if_no_path / fail_if_no_path - what to do if every path in every PG > has failed. Userspace can check the queue size from the status line to > judge how urgent it is to fix the problem is: if queueing, userspace *must* > intervene to resolve the problem and clear the queue. I'm not convinced here, but also don't have strong feelings. I'd rather think that this is a configuration option and should be handled by reloading the table with or without the option instead. But this is probably a matter of little importance and mostly taste ;-) Also, I do think there should be a high water mark even when queuing, or else we risk blowing away all memory. I'm not sure whether that's an issue though. > Do path selectors and hw_handlers get the info they need? For the hw handlers I think yes. > Should there be any additional infrastructure provided for hw_handler > pg_init fn? (e.g. a callback mechanism) pg_init is required to return > immediately, and must call dm_pg_init_complete() > when it's finished. Does it need more error flags? e.g. to fail all > paths in the PG, not just the one it was called with? This additional error flag might make sense if it detects the whole PG is faulty - either because it doesn't match the LU WWN we expected to see or because the error response to the init command suggests the whole controller is faulty. > I'd like to see hw_handler implementations for at least two different > types of hardware before pushing this upstream. I'll hopefully get to code one for the EMC this week. I got most of the code ready. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company