Re: [fuse-devel] clean mountpoint umount on daemon SIGKILL

[Maxim V. P. <mpa...@pa...>]

Hi Anatol,

04/27/2013 06:47 PM, Anatol Pomozov пишет:
> Hi
>
> On Thu, Dec 13, 2012 at 12:18 AM, Maxim V. Patlasov
> <mpa...@pa...> wrote:
>> Anatol,
>>
>> 12/13/2012 11:28 AM, Nikolaus Rath пишет:
>>
>>> Anatol Pomozov <ana...@pu...>
>>> writes:
>>>> Unfortunately SIGKILL produces another issue - the mountpount is left in
>>>> inconsistent state. libfuse calls umount() in its uninitialization logic
>>>> and SIGKILL does not give any chance to run umount(). But having clean
>>>> unmount even in case of SIGKILL would be really nice to have in fuse.
>>> This is generally not a good idea. Imagine if you run a tool like rsync.
>>> If the source mountpoint suddenly becomes empty, rsync would end up
>>> deleting everything in the destination. If the mountpoint returns an I/O
>>> error instead (as it currently does), rsync can detect the problem and
>>> will instead refuse to do anything.
>>
>> FUSE reconnect can be implemented relatively easy. The idea is to keep
>> kernel fuse queueing requests while user-space is dead and when it restarts,
>> it's being connected to existing kernel fuse_conn. Having this feature
>> implemented, you could SIGKILL deadlocked fuse daemon, then start it again
>> and umount the filesystem cleanly. Will this scheme be helpful for you?
> More I think about fuse transparent reconnect more I like it. In the
> future it will allow to implement stuff like failover (start a new
> daemon in place of the dead/killed one) and hotswap daemon upgrade.
>
> Maxim, have you tied to implement it?

Yes, there are two patches developed by Pavel Emelyanov: one to show 
open files in fusectl, and another to reconnect fuse daemon to an 
existing fuse-connection. I can post them as 'rfc' if you're interested.

> Do you see any issues, in
> particular is it possible to restore daemon state to make filesystem
> client believe it is the same connection?
>

It's depend on fuse daemon. If it's simple enough, re-opening files 
listed in fusectl on restart would work. But any transient userspace 
state not derivable from the list of open files will be the problem. In 
our case, fuse daemon keeps knowledge about last write request that was 
flushed on data server (i.e. we sync storage less often than send 
writes). So after restart the daemon won't be able to recognize whether 
data servers are in consistent state or not.

Thanks,
Maxim