linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vijay Chidambaram <vvijay03@gmail.com>
To: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jayashree Mohan <jayashree2912@gmail.com>,
	Ashlie Martinez <ashmrtn@utexas.edu>,
	vijay@cs.utexas.edu
Subject: Crashmonkey and Ace: tools to test file-system crash consistency
Date: Tue, 2 Oct 2018 15:34:17 -0500	[thread overview]
Message-ID: <CAPaz=EJC5O=grad128C5fF=zN=irgbbs78mDH5M4YE96eqQN9A@mail.gmail.com> (raw)

Hi,

My research group at UT Austin has developed two tools to help test
file-system crash-consistency. The tools found 10 previously
undiscovered bugs in btrfs and F2FS (some of which have existed in the
kernel since 2014). The tools work with any POSIX file system, and do
not require any modifications to file-system code.

The first tool, Crashmonkey, takes as input a workload (a sequence of
file-system operations). It runs the workload on a new file system,
simulates crashes after persistence points (fsync/fdatasync/sync),
recovers the file system, and tests if the file system recovered
correctly. It does not use fsck to test crash-consistency; it uses its
own fine-grained checks instead.

The second tool, Automatic Crash Explorer (Ace), generates workloads
that are fed to Crashmonkey. Given constraints such as the size of the
workload or which file-system operations to use in the workload, Ace
systematically generates all workloads that fall within the
constraints.

Together, the tools provide push-button testing of crash-consistency
for POSIX file systems. Based on the computational budget for testing,
you can configure the tools to test different number of workloads.

The improvement over xfstests and dm-log-writes is that given
high-level constraints, generating workloads and testing each workload
is done automatically with our tools. With dm-log-writes and xfstests,
you need to manually write each workload.

Our code is available here: https://github.com/utsaslab/crashmonkey

We have instructions on how to run a single command to test your file
system with over 300 simple workloads. This command should take about
35 min on a single-core machine.

The paper about the work is available here:
http://www.cs.utexas.edu/~jaya/pdf/osdi18-B3.pdf

Slides from our upcoming conference talk:
http://www.cs.utexas.edu/~jaya/slides/osdi18-B3-slides.pdf

Finally, a demo about the tool:
https://www.youtube.com/watch?v=6fiomPVK8o0&feature=youtu.be

We hope you find the tools useful. Thanks to Amir Goldstein and Ted
Ts'o who encouraged us in doing this work!

Thanks,
Vijay Chidambaram
http://www.cs.utexas.edu/~vijay/

                 reply	other threads:[~2018-10-03  3:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPaz=EJC5O=grad128C5fF=zN=irgbbs78mDH5M4YE96eqQN9A@mail.gmail.com' \
    --to=vvijay03@gmail.com \
    --cc=ashmrtn@utexas.edu \
    --cc=jayashree2912@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=vijay@cs.utexas.edu \
    --subject='Re: Crashmonkey and Ace: tools to test file-system crash consistency' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).