Hi Ted;
Thankyou so much for the prompt response!
On 05/03/2014 09:06 AM, Theodore Ts'o wrote:
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.
No argument here or with any of the other comments that you make. :-)
However, none of these great things are going to happen if I can't
figure out how to get device mapper to return the new errors. :-P
I will continue to look at the dm source, but I hope one of the dm
eminences on the list can provide me with some hints as to what I should
be looking at WRT to making it possible to return these new errors for
reads and writes.
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....
tnx!
johnu
- Ted
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
