From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: stgt <stgt@vger.kernel.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: STGT fork for "broken disk emulation"
Date: Mon, 21 Jul 2014 14:52:30 -0700 [thread overview]
Message-ID: <CAN05THRgcZUb=6Z3_YVuYShPUPveW4V7aanFCfU-ceYehwpRkQ@mail.gmail.com> (raw)
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
next reply other threads:[~2014-07-21 21:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-21 21:52 ronnie sahlberg [this message]
2014-07-22 6:23 ` STGT fork for "broken disk emulation" Mark Harvey
2014-07-23 14:50 ` FUJITA Tomonori
2014-07-23 17:55 ` ronnie sahlberg
2014-07-25 7:34 ` FUJITA Tomonori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN05THRgcZUb=6Z3_YVuYShPUPveW4V7aanFCfU-ceYehwpRkQ@mail.gmail.com' \
--to=ronniesahlberg@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=stgt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).