123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305 |
- dm-dust
- =======
- This target emulates the behavior of bad sectors at arbitrary
- locations, and the ability to enable the emulation of the failures
- at an arbitrary time.
- This target behaves similarly to a linear target. At a given time,
- the user can send a message to the target to start failing read
- requests on specific blocks (to emulate the behavior of a hard disk
- drive with bad sectors).
- When the failure behavior is enabled (i.e.: when the output of
- "dmsetup status" displays "fail_read_on_bad_block"), reads of blocks
- in the "bad block list" will fail with EIO ("Input/output error").
- Writes of blocks in the "bad block list will result in the following:
- 1. Remove the block from the "bad block list".
- 2. Successfully complete the write.
- This emulates the "remapped sector" behavior of a drive with bad
- sectors.
- Normally, a drive that is encountering bad sectors will most likely
- encounter more bad sectors, at an unknown time or location.
- With dm-dust, the user can use the "addbadblock" and "removebadblock"
- messages to add arbitrary bad blocks at new locations, and the
- "enable" and "disable" messages to modulate the state of whether the
- configured "bad blocks" will be treated as bad, or bypassed.
- This allows the pre-writing of test data and metadata prior to
- simulating a "failure" event where bad sectors start to appear.
- Table parameters
- ----------------
- <device_path> <offset> <blksz>
- Mandatory parameters:
- <device_path>:
- Path to the block device.
- <offset>:
- Offset to data area from start of device_path
- <blksz>:
- Block size in bytes
- (minimum 512, maximum 1073741824, must be a power of 2)
- Usage instructions
- ------------------
- First, find the size (in 512-byte sectors) of the device to be used::
- $ sudo blockdev --getsz /dev/vdb1
- 33552384
- Create the dm-dust device:
- (For a device with a block size of 512 bytes)
- ::
- $ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 512'
- (For a device with a block size of 4096 bytes)
- ::
- $ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096'
- Check the status of the read behavior ("bypass" indicates that all I/O
- will be passed through to the underlying device; "verbose" indicates that
- bad block additions, removals, and remaps will be verbosely logged)::
- $ sudo dmsetup status dust1
- 0 33552384 dust 252:17 bypass verbose
- $ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct
- 128+0 records in
- 128+0 records out
- $ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
- 128+0 records in
- 128+0 records out
- Adding and removing bad blocks
- ------------------------------
- At any time (i.e.: whether the device has the "bad block" emulation
- enabled or disabled), bad blocks may be added or removed from the
- device via the "addbadblock" and "removebadblock" messages::
- $ sudo dmsetup message dust1 0 addbadblock 60
- kernel: device-mapper: dust: badblock added at block 60
- $ sudo dmsetup message dust1 0 addbadblock 67
- kernel: device-mapper: dust: badblock added at block 67
- $ sudo dmsetup message dust1 0 addbadblock 72
- kernel: device-mapper: dust: badblock added at block 72
- These bad blocks will be stored in the "bad block list".
- While the device is in "bypass" mode, reads and writes will succeed::
- $ sudo dmsetup status dust1
- 0 33552384 dust 252:17 bypass
- Enabling block read failures
- ----------------------------
- To enable the "fail read on bad block" behavior, send the "enable" message::
- $ sudo dmsetup message dust1 0 enable
- kernel: device-mapper: dust: enabling read failures on bad sectors
- $ sudo dmsetup status dust1
- 0 33552384 dust 252:17 fail_read_on_bad_block
- With the device in "fail read on bad block" mode, attempting to read a
- block will encounter an "Input/output error"::
- $ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=1 skip=67 iflag=direct
- dd: error reading '/dev/mapper/dust1': Input/output error
- 0+0 records in
- 0+0 records out
- 0 bytes copied, 0.00040651 s, 0.0 kB/s
- ...and writing to the bad blocks will remove the blocks from the list,
- therefore emulating the "remap" behavior of hard disk drives::
- $ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
- 128+0 records in
- 128+0 records out
- kernel: device-mapper: dust: block 60 removed from badblocklist by write
- kernel: device-mapper: dust: block 67 removed from badblocklist by write
- kernel: device-mapper: dust: block 72 removed from badblocklist by write
- kernel: device-mapper: dust: block 87 removed from badblocklist by write
- Bad block add/remove error handling
- -----------------------------------
- Attempting to add a bad block that already exists in the list will
- result in an "Invalid argument" error, as well as a helpful message::
- $ sudo dmsetup message dust1 0 addbadblock 88
- device-mapper: message ioctl on dust1 failed: Invalid argument
- kernel: device-mapper: dust: block 88 already in badblocklist
- Attempting to remove a bad block that doesn't exist in the list will
- result in an "Invalid argument" error, as well as a helpful message::
- $ sudo dmsetup message dust1 0 removebadblock 87
- device-mapper: message ioctl on dust1 failed: Invalid argument
- kernel: device-mapper: dust: block 87 not found in badblocklist
- Counting the number of bad blocks in the bad block list
- -------------------------------------------------------
- To count the number of bad blocks configured in the device, run the
- following message command::
- $ sudo dmsetup message dust1 0 countbadblocks
- A message will print with the number of bad blocks currently
- configured on the device::
- countbadblocks: 895 badblock(s) found
- Querying for specific bad blocks
- --------------------------------
- To find out if a specific block is in the bad block list, run the
- following message command::
- $ sudo dmsetup message dust1 0 queryblock 72
- The following message will print if the block is in the list::
- dust_query_block: block 72 found in badblocklist
- The following message will print if the block is not in the list::
- dust_query_block: block 72 not found in badblocklist
- The "queryblock" message command will work in both the "enabled"
- and "disabled" modes, allowing the verification of whether a block
- will be treated as "bad" without having to issue I/O to the device,
- or having to "enable" the bad block emulation.
- Clearing the bad block list
- ---------------------------
- To clear the bad block list (without needing to individually run
- a "removebadblock" message command for every block), run the
- following message command::
- $ sudo dmsetup message dust1 0 clearbadblocks
- After clearing the bad block list, the following message will appear::
- dust_clear_badblocks: badblocks cleared
- If there were no bad blocks to clear, the following message will
- appear::
- dust_clear_badblocks: no badblocks found
- Listing the bad block list
- --------------------------
- To list all bad blocks in the bad block list (using an example device
- with blocks 1 and 2 in the bad block list), run the following message
- command::
- $ sudo dmsetup message dust1 0 listbadblocks
- 1
- 2
- If there are no bad blocks in the bad block list, the command will
- execute with no output::
- $ sudo dmsetup message dust1 0 listbadblocks
- Message commands list
- ---------------------
- Below is a list of the messages that can be sent to a dust device:
- Operations on blocks (requires a <blknum> argument)::
- addbadblock <blknum>
- queryblock <blknum>
- removebadblock <blknum>
- ...where <blknum> is a block number within range of the device
- (corresponding to the block size of the device.)
- Single argument message commands::
- countbadblocks
- clearbadblocks
- listbadblocks
- disable
- enable
- quiet
- Device removal
- --------------
- When finished, remove the device via the "dmsetup remove" command::
- $ sudo dmsetup remove dust1
- Quiet mode
- ----------
- On test runs with many bad blocks, it may be desirable to avoid
- excessive logging (from bad blocks added, removed, or "remapped").
- This can be done by enabling "quiet mode" via the following message::
- $ sudo dmsetup message dust1 0 quiet
- This will suppress log messages from add / remove / removed by write
- operations. Log messages from "countbadblocks" or "queryblock"
- message commands will still print in quiet mode.
- The status of quiet mode can be seen by running "dmsetup status"::
- $ sudo dmsetup status dust1
- 0 33552384 dust 252:17 fail_read_on_bad_block quiet
- To disable quiet mode, send the "quiet" message again::
- $ sudo dmsetup message dust1 0 quiet
- $ sudo dmsetup status dust1
- 0 33552384 dust 252:17 fail_read_on_bad_block verbose
- (The presence of "verbose" indicates normal logging.)
- "Why not...?"
- -------------
- scsi_debug has a "medium error" mode that can fail reads on one
- specified sector (sector 0x1234, hardcoded in the source code), but
- it uses RAM for the persistent storage, which drastically decreases
- the potential device size.
- dm-flakey fails all I/O from all block locations at a specified time
- frequency, and not a given point in time.
- When a bad sector occurs on a hard disk drive, reads to that sector
- are failed by the device, usually resulting in an error code of EIO
- ("I/O error") or ENODATA ("No data available"). However, a write to
- the sector may succeed, and result in the sector becoming readable
- after the device controller no longer experiences errors reading the
- sector (or after a reallocation of the sector). However, there may
- be bad sectors that occur on the device in the future, in a different,
- unpredictable location.
- This target seeks to provide a device that can exhibit the behavior
- of a bad sector at a known sector location, at a known time, based
- on a large storage device (at least tens of gigabytes, not occupying
- system memory).
|