On Mon, Apr 30, 2012 at 10:13 AM, Tommi Virtanen <tommi.virtanen@xxxxxxxxxxxxx> wrote: > On Sat, Apr 28, 2012 at 17:29, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: >> This could be useful for testing the in-kernel Ceph client: >> >> http://www.spinics.net/lists/linux-ext4/msg31856.html > > Well, that post is all about non-networked file systems. > > zzuf has a network mode (-n) where it hijacks the socket calls and can > randomly mutate the bytes transferred. However, I feel like most of > the benefits of that wrapper are lost, as the Ceph network behavior > just isn't very cleanly deterministic.. even if we included the > cluster serving the client inside the System Under Test for the > fuzzing, I feel like the crashes wouldn't be very reproducible, so > fancy features of that wrapper, like the the git bisect integration, > will not be useful. > > What we might want to do is run zzuf to mess with the osds etc while > exercising the usual QA suite, similar to thrashing. Not > deterministically reproducible, but would probably expose some bugs > now and then. Even ext{2,3,4} and btrfs use threads. That means that the behavior under test is never going to be deterministic. The real question is how many bugs would be exposed, and whether those bugs would be fixable with the information provided. Performance testing is the area where nondeterminism really starts to hurt the most. Colin > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
