Adrian Bunk wrote:.. That's exactly the worry. If anyone want's to take a crack at testing some of the more likely fail paths there, just introduce a media error onto a SATA disk that's buried at the bottom of a stacked RAID1 over RAID0 over LVM, with XFS and nfsd on top. Or something like that. And then experiment with corrupting meta data rather than simply file data. How-to introduce a media error? hdparm --make-bad-sector nnnnnn /dev/sdX This catches the most likely (IMHO) failure scenarios, but still comes nowhere near 100% code coverage. :( Cheers --
| Joe Perches | [PATCH 143/148] include/asm-x86/vm86.h: checkpatch cleanups - formatting only |
| Linus Torvalds | Re: Back to the future. |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
