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 --
| Srivatsa Vaddagiri | Re: [PATCH, RFC] reimplement flush_workqueue() |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Rafael J. Wysocki | 2.6.26-rc7-git2: Reported regressions from 2.6.25 |
| Alexey Dobriyan | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ilpo Järvinen | Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
git: | |
