Messages in this thread | | | Date | Mon, 21 Jul 2014 16:23:41 +0200 | From | Hannes Reinecke <> | Subject | ZAC target (Was: Re: dm-multipath: Accept failed paths for multipath maps) |
| |
On 07/18/2014 07:04 PM, John Utz wrote: >> On 07/18/2014 05:31 AM, John Utz wrote: >>> Thankyou very much for the exhaustive answer! I forwarded on to my >>> project peers because i don't think any of us where aware of the >>> existing infrastructure. >>> >>> Of course, said infrastructure would have to be taught about ZAC, >>> but it seems like it would be a nice place to start testing from.... >>> >> ZAC is a different beast altogether; I've posted an initial set of >> patches a while back on linux-scsi. >> But I don't think multipath needs to be changed for that. >> Other areas of device-mapper most certainly do. > > Pretty sure John is working on a new ZAC-oriented DM target. > > YUP. > > Per Ted T'so's suggestion several months ago, the goal is to create > a new DM target that implements the ZAC/ZBC command set and the SMR > write pointer architecture so that FSfolksen can try their hand at > porting their stuff to it. > > It's in the very early stages so there is nothing to show yet, but > development is ongoing. There are a few unknowns about how to surface > some specific behaviors (new verbs and errors, particularly errors > with sense codes that return a write pointer) but i have not gotten > far enuf along in development to be able to construct succint and > specific questions on the topic so that will have to wait for a bit. > I was pondering the 'best' ZAC implementation, too, and found the 'report zones' command _very_ cumbersome to use. Especially the fact that in theory each zone could have a different size _and_ plenty of zones could be present will be making zone lookup hellish.
However: it seems to me that we might benefit from a generic 'block boundaries' implementation. Reasoning here is that several subsystems (RAID, ZAC/ZBC, and things like referrals) impose I/O scheduling boundaries which must not be crossed when assembling requests.
Seeing that we already have some block limitations I was wondering if we couldn't have some set of 'I/O scheduling boundaries' as part of the request_queue structure.
Kent, Jens; comments here?
Cheers,
Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |