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