Re: [fuse-devel] Blocking umount

[Werner B. <wer...@on...>]

Am Tue, 08 Jun 2010 10:20:02 -0400
schrieb Nikolaus Rath <Nik...@ra...>:

> I have a file system that caches data locally but the final backend is
> Amazon S3. On umount, the fs needs to upload the cache to S3 which may
> take a while. If umount does not block, the user is left to believe
> that all the data has been written safely while the upload is
> actually still in progress.
> 
> I worked around this problem by writing a custom umount command that
> determines the PID of the mount process by reading from a special
> inode, calls fusermount -u and then waits for the mount process to
> terminate. This works mostly, but is a little bit clumsy and fails
> when the fs is unmounted e.g. by an init script on system shutdown.
> 
> 
> Do you think you'll have the chance to implement this anytime soon?
> 
davfs2, with a WebDAV server as backend, faces the same problem and
also uses an umount helper.
Though support for blocking umount by fuse might make things easier, it
will not solve the problem with init scripts. At least at shutdown they
will not wait forever. After some time they will send SIGTERM and
finally SIGKILL.
What file systems like davfs2 or your S3 file system need to do is this:
When receiving SIGTERM they must clean up and save the local state in a
way that allows to recover when mounted next time.
davfs2 tries it this way:
In addition to the cached files it also saves some metadat on disk.
Whenn unmounted normally it will try to upload dirty files to the
server and write the metadata to disk. When it gets SIGTERM it only
writes the metadata to disk but does not upload dirty files. Instead it
will mark them in the stored metadata. But for large file systems even
writing the metadata might take to much time (though had no report that
this error really happend).
Unfortunately there is no easy way to communicate this to the user, so
the user knows that the local changes are not yet written to the
server. On graphical desktops some kind of popup dialog (e.g. via
dbus) should be possible for this.

Werner