[stgt] STGT fork for "broken disk emulation"
Mark Harvey
markh794 at gmail.com
Tue Jul 22 08:23:54 CEST 2014
Could this be simply a new backing store type ?
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
More information about the stgt
mailing list