[dm-devel] Can device mapper be taught to return new errors and sense codes that are part of the ZAC/ZBC spec?

[Theodore Ts'o]

On Sat, May 03, 2014 at 02:40:51AM +0000, John Utz wrote:
> 
> This question is also related to the same simulator project mentioned in my previous email.
> 
> The ZAC/ZBC spec(s) specify some errors that dont currently
> exist. For the simulator to be successful, it needs to be able to
> respond appropriately to being asked to do things that other drives
> are allowed to do, but this one is not.
> 
> So read's and writes for the simulator have to return errors that
> dont currently exist in the kernel as of today.
> 
> I notice that struct dm_target has an error string entry, but that
> is only for the ctor and it's a string.
> 
> Can any of you provide any suggestions of guidance on this topic?

My recommendation is to make things configurable.  One option is to
treat it as if it were a real ZAC/ZBC specification, which is to treat
an out-of-policy write as an I/O error --- after all, this is what a
real restricted-mode drive would do.

Another option is to simply keep statistics on the number
out-of-policy writes, and to use tracepoints so that developers can
have some kind of metric of how "SMR friendly" their
application/filesystem is currently faring.

One final option, which is a nice-to-have, is to try to model a drive
managed or host aware drive by adding latency to various I/O
operations after out-of-policy I/O operations have occurred.  It
doesn't have to be perfect, and it's very likely that a precise model
of what drives will actually do will be a closely held secret.  So
what I'd suggest is to make the delay model to be a pluggable
interface with with an EXPORT_SYMBOL interface (with an explicit note
that the intention that the intent of the author is to allow
proprietary delay modelling modules to be able to use this interface).

Eventually, manufacturers desires to try to keep the delay profiles a
proprietary a secret will be hopeless, since open source developers
can just simply carry out timing attacks on SMR drives and develop
statistical models that that will in all likelihood be very good.  But
given our experience with how SDD manufactuers have tried to keep the
erase block and page size of their products to be a proprietary secret
(despite open source programs that figure this out experimentally),
there really is no limit to the stupidity and paranoia of product
managers and lawyers....

	      	       	  	  	       - Ted