Messages in this thread | | | Date | Sat, 21 May 2005 00:13:12 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] FUSE: don't allow restarting of system calls |
| |
Miklos Szeredi wrote: > This patch removes ability to interrupt and restart operations while > there hasn't been any side-effect. > > The reason: applications. There are some apps it seems that generate > signals at a fast rate. This means, that if the operation cannot make > enough progress between two signals, it will be restarted for ever. > This bug actually manifested itself with 'krusader' trying to open a > file for writing under sshfs. Thanks to Eduard Czimbalmos for the > report.
Caching and prefetching would solve that probem much more usefully.
Does sshfs not cache or prefetch any of the data?
IMHO, caching and prefetching makes a lot of sense for this situation - in fact, it does for any kind of filesystem operation during a sequence of file operations where a program does not use locks (flock etc.), fsyncs, or open/close.
Surely caching and prefetching should be a generic feature of FUSE for all its filesystems unless disabled. Is there a reason why this is not done, or is it just not implemented?
> The problem can be solved just by making open() uninterruptible, > because in this case it was the truncate operation that slowed down > the progress. But it's better to solve this by simply not allowing > interrupts at all (except SIGKILL), because applications don't expect > file operations to be interruptible anyway. As an added bonus the > code is simplified somewhat.
NFS makes file operations interruptible when they're mounted with "intr".
It's a life-saver, when the server or network gets wedged, to be able to Control-C a program instead of it being stuck in D-state and requiring a reboot.
Having a program be stuck in read/write ignoring signals, so that Control-C, Control-Z and kill don't work on it, while it's waiting for some network operation, is a horrible thing.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |