On Fri, 25 Feb 2011 14:36:00 +1100 ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > On Wed, Feb 23, 2011 at 11:00 AM, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> wrote: > > On Sat, 19 Feb 2011 18:29:36 +1100 > > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > > > >> Libiscsi now has support to generate task management functions. > >> This can be used in to easily and reliably generate task management > >> functions and send these to a target to test that > >> the tm operations work. > >> For example in 'make test' or in special tools written for regression testing. > >> > >> > >> As there has been a few tm related issues in stgt, and that is often > >> 'difficult' to manually generate such functions from userspace, > >> I think that this support in libiscsi will be useful. > > > > Nice, I should test tgt with it. > > Would it be useful to add some "make test" framework which could run a > number of small tests with tgtd and dedicated applications built on > libiscsi and similar ? > > Things like > 1) Write a singe huge WRITE10 to the target containing random data and > then read it back with READ10 and compare the result? > 2) Send a huge number of WRITE10 to the target, then immediately send > ABORT TASK for all of them and make sure tgtd does not segv ? > 3) Take out a reserve, then from a different session try to do I/O and > verify the reserve works ? > > Something like that, a set of many small test applications and tests > that are run one by one to verify one task at a time. Surely, such could be very useful. I suspect it's difficult to test TMF (abort, etc) since in most cases, the target is fast enough. > I can start building an initial framework and a couple of small tests > if you want to. > It would mean that in order to do 'make test' on STGT you would have a > dependency that you would need libiscsi so that you can build the test > tools. I don't think that adding libiscsi dependency to tgt is a good idea (at least, until libiscsi is shipped in most of Linux distributions). I think that we have such framework as a separate project. The framework can be useful for other iSCSI target implementations too. > (This could also allow 'fuzz'-testing. Which is often very useful for > testing boundary cases that are 'difficult/impossible' to generate > using a real bug-free client. Fuzz testing could be 'do all these I/O > over and over but add random modification to iscsi and scsi headers, > sending deliberately 'bad' commands to the server over and over to see > if you eventually get a segv or similar) I think that this is a useful feature too. Thanks! -- 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
