From: Yathindra <ydev@cs.utah.edu>
To: "Bryn M. Reeves" <bmr@redhat.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: Simulating faulty disk
Date: Fri, 21 Oct 2011 09:13:21 -0600 [thread overview]
Message-ID: <4EA18C11.5060600@cs.utah.edu> (raw)
In-Reply-To: <4EA188F3.4000206@cs.utah.edu>
>mount -t ext3 /dev/sdb /mnt
Copied some data into /mnt
>dmsetup create d0 --table="0 `blockdev --getsize /dev/sdb` delay
/dev/sdb 0 500"
device-mapper: reload ioctl failed: Invalid argument
Command failed
>umount /mnt
> dmsetup create d0 --table="0 `blockdev --getsize /dev/sdb` delay
/dev/sdb 0 500"
Worked.
Basically, am trying to test how regular userspace commands to
read/write files
behave when I/O fails. For this, I need to put a file system and then
carry on testing.
But as seen from above, dmsetup is failing to create a flakey/delay
device when /dev/sdb
has a filesystem on top of it. Is there any workaround ?
Thanks,
Yathi
On 10/21/2011 9:00 AM, Yathindra wrote:
> Ok :) Bryn is there a more elaborate document which shows simple
> examples
> to work with device mapper. For a newbie like me it would be really
> helpful.
>
> Thanks,
> Yathi
>
> On 10/21/2011 8:56 AM, Bryn M. Reeves wrote:
>> On 10/21/2011 03:47 PM, Yathindra wrote:
>>> dmsetup create d0 --table="0 `blockdev --getsize /dev/sdb` delay
>>> /dev/sdb 0 500"
>>> dmsetup create f0 --table="0 `blockdev --getsize /dev/mapper/d0` flakey
>>> /dev/mapper/d0 0 9 1"
>>> mkfs -t ext3 /dev/mapper/f0
>>> ...
>>> ...
>>> ext2fs_mkdir: Attempt to read block from filesystem resulted in short
>>> read while creating root dir
>>>
>>> Can we even mount such a device ?
>>
>> It's a flakey device :)
>>
>> With that table you'll have a device that is failing write I/Os for
>> 1s in every ten. If that coincides with mkfs trying to write to the
>> device it will create a corrupted file system.
>>
>> Depending on what you are trying to test you may want to put data on
>> the device first.
>>
>> Regards,
>> Bryn.
>
next prev parent reply other threads:[~2011-10-21 15:13 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
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 [this message]
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=4EA18C11.5060600@cs.utah.edu \
--to=ydev@cs.utah.edu \
--cc=bmr@redhat.com \
--cc=dm-devel@redhat.com \
/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.