From: Nikolaus R. <Nik...@ra...> - 2010-06-09 12:59:30
|
Werner Baumann <werner.baumann-53koH/AXb86i2/dY4...@pu...> writes: > Am Tue, 08 Jun 2010 10:20:02 -0400 > schrieb Nikolaus Rath <Nik...@pu...>: > >> 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? > > 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. That is often true, but I think in contrast to not blocking this cannot be considered a bug in the file system. If you want to umount network file systems on shutdown, you have to configure your system to wait long enough or live with the consequences. > 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. Of course (and I'm already doing that), but I think this is no substitution for a blocking umount. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |