[stgt] STGT fork for "broken disk emulation"

[FUJITA Tomonori]

On Tue, 22 Jul 2014 16:23:54 +1000
Mark Harvey <markh794 at gmail.com> wrote:

> Could this be simply a new backing store type ?

Sounds reasonable to me. If we could inject an error dynamically, it
would be useful, I think.

> Depends on error injection you want/need. If it is scsi command related, should be achievable in backing store. If it's transport related then I could see it being more invasive.
> 
> Another idea would be to hijack send/receive diagnostic op code. Initiator could send "injection commands" via receive diag op code payload & check status etc via send diag
> 
> Sent from my iPhone
> 
>> On 22 Jul 2014, at 7:52, ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>> 
>> List,
>> 
>> I have created a temporary work version of TGTD at:
>> https://github.com/rsahlberg/flaky-stgt
>> 
>> This is not a production TGTD or a version that any normal users should use,
>> instead I had an idea to try to add features to make it possible to create an
>> iSCSI device that is broken and misbehaves in controllable ways.
>> 
>> For example, imagine a scsi disk that is "good" right now but after a
>> certain stage in a scripted test the disk goes bad and start failing
>> all WRITE commands.
>> Just like a disk that suddenly has run out of reallocation space.
>> 
>> 
>> The only people I see that could find this type of feature useful
>> would be, I guess,
>> filesystem developers, SCSI initiator midlayer developers or perhaps
>> people writing
>> code that talks directly to the disk and want to test that their error
>> recovery paths
>> work.
>> I see no use or benefit from these features to normal users.
>> 
>> 
>> Right now it is a bit in flux, and I also need to see if I can find
>> buy-in and convince
>> filesystem and block device driver developer folks that this could
>> actually be useful to them.
>> 
>> Later on would come the question, should I refactor the code and
>> should we push this into STGT mainline?
>> I personally think that this usecase I am aiming for is so special
>> case, and is only
>> features that are useful or relevant to an almost infinitely small set
>> of filesystem and block device driver developers that it would not
>> make much sense.
>> But if the TGTD community would rather have this built-in to official TGTD I am
>> more than happy to rework the patches once things stabilize and submit.
>> 
>> This is not a hostile fork. this is a temporary work/scratch space
>> while I experiment
>> on "broken disk emulation" and while I try to see if there is interest
>> in the devlopment community of this as a test tool.
>> 
>> 
>> If anyone of you think this could be useful, please feel to try it out
>> or let your
>> filesystem developer friends know that "could you use a scsi disk that
>> is 'busted' in controllable ways for your testing?"
>> 
>> 
>> best regards
>> ronnie sahlberg
>> --
>> To unsubscribe from this list: send the line "unsubscribe stgt" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html