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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
