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
