lkml.org 
[lkml]   [2005]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-05-21 01:17    [W:0.041 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site