On Wed, 28 Sep 2011 12:48:37 -0700 Jojy Varghese <jojy.varghese@xxxxxxxxx> wrote: > Hi > I am trying to dynamically add error injection to my virtual > disk(LVM) for testing+ debugging purpose. I saw "faulty" personality > module in the kernel and was wondering if there was any documentation > on its usage. I am not looking to set up a RAID but a simple mapped > device. So the basic use case is that I need to be able to dynamically > add/remove error sectors and also be able to have granular error > configuration like read error, read+write error etc. > > thanks in advance > Jojy > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html The 'faulty' md personality is described briefly in the 'md.4' man page which is included in the mdadm distribution. I've included the relevant part below. Configuring the type of faults is described in mdadm.8 under the '-p --layout=' section. So can adjust the settings using mdadm --grow. so: mdadm -B /dev/md0 -l faulty -n1 /dev/sda will build a 'faulty' device which provides access to /dev/sda, but introduces faults. Initially no faults will be introduces. mdadm -G /dev/md0 --layout=rt400 will tell md0 to generate a read error every 400 requests, but not to remember the error - rt == readtransient --layout=rp400 will create a persistent error every 400 reads subsequent reads of the same block will produce the same error. at most 50 persistent errors can be recorded. mdadm -G /dev/md0 --layout=clear will stop producing new errors mdadm -G /dev/md0 --layout=flush will forget all persistent errors. from md.4: FAULTY The FAULTY md module is provided for testing purposes. A faulty array has exactly one component device and is normally assembled without a superblock, so the md array created provides direct access to all of the data in the component device. The FAULTY module may be requested to simulate faults to allow testing of other md levels or of filesystems. Faults can be chosen to trigger on read requests or write requests, and can be transient (a subsequent read/write at the address will probably succeed) or persistent (subse- quent read/write of the same address will fail). Further, read faults can be "fixable" meaning that they persist until a write request at the same address. Fault types can be requested with a period. In this case, the fault will recur repeatedly after the given number of requests of the rele- vant type. For example if persistent read faults have a period of 100, then every 100th read request would generate a fault, and the faulty sector would be recorded so that subsequent reads on that sector would also fail. There is a limit to the number of faulty sectors that are remembered. Faults generated after this limit is exhausted are treated as tran- sient. The list of faulty sectors can be flushed, and the active list of fail- ure modes can be cleared. from mdadm.8: When setting the failure mode for level faulty, the options are: write-transient, wt, read-transient, rt, write-persistent, wp, read-persistent, rp, write-all, read-fixable, rf, clear, flush, none. Each failure mode can be followed by a number, which is used as a period between fault generation. Without a number, the fault is generated once on the first relevant request. With a number, the fault will be generated after that many requests, and will continue to be generated every time the period elapses. Multiple failure modes can be current simultaneously by using the --grow option to set subsequent failure modes. "clear" or "none" will remove any pending or periodic failure modes, and "flush" will clear any persistent faults. NeilBrown
Attachment:
signature.asc
Description: PGP signature
