[ANNOUNCE] block layer (request based) multipath v1

[ANNOUNCE] block layer (request based) multipath v1

[Mike Christie]

Version 1 and maybe the only version :)

I have pretty much completely convert dm-multipath to blk_mpath. I 
converted the hw handlers (including the out of tree hp-sw and 
engenio-rdac ones) and implemented the emc sense code for Read/Write 
errors. The next task would be to completely convert the open source 
Engenio driver which I had started doing for dm-multipath and the eroro 
code patches but ended up having problems with the sense decoding.

The large patch is here
http://www.cs.wisc.edu/~michaelc/block/blk_mpath/blk_mpath3.patch

I think the only items I have left to convert are some of the dm ioctls, 
but that is trivial and the defaults are ok for usage. For example I 
have not implemted a sysfs attr to read/write queue_if_no_path and a 
timeout attr so we do not have to wait forever on it.

Comments???? Should I work with Christophe to convert the userspace tools?



Changed since last post:

- Fixed partial completion code to support existing scenarios
(for example SCSI MEDIUM ERRORS where the head is completed ok but the 
end could end up failed or ok)
- converted dm-hw_handler code
- Completely converted dm-emc.c including adding RW error sense code
- Added hp-sw and engenio rdac code for failover. I will send sense code 
support when finished gettitng access from OSDL and can test that code, 
but it should basically work but just not so effeciently and when doing 
snapshots or backups or firmware upgrades or other features. Maybe 
Engenio could just implement this now since all the pieces are there, 
except maybe controller representation, or at least give me some docs so 
I do not have to guess about some of the code in the GPL driver :)
- Added a path state sysfs attr for onlining paths. Userspace can online 
a path and do failback now.

Re: [ANNOUNCE] block layer (request based) multipath v1

[Christophe Varoqui]

On Wed, Oct 19, 2005 at 01:20:44AM -0500, Mike Christie wrote:
> Version 1 and maybe the only version :)
>
...
> 
> I think the only items I have left to convert are some of the dm ioctls, 
> but that is trivial and the defaults are ok for usage. For example I 
> have not implemted a sysfs attr to read/write queue_if_no_path and a 
> timeout attr so we do not have to wait forever on it.
> 
> Comments???? Should I work with Christophe to convert the userspace tools?
> 
Nice,

can libdevmapper event listening mecanisms be replaced by the uevents listener ?
IOW, will all necessary attribute changes be reported as uevents ?

Events needed are :
- multipath topology changes :
  - path add/remove (well, this one is guarantied through /block I guess)
  - attributes changes
  - path state changes / path reinstates
  - path group switches
- multipath add/remove (Deduce from /block uevents ?)

Regards,
cvaroqui

Re: [ANNOUNCE] block layer (request based) multipath v1

[Mike Christie]

Christophe Varoqui wrote:
> On Wed, Oct 19, 2005 at 01:20:44AM -0500, Mike Christie wrote:
> 
>>Version 1 and maybe the only version :)
>>
> 
> ...
> 
>>I think the only items I have left to convert are some of the dm ioctls, 
>>but that is trivial and the defaults are ok for usage. For example I 
>>have not implemted a sysfs attr to read/write queue_if_no_path and a 
>>timeout attr so we do not have to wait forever on it.
>>
>>Comments???? Should I work with Christophe to convert the userspace tools?
>>
> 
> Nice,
> 
> can libdevmapper event listening mecanisms be replaced by the uevents listener ?
> IOW, will all necessary attribute changes be reported as uevents ?

It looks like I am going to redo the patches and make it so dm call 
request_fns. So we are basicall going to fix up dm-multipath instead of 
making yet another multipath driver :)

> 
> Events needed are :
> - multipath topology changes :
>   - path add/remove (well, this one is guarantied through /block I guess)
>   - attributes changes
>   - path state changes / path reinstates
>   - path group switches
> - multipath add/remove (Deduce from /block uevents ?)
> 

I was just wondering where is all this netlink stuff? I have not seen a 
dm-netlink interface patch. Are you just keying of events from the 
kobject stuff?

Re: [ANNOUNCE] block layer (request based) multipath v1

[Mike Christie]

Mike Christie wrote:
> 
> I was just wondering where is all this netlink stuff? I have not seen a 
> dm-netlink interface patch. Are you just keying of events from the 
> kobject stuff?
> 

Nevermind I see Ed's mail.

Re: [ANNOUNCE] block layer (request based) multipath v1

[Alasdair G Kergon]

On Thu, Oct 20, 2005 at 03:05:10PM -0500, Mike Christie wrote:
> I was just wondering where is all this netlink stuff? I have not seen a 
> dm-netlink interface patch. 

That's what we need IMHO.
 
Alasdair
-- 
agk@redhat.com