Re: [RFC] A SCSI fault injection framework using SystemTap.
The new framework is tested on Fedora8(i386) running with kernel 2.6.23.12. So far, I'm cleaning up the tool set for release, and plan to post it in the near future. Now it's ready. The scsi fault injection tool is available from the following site. https://sourceforge.net/projects/scsifaultinjtst/ If you have any comments, please let me know. Additionally, the deadlock problem reproduced also on md RAID10. I think that the same reason for RAID1 deadlock reported earlier cause this problem, because raid10.c is based on raid1.c. e.g. -The kernel thread for md RAID1 could cause a deadlock when the error handler for md RAID1 contends with the write access to the md RAID1 array. I've reproduced the deadlock on RAID10 using this tool with a small shell script for automatically injecting a fault repeatedly. But I can't come up with any good idea for the patch to fix this problem so far. -- Kenichi TANAKA| Open Source Software Platform Development Division | Computers Software Operations Unit, NEC Corporation | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] A SCSI fault injection framework using SystemTap.
Matthew Wilcox wrote: On Tue, Jan 15, 2008 at 12:04:09PM +0900, K.Tanaka wrote: I would like to introduce a SCSI fault injection framework using SystemTap. Currently, kernel has Fault-injection framework and Faulty mode for md, which can also be used for testing the error handling. But, they could only produce fixed type of errors stochastically. In order to simulate more realistic scsi disk faults, I have created a new flexible fault injection framework using SystemTap. How does it compare to using scsi_debug, which I believe can do all of the above and more? Sorry for the lack of explanation. The new framework is supposed to be used by a userspace testing tool (such as a shell script). For the availability, this framework enables user to designate the inode number of the target file on the device to inject faults. On accessing the target file through page caches, a fault will be injected. Also, user can designate the logical block address as the target position of a fault injection. -- - Kenichi TANAKA| Open Source Software Platform Development Division | Computers Software Operations Unit, NEC Corporation | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [RFC] A SCSI fault injection framework using SystemTap.
On Tue, Jan 15, 2008 at 12:04:09PM +0900, K.Tanaka wrote: -dm-mirror's redundancy doesn't work. A read error from the disk consisting the array will be directory passed to the userspace, without reading from the other mirror. (It turns out that this issue is a known issue, but the patch is not merged. http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-raid1-handle-read-failures.patch) It's in the queue for 2.6.25. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] A SCSI fault injection framework using SystemTap.
On Tue, Jan 15, 2008 at 12:04:09PM +0900, K.Tanaka wrote: I would like to introduce a SCSI fault injection framework using SystemTap. Currently, kernel has Fault-injection framework and Faulty mode for md, which can also be used for testing the error handling. But, they could only produce fixed type of errors stochastically. In order to simulate more realistic scsi disk faults, I have created a new flexible fault injection framework using SystemTap. How does it compare to using scsi_debug, which I believe can do all of the above and more? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
