SMR projects

SMR projects

[Albert Chen]

Hi,

We (Western Digital) have been busy implementing a device mapper SMR simulator (Core-04) and is starting work on Core-05 as per SMR project list at https://docs.google.com/spreadsheet/ccc?key=0ArpHfE64ikfsdHROWE5Icm9tOWFCNVlnZGFMM21VRFE&usp=sharing#gid=1.

As a reality/course check: are Core-04 and Core-05 still of interest/value to the community?


Thanks!
Albert

Re: SMR projects

[Darrick J. Wong]

On Wed, Aug 13, 2014 at 10:03:20PM +0000, Albert Chen wrote:
> Hi,
> 
> We (Western Digital) have been busy implementing a device mapper SMR simulator (Core-04) and is starting work on Core-05 as per SMR project list at https://docs.google.com/spreadsheet/ccc?key=0ArpHfE64ikfsdHROWE5Icm9tOWFCNVlnZGFMM21VRFE&usp=sharing#gid=1.
> 
> As a reality/course check: are Core-04 and Core-05 still of interest/value to the community?

I certainly think so, if we can get it into device-mapper. :)

--D
> 
> 
> Thanks!
> Albert
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SMR projects

[Rohan Puri]

On Thu, Aug 14, 2014 at 4:31 AM, Darrick J. Wong
<darrick.wong@oracle.com> wrote:
> On Wed, Aug 13, 2014 at 10:03:20PM +0000, Albert Chen wrote:
>> Hi,
>>
>> We (Western Digital) have been busy implementing a device mapper SMR simulator (Core-04) and is starting work on Core-05 as per SMR project list at https://docs.google.com/spreadsheet/ccc?key=0ArpHfE64ikfsdHROWE5Icm9tOWFCNVlnZGFMM21VRFE&usp=sharing#gid=1.
>>
>> As a reality/course check: are Core-04 and Core-05 still of interest/value to the community?
>
> I certainly think so, if we can get it into device-mapper. :)
>
> --D
>>
>>
>> Thanks!
>> Albert
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Albert,

Can you send patches for the same, so that others interested can go through?

- Rohan

RE: SMR projects

[Albert Chen]

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-Simulator-Behavior-Expectations


Thanks!
Albert

-----Original Message-----
From: Rohan Puri [mailto:rohan.puri15@gmail.com] 
Sent: Thursday, August 14, 2014 1:30 AM
To: Darrick J. Wong
Cc: Albert Chen; linux-fsdevel@vger.kernel.org
Subject: Re: SMR projects

On Thu, Aug 14, 2014 at 4:31 AM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> On Wed, Aug 13, 2014 at 10:03:20PM +0000, Albert Chen wrote:
>> Hi,
>>
>> We (Western Digital) have been busy implementing a device mapper SMR simulator (Core-04) and is starting work on Core-05 as per SMR project list at https://docs.google.com/spreadsheet/ccc?key=0ArpHfE64ikfsdHROWE5Icm9tOWFCNVlnZGFMM21VRFE&usp=sharing#gid=1.
>>
>> As a reality/course check: are Core-04 and Core-05 still of interest/value to the community?
>
> I certainly think so, if we can get it into device-mapper. :)
>
> --D
>>
>>
>> Thanks!
>> Albert
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-fsdevel" in the body of a message to majordomo@vger.kernel.org 
>> 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@vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Albert,

Can you send patches for the same, so that others interested can go through?

- Rohan

Re: SMR projects

[Zach Brown]

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-Simulator-Behavior-Expectations

That looks reasonable.  Some totally unorganized questions:

- Can we use trace points for monitoring the interaction of commands and
  zones and the SWP? 

- How does the SWP interact with concurrent requests?  Is it evaluated
  serially as commands first arrive?

- How does the SWP 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.

- I guess commands like trim/write same/xcopy would be processed as
  combinations of reads and writes.

- Is the emulator addressing SWP update persistence and write completion
  ordering?

- z

RE: SMR projects

[Jim Malina]

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@vger.kernel.org [mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of Zach Brown
Sent: Wednesday, August 20, 2014 12:43 PM
To: Albert Chen
Cc: Rohan Puri; Darrick J. Wong; linux-fsdevel@vger.kernel.org
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@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SMR projects

[Zach Brown]

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