Hi Amir, I neglected to mention this earlier: CrashMonkey does not require recompiling the kernel (it is a stand-alone kernel module), and has been tested with the kernel 4.4. It should work with future kernel versions as long as there are no changes to the bio structure. As it is, I believe CrashMonkey is compatible with the current kernel. It certainly provides functionality beyond log-writes (the ability to replay a subset of writes between FLUSH/FUA), and we intend to add more functionality in the future. Right now, CrashMonkey does not do random sampling among possible crash states -- it will simply test a given number of unique states. Thus, right now I don't think it is very effective in finding crash-consistency bugs. But the entire infrastructure to profile a workload, construct crash states, and test them with fsck is present. I'd be grateful if you could try it and give us feedback on what make testing easier/more useful for you. As I mentioned before, this is a work-in-progress, so we are happy to incorporate feedback. Thanks, Vijay Chidambaram, http://www.cs.utexas.edu/~vijay/ On Tue, Aug 15, 2017 at 3:32 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Tue, Aug 15, 2017 at 8:01 PM, Vijay Chidambaram <vvijay03@xxxxxxxxx> wrote: >> Hi Josef and Amir, >> > ... >> >> @Amir: Given that Josef's code is already in the kernel, do you think >> changing CrashMonkey code would be useful? We are always happy to >> provide something for upstream, but we want to be sure how much work >> would be involved. >> > > Simply put, people (myself included) are more likely to use CrashMonkey > if it uses upstream kernel and/or if it brings valuable functionality > to filesystem > testing, beyond what log-writes already does - > I am have not studies either tools yet to be able to determine if that > is the case. > > Cheers, > Amir.
