[dm-devel] 2.6.10-rc1-udm1: multipath work in progress

[Lars Marowsky-Bree]

On 2004-10-29T23:23:02, Alasdair G Kergon <agk at redhat.com> 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 at suse.de>

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