Hi Zach, 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. Regards Jim -----Original Message----- From: linux-fsdevel-owner@xxxxxxxxxxxxxxx [mailto:linux-fsdevel-owner@xxxxxxxxxxxxxxx] On Behalf Of Zach Brown Sent: Wednesday, August 20, 2014 12:43 PM To: Albert Chen Cc: Rohan Puri; Darrick J. Wong; linux-fsdevel@xxxxxxxxxxxxxxx Subject: Re: SMR projects On Tue, Aug 19, 2014 at 11:13:28PM +0000, Albert Chen wrote: > Hi Rohan and Darrick, > > Thanks for your feedback. We plan to release documentation first, then code once it passes our internal test matrix. > In the meantime - if you get a chance, could you please let us know if our simulator behavior is what you would expect? > > https://github.com/westerndigitalcorporation/SMR-Simulator/wiki/SMR-Si > mulator-Behavior-Expectations That looks reasonable. Some totally unorganized questions: - 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? - How does the WP interact with concurrent requests? Is it evaluated serially as commands first arrive? [wd] - Assume this question refers to queued commands. I can't speak for the host driver side, but on the device, command queues for writes will be reordered to be sequential. If the write queue cannot be reordered to be sequential, command queue processing will stall. An exit from the stall condition could be initiated by a TLER (time limit error recovery) timeout - 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 - 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. 2. WRITE SAME - should follow all the rules for a write command. WRITE SAME only covers a single LBA range. One consideration is that RESET WRITE POINTERS all will have a similar effect to write same. 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. - Is the emulator addressing SWP update persistence and write completion ordering? [wd] - We will save the simulator state on the backing disk, so WP for each zone persistent across reboot. We do not check the order of IO completion, only when the IO is received by the device mapper target. - 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 -- 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
