Re: [RFC] SCSI support for SMR/ZBC commands

[Hannes Reinecke <hare@suse.de>]

On 05/05/2014 11:28 PM, HanBin Yoon wrote:
> SMR (Shingled Magnetic Recording) disk drives are able to achieve higher areal
> density, at the cost of making media write operations to the disk more
> inflexible (i.e., divides the disk into multiple zones, each of which can be
> written sequentially only).
>
> Following on some discussions in the Linux filesystem community around SMR
> [1][2], I'd like to work on adding early support for SMR-related SCSI commands
> (ZBC, or Zoned Block Commands [3]). First, I'd like to ask the Linux SCSI/
> filesystem communities for advice and recommendations on how to go about it.
>
> [1] http://thread.gmane.org/gmane.linux.file-systems/81970/focus=82309
> [2] http://www.spinics.net/lists/linux-fsdevel/msg72305.html
> [3] http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-010r8.pdf
>
> I'm thinking of classifying an SMR disk drive as an sd-type SCSI device, as SMR
> is expected to be delivered in the form of an add-on/enhancement to existing
> traditional disk drives. SMR disk drives will continue to support random read
> capability.
>
> As for exposing ZBC to upper layers of the stack, I'm thinking of two potential
> ways:
>    A) As an ioctl handled by sd_ioctl(), in drivers/scsi/sd.c
>    B) As a request command flag type handled by sd_prep_fn(), in
>       drivers/scsi/sd.c
>
The actual idea was that ZMR/ZBC devices will show up as a separate 
SCSI device type. This should be handled as a separate sub-type of 
the existing 'sd' driver.

We have discussed the problem with exposing zones to upper layers; 
as there'll be quite a lot of zones per device (in the order of 
1000) it's impractical to expose these zones via sysfs individually.
If there were a way to expose the zone information in compact way we 
might want to revisit this.

I'm not quite convinced that we need an additional ioctl for the two 
new commands; my initial plan here is to add support for this in 
sg3_utils and use the stock SG_IO here.

I would start by adding support for the special request (as you 
already did in your second patch), and to figure out if and how the 
zone information could be held in the block request_queue structure.

Problem here is that we need to tweak the allocator to not issue 
requests spanning two zones. So either we'll be setting up a 
device-mapper target here (like dm-switch or suchlike) which will 
format the I/O for us, or we're pushing this information into the 
block layer proper.

I really would like to see the real solution of pushing it into the 
block layer / request_queue limitations, but for that we'll need 
some efficient way of storing and looking up the zone configuration.

Ted T'so said he would be having some code for that ... Ted?

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-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html