RefusetoCrashwithRe-FUSE.PDFVIP

Refuse to Crash with Re-FUSE Swaminathan Sundararaman Laxman Visampalli Andrea C. Arpaci-Dusseau Computer Sciences Department, Qualcomm Inc. Remzi H. Arpaci-Dusseau University of Wisconsin-Madison laxmanv@ Computer Sciences Department, swami@ University of Wisconsin-Madison {dusseau,remzi}@ Abstract ?ve years for storage products to “harden” and thus become We introduce Re-FUSE, a framework that provides sup- ready for real commercial usage [Vahdat 2010]. port for restartable user-level ?le systems. Re-FUSE mon- One reason for this reluctance to adopt new technology itors the user-level ?le-system and on a crash transparently is that unproven software often still has bugs in it, beyond restarts the ?le system and restores its state; the restart pro- those that are discovered through testing [Lu 2008]. Such cess is completely transparent to applications. Re-FUSE pro- “heisenbugs” [Gray 1987] often appear only in deployment, vides transparent recovery through a combination of novel are hard to reproduce, and can lead to system unavailability techniques, including request tagging, system-call logging, in the form of a crash. and non-interruptible system calls. We tested Re-FUSE with File system crashes are harmful for two primary reasons. three popular FUSE ?le systems: NTFS-3g, SSHFS, and First, when a ?le system crashes, manual intervention is of- AVFS. Through experimentation, we show that Re-FUSE in- ten required to repair any damage and restart the ?le sys- duces little performance overhead and can tolerate a wide tem; thus, crashed ?le systems stay down for noticeable range of ?le-system crashes. More critically, Re-FUSE does stretches of time and decrease availability