Date: Thu, 3 Jan 2008 15:27:56 +0000 (UTC) From: Csaba Henk <csaba-ml@creo.hu> To: freebsd-hackers@freebsd.org Subject: Re: Disk sync at shutdown and fusefs filesystems Message-ID: <slrnfnpvmg.i6j.csaba-ml@beastie.creo.hu> References: <20071211001828.54e1da6b@deimos.mars.bsd> <slrnflug57.i6j.csaba-ml@beastie.creo.hu> <20071212134316.3d65f102@deimos.mars.bsd> <slrnfmbjph.i6j.csaba-ml@beastie.creo.hu> <20071216232655.5d829d41@deimos.mars.bsd> <slrnfmd9lc.i6j.csaba-ml@beastie.creo.hu> <20071217141504.1f3d8932@deimos.mars.bsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-12-17, Alejandro Pulver <alepulver@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnfnpvmg.i6j.csaba-ml>