[Portland] PortlandVFSProposal

[Dmitry M. Shatrov]

07/01/2006 23:04 +0100, nf2: 
> Diego Calleja wrote:
> I believe with FUSE many applications need to be rewritten as well, 
> because they don't expect the filesystem to be slow. With FUSE you have 
> to move all your file-operations (even a "stat" call) out of the 
> GUI-thread, because they might block for a very long time. I'd reckon 
> not all applications do that. Thus the implications of migrating to FUSE 
> or the Common-VFS are actually very similar.

An application expecting accidental filesystem lockup is several times
more complicated, nobody cares at the moment. My experience with GNOME
apps shows that they still hang on stale network resources. They did and
they will. Any application-side solution will be based on either
read/write timeouts or separate I/O threads. A simple proof of guess
what:

1. Let's take multithreading as a right solution
2. Provided that VFS should provide consistent access to any local or
remote resource we conclude that an application should consider each
file as possibly a remote one.
3. Proper handling of local files is a subset of proper handling of
remote files.
4. (2) and (3) gives that any application should treat any file as a
remote one
5. CONCLUSION from (1): any application working with files should be
multithreaded

7. Requiring all applications to be multithreaded is a nonsense and of
course implies rewriting most if not all of existent desktop
applications.

6. That means that timeouts should be used to protect from hang-ups on
remote files.

The most proper place to implement timeouts is the code of the file
system itself. What should be done is making FUSE-based network
filesystems code to include proper timeouts.

These timeouts could be customizable if it matters. A movie player could
require 'gui-wise' timeouts (2-4 seconds): if a timeout is hit user sees
a dialog box: "stop playback/retry". Other applications may require
'data-integrity-wise' timeout policy and become multithreaded if it
worths. These customizable timeouts could be exposed through ioctl's on
the files themselves. The default network timeout policy setting could
be selected through a /proc enty on system startup: 'gui-wise' for a
desktop of course.