On Tue, Sep 06, 2016 at 10:32:28PM +0200, Lukas Lueg wrote: > I'm currently fuzzing rev 2076992 and things start to slowly, slowly > quiet down. We will probably run out of steam at the end of the week > when a total of (roughly) half a billion BTRFS-images have passed by. > I will switch revisions to current HEAD and restart the whole process > then. A few things: > > * There are a couple of crashes (mostly segfaults) I have not reported > yet. I'll report them if they show up again with the latest revision.
Ok. > * The coverage-analysis shows assertion failures which are currently > silenced. An assertion failure is technically a worse disaster > successfully prevented, it still constitutes unexpected/unusable > behaviour, though. Do you want assertions to be enabled and images > triggering those assertions reported? This is basically the same > conundrum as with BUG_ON and abort(). Yes please. I'd like to turn most bugons/assertions into a normal failure report if it would make sense. > * A few endless loops entered into by btrfsck are currently > unmitigated (see bugs 155621, 155571, 155551 and 155151). It would be > nice if those had been taken care of by next week if possible. Two of them are fixed, the other two need more work, updating all callers of read_node_slot and the callchain. So you may still see that kind of looping in more images. I don't have an ETA for the fix, I won't be available during the next week. At the moment, the initial sanity checks should catch most of the corrupted values, so I'm expecting that you'll see different classes of problems in the next rounds. The testsuite now contains all images that you reported and we have a fix in git. There are more utilities run on the images, there may be more problems for us to fix. -- 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
