On Fri, 1 Mar 2013 14:11:15 -0600, Rich Johnston <rjohnston@xxxxxxx> wrote: > On 02/20/2013 04:42 AM, Dmitry Monakhov wrote: > > There are many situations where disk may fail for example > > 1) brutal usb dongle unplug > > 2) iscsi (or any other netbdev) failure due to network issues > > In this situation filesystem which use this blockdevice is > > expected to fail(force RO remount, abort, etc) but whole system > > should still be operational. In other words: > > 1) Kernel should not panic > > 2) Memory should not leak > > 3) Data integrity operations (sync,fsync,fdatasync, directio) should fail > > for affected filesystem > > 4) It should be possible to umount broken filesystem > > > > Later when disk becomes available again we expect(only for journaled filesystems): > > 5) It will be possible to mount filesystem w/o explicit fsck (in order to caught > > typo s/caught/catch/g > > > issues like https://patchwork.kernel.org/patch/1983981/) > > 6) Filesystem should be operational > > 7) After mount/umount has being done all errors should be fixed so fsck should > > not spot any issues. > > > > This test use fault enjection (CONFIG_FAIL_MAKE_REQUEST=y config option ) > May want to mention all the kernel config options required. > i.e. CONFIG_FAULT_INJECTION=y ... are there others? > CONFIG_FAULT_INJECTION_DEBUG_FS=y ??? Yes, all three options are required. > > > which force all new IO requests to fail for a given device. Xfs already has > to force > > > XFS_IOC_GOINGDOWN ioctl which provides similar behaviour, but it is fs speciffic > > typos s/behaviour/behavior/g s/speciffic/specific > > and it does it in an easy way > because it perform freeze_bdev() before actual > > shotdown. > typo s/shotdown/shutdown/g Agree with your diagnosis. My gramma is bad and I've forget to call spell check before submission. Should I resend this one or you fix it manually on commit time? > > > > > Test run fsstress in background and then force disk failure. > > Once disk failed it check that (1)-(4) is true. > Once the disk fails, check that (1)-(4) are true. > > > Then makes disk available again and check that (5)-(7) is also true > make the disk ... are > > > > BE CAREFUL!! test known to cause memory corruption for XFS > > see: https://gist.github.com/dmonakhov/4953045 > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
