From: Yathindra <ydev@cs.utah.edu>
To: linux-scsi@vger.kernel.org
Cc: ydev@cs.utah.edu
Subject: Re: Simulating faulty disk
Date: Thu, 20 Oct 2011 02:43:30 -0600 [thread overview]
Message-ID: <4E9FDF32.6050305@cs.utah.edu> (raw)
In-Reply-To: <4E9FCE16.4070106@cs.utah.edu>
Hi,
Can anybody with experience in using scsi_debug driver tell me if it can
be used to inject medium errors on various file/disk blocks.
And also, can it delay commands so we can simulate an unresponsive disk.
Thanks,
Yathi
On 10/20/2011 1:30 AM, Yathindra wrote:
> Hi Bryan,
>
> I saw this too but it does not have features to delay the commands.
> And it works only at the file level.
>
> I thought about scsi_debug driver but it seems to able to inject
> medium errors on sector 0x1234 only.
> I'm not sure why that limitation exists though.
>
> Thanks,
> Yathi
> On 10/19/2011 10:47 PM, Bryan Mesich wrote:
>> On Wed, Oct 19, 2011 at 09:18:57PM -0600, Yathindra wrote:
>>> Hi,
>>>
>>> I'm trying to simulate a faulty disk behavior on linux. Basically, I
>>> want to inject various disk failure patterns
>>> such as medium errors, unresponsive disk etc.
>>>
>>> What is the best way to go about it. I heard about scsi_debug driver
>>> but
>>> it can only simulate medium
>>> errors on fixed sector 0x1234. Also, scsi fault injection using
>>> Systemtap seems to be a user space tool
>>> limited to files.
>>>
>>> Any suggestions is greatly appreciated.
>> I saw this go by the linux-scsi list a while back thinking it
>> might be useful sometime down the road:
>>
>> http://lwn.net/Articles/265187/
>>
>> I think the project is hosted on sourceforge.net at the following
>> URL:
>>
>> http://scsifaultinjtst.sourceforge.net/
>>
>> I had also read through part of a paper that was co-authored by
>> the same person (from linux symposium 2008):
>>
>> http://www.linuxsymposium.org/archives/OLS/Reprints-2008/tanaka-reprint.pdf
>>
>>
>> Doesn't look like there has been much activity since 2009, but it
>> looks like it has the functionality you need.
>>
>> Bryan
>>
>>> Thanks,
>>> Yathi
>
next prev parent reply other threads:[~2011-10-20 8:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-20 3:18 Simulating faulty disk Yathindra
[not found] ` <20111020044734.GC15211@atlantis.cc.ndsu.nodak.edu>
2011-10-20 7:30 ` Yathindra
2011-10-20 8:43 ` Yathindra [this message]
2011-10-20 9:27 ` Bryn M. Reeves
2011-10-20 15:45 ` Yathindra
2011-10-20 15:56 ` Bryn M. Reeves
2011-10-20 15:59 ` Yathindra
2011-10-20 16:46 ` Yathindra
2011-10-20 17:40 ` Bryn M. Reeves
2011-10-20 17:53 ` Yathindra
[not found] ` <4EA13A52.60902@redhat.com>
[not found] ` <4EA18610.3050900@cs.utah.edu>
2011-10-21 14:56 ` Bryn M. Reeves
2011-10-21 15:00 ` Yathindra
2011-10-21 15:13 ` Yathindra
2011-10-21 15:21 ` Bryn M. Reeves
2011-10-21 16:33 ` Yathindra
2011-10-22 6:16 ` Yathindra
2011-10-21 4:14 ` Yathindra
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=4E9FDF32.6050305@cs.utah.edu \
--to=ydev@cs.utah.edu \
--cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.