[Avf-fuse-dev] interrupted operations

[Steven J. <py...@li...>]

Greetings,

I have given some thought to the situation with interruptible calls and
fuse.

On one hand, it's VERY annoying when an NFS server dies and unkillable
processes pile up on the clients, especially if I have to reboot to flush
them out and get the share unmounted when I know it won't be back for a
while (or don't want it back at all).

On the other hand, it's a real pain that NFS almost meets requirements for
filesystem semantics.

Blue skying a bit here, what about modifying request_wait_answer such that
if wait_event_interruptible IS interrupted:

1. if !req->sent, -ERESTARTSYS
2. if the operation doesn't modify the filesystem (getdir, read,
get/listxattr, etc), -ERESTARTSYS

Those are fairly easy cases. Now, the harder ones:
3. If SIGKILL is pending, -EINTR (and it doesn't matter, the process is as
good as dead).

3a. (optional) a little heavier to compute, but won't happen often:
If any signal is pending which will result in termination (because of
default behaviour and not having a handler set), -EINTR

4. If no fatal signals are pending, just keep waiting in spite of the
signal (which is no worse than the uninterruptible wait happening now).

On the userspace side, the rules become simple, once dequeued, process
until complete.

The advantage is that we keep the library (and filesystems based on it)
simple by not having to support rolling started operations back while
still having the ability to kill processes that get hung up due to
filesystem delays.

G'day,
sjames


||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support