Please make sure you are running a very recent kernel. Btrfs is VERY active and fixes for things like this are going in all the time. Any related crash errors, kernel oopses, and exact methodology so we can reproduce would be useful. dmesg and uname -a would help us triage this and see what we need to fix. Mike
On Sat, Sep 1, 2012 at 3:10 AM, Shentino <shent...@gmail.com> wrote: > > Also, since the problem prevented me from syncing my other filesystmes > I couldn't capture the debug info. > > It vanished during the cold boot still sitting in dirty page cache. > > On Fri, Aug 31, 2012 at 11:44 PM, Shentino <shent...@gmail.com> wrote: > > How effective would it be to directly write to the underlying device > > and then running tests to see if the corruption is properly detected? > > > > I just ran a fuzz test by syncing, and then manually corrupting a file > > with the help of a surgical sed (yes, the before and after patterns > > had fixed equal lengths). First I got an I/O error (expected), then I > > ran scrub and got more problems (not ok), the system froze (not good), > > a reboot failed to mount the system again (worse), and then the fsck > > program dumped core. > -- > 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 -- 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
