Disk sync at shutdown and fusefs filesystems

[Csaba Henk]

On 2007-12-17, Alejandro Pulver <alepulver at FreeBSD.org> wrote:
> When the implementation is ready, and if these problems are sorted out,
> do you think it could be enabled by default (at least for root)? Because
> that's the behavior most filesystems would prefer I think.

I made up a testable implementation, see it here:

http://mercurial.creo.hu/repos/fuse4bsd-hg-experimental/?rev/abc018d9f535

It seems to work fine. In order to have a fuse daemon which is
"malicious", ie. tries to stall shutdown, I hacked fusexmp_fh.c as
follows:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- /dispatch/root/fuse-2.7.0/example/fusexmp_fh.c	2007-05-20 13:05:43.000000000 +0200
+++ fusexmp_fh.c	2008-01-03 02:47:00.000000000 +0100
@@ -416,6 +416,17 @@ static int xmp_lock(const char *path, st
                        sizeof(fi->lock_owner));
 }
 
+static void xmp_destroy(void *foo)
+{
+	unsigned i = 0;
+
+	for(;;) {
+		fprintf(stderr, "%d ", i++);
+		sleep(1);
+	}
+}
+
+
 static struct fuse_operations xmp_oper = {
     .getattr	= xmp_getattr,
     .fgetattr	= xmp_fgetattr,
@@ -451,6 +462,7 @@ static struct fuse_operations xmp_oper =
     .removexattr= xmp_removexattr,
 #endif
     .lock	= xmp_lock,
+    .destroy	= xmp_destroy,
 };
 
 int main(int argc, char *argv[])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

shutdown(8) was able to complete. The above hack could only cause a ten second
delay -- see the output of the daemon:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
unique: 0, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.8
flags=0x00000000
max_readahead=0x00000000
   INIT: 7.8
   flags=0x00000002
   max_readahead=0x00000000
   max_write=0x00020000
   unique: 0, error: 0 (Unknown error: 0), outsize: 40
0 1 2 3 4 5 6 7 8 9 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

So FreeBSD's shutdown handles this fine, the system can't really be
DoS'd this way.

Therefore we don't need a too strict access policy. I think that from
our POV, it would be sufficient to add a "-osync_unmount" mount option
and a sysctl via which it's availability for unpriviliged users can be
set.  But life is not that simple: if we added such a mount opt that
would remain FreeBSD specific (on Linux it won't happen, for reasons I
don't want to digress on here), and therefore filesystem authors -- who
usually use fuse options internally -- won't use it; although they are
the authorative persons whether their filesystems needs to have a
sychronized unmount or not.  I'll try to find the fine middle ground
with Miklos with respect to this.

So while the interface to this feature is under construction, you can
already play with it and I'd like to know about your experiences.

This can be done as follows:

 - Get the experimental version of fuse4bsd from the above mentioned
   URL. (More exactly, the above URL shows the cset which brings in
   the current implementation; if you want to get the latest of
   this branch, use

   hg {clone,pull} -r sync_unmount0 http://mercurial.creo.hu/repos/fuse4bsd-hg-experimental

   or

   fetch http://mercurial.creo.hu/repos/fuse4bsd-hg-experimental/?archive/sync_unmount0.tar.gz

   As of the time of writing this, abc018d9f535 and sync_unmount0 refer to
   the same revision.)

 - Compile it with the CFLAG -DFUSE_HAS_DESTROY=1 (the proto version
   hasn't been bumped when DESTROY was added, so I can't figure it
   out if DESTROY is available; you have to pass this setting
   manually). (Apart from loading the kld, don't forget to use the
   mount_fusefs(8) binary compiled from this code!)

 - Recompile fusefs-libs using the following revision of
   lib/mount_bsd.c:

   http://fuse.cvs.sourceforge.net/*checkout*/fuse/fuse/lib/mount_bsd.c?revision=1.14

   (this includes the patch
   http://fuse.cvs.sourceforge.net/fuse/fuse/lib/mount_bsd.c?r1=1.13&r2=1.14
   which fixes a bug referred to in this thread as "issue 2").

 - Go wild with your experiments. ATM the easiest way to enable sync unmount
   is adding MOUNT_FUSEFS_SYNC_UNMOUNT=1 to the environment. (Making it
   settable via the environment lets us leave the lib/fs code intact.)
   ATM sync unmount is available without restrictions.

Have fun,
Csaba