On Tue, Aug 26, 2014 at 10:42:58PM +0000, Jim Malina wrote: > Thanks for your questions. Our team has collaborated for given responses below. > FYI, previously we mistakenly referenced SWP, which is now named Write Pointer (WP). > I've changed SWP to WP references. Cool, thanks for the details. They certainly make it a lot easier to imagine what some kind of dm-smr mapping layer might look like. > - Can we use trace points for monitoring the interaction of commands and > zones and the WP? > > [wd] - Yes, we plan to have trace points in the main IO path. > Do you have specific requests for tracing? I don't have specific requests, no. I trust you guys to pick interesting events. I just wanted them to be easy to work with :). > - How does the WP interact with write failure? I'd guess it's always > advanced so that the host doesn't have to worry about resetting where > it's sending IO. > > [wd] - The WP will point to the next sequential LBA in a zone to be written. > In an error case, the sense code will contain the next WP Ah, OK. That feedback from the error handling paths back into the submission paths will certainly be something to watch out for (and test). > - I guess commands like trim/write same/xcopy would be processed as > combinations of reads and writes. > > [wd] - These need to be broken up into 3 cases... > > 1. Trim - We're still contemplating trim. This has ranges passed in. > Range operation is straight forward. The question is a trim to an > unwritten area of a zone, or a trim straddling a written and unwritten area. > Not sure about this case. I would fail the trim command on a range that straddles a zone. I agree. Symmetry between failing straddling writes and failing straddling trims makes sense. > 3. XCOPY - This command is currently not defined for ZAC/SBC devices. > We are considering defining a replacement, GARBAGE COLLECT, or > SCATTERED WRITE. Not sure the name at this point. > The yet to be proposed command would take a list of LBA ranges and > write their data to a destination zone. Optionally, this command could > perform a reset write pointer on all the zones that contained the ranges. > Just a thought. Yeah, definitely interesting. I imagine we'd want to see how much time significant workloads spend reclaiming zones and if the device has a lot more concurrent bandwidth with which to do that. I think I'd call it a gathering write though.. lots of disjoing source zone:LBA ranges being grouped into one contiguous write at a zone's WP. - z -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
