On Sat, Sep 1, 2012 at 10:44 PM, David Sterba <d...@jikos.cz> wrote: > On Sat, Sep 01, 2012 at 06:03:32PM -0700, Shentino wrote: >> This whole subject was also about using sed to corrupt-o-magic a >> file's data on disk. >> >> Is this an acceptable method for testing? > > Starting with kernels 3.4 the error handling has been improved, > namely for the EIO, so it shouldn't take your box down when you hit one. > Newer kernels got fixes to the 'transaction abort' cleanup, so it should > be possible to umount and mount the filesystem without problems. > > The filesystem should survive shooting at blocks, the checksums catch > any change (with respect to it's strength, ie. generating a hash > collision will lead to crash/abort later). > > Expected result for reading blocks after random writes is: > * EIO for the corrupted block (both data or metadata) provided that > there's no other copy > * transparent and automatic repair from other copies
I assume the same results are expected during a scrub as during a normal read? > I've tested this on an 2 disk data/raid1, metadata/raid1 with a running > dd over one of the devices continually and using the filesystem. It was > slower. > > > david Would I be correct to assume that a core dump on fsck is an automatic bug or is using the old 3.3.8 kernel a taint that would invalidate a report? Note that this is for the btrfs-progs containing the fsck, not the actual kernel side code. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
