Re: [PATCH] [Request for inclusion] Filesystem in Userspace

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

On Sun, Nov 21, 2004 at 11:31:58 +0100, Miklos Szeredi wrote:
> > But you won't bundle the *write* requests. And that's what will be
> > painfuly slow.
> 
> Well, painfully slow is just about 100Mbytes/sec on my 1GHz C3
> machine.  Be real.

Measured under what conditions?

> >     3) Use a real disk file to back the page cache. Exactly like coda
> >        does it.
> 
> Yes, that could be done.  Not exactly like coda, because the
> filesystem would have no way of knowing exacty _what_ was written.
> For many applications it's _way_ too inefficient to write back the
> whole file on every little change.  And writing back the file on
> release would mean a) big latency b) inconsistency between the backing
> filesystem and the virtual one.
> 
> Actually latency _is_ the major problem with the CODA like interface.
> Try doing a 'less bigfile' with an sftp filesystem based on CODA and
> FUSE, and you'll see what I mean.  It will _feel_ a hell of a lot
> slower with CODA, just because you'd have to wait for the whole file
> to download to get the first byte.
> 
> > I would not be so sure about this. The deadlock is caused by the fact
> > that such pages may exist, not by their number. Limiting the number will
> > only decrease the probability the deadlock will happen, but won't make
> > it go away.
> 
> No.  The problem _is_ caused by their number, because it will only
> happen if pages cannot be freed in any other way, only by doing
> writeback to the userspace filesystem.  If there are pages which _can_
> be freed other ways, then deadlock won't happen.
> 
> Now if you limit the total number of pages that FUSE can use for
> writable memory mappings to 10% of the total memory in the machine,
> you can be pretty sure, that the remaining 90% will not be filled with
> unpageable memory (otherwise you'd be in pretty big trouble anyway).

There may be only one dirty page in the whole system and it may be the
one backed by FUSE. Now yes, if it was not backed by FUSE, I would be in
trouble -- but the OOM killer would get me out. It will *NOT* get me out
with fuse, because it thinks the page will be cleaned, which it won't.

Thus by limiting the numeber of pages, you decrease the probability that
the deadlock will happen. You may even get to reasonably small numbers.
But you can't get to 0. The deadlock will still be there, it will just
be unlikely.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]