Re: STGT fork for "broken disk emulation"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux