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

[Jan Hudec <bulb@ucw.cz>]

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

On Sun, Nov 21, 2004 at 08:42:55 +0100, Miklos Szeredi wrote:
> 
> > Ok, this one works, I agree... But it will be way slower than coda's
> > file-backed approach, right?
> 
> No.  In both cases there will be two memory copies:
> 
>   - from userspace fs to pagecache
>   - from pagecache to read buffer
> 
> And vica versa for write.  FUSE will have some overhead of context
> switches, but in the optimal case (sequential read), the readahead
> code will bundle read requests, and with a 128MByte read, the cost of
> a context switch is probably infinitesimal.

But you won't bundle the *write* requests. And that's what will be
painfuly slow.

Now the file-backed approach is the only that will work for writes
without swapper deadlock.

> > > In the second case there is no deadlock, because the memory subsystem
> > > doesn't wait for data to be written.  If the filesystem refuses to
> > > write back data in a timely manner, memory will get full and OOM
> > > killer will go to work.  Deadlock simply cannot happen.
> > 
> > Hmmm, so if userspace part is swapped out and data is dirtied
> > "too quickly", OOM is practically guaranteed? That is not nice.
> 
> Yeah.  I imagined, that the kernel won't assign all it's free pages to
> file mappings, but people on the list enlightened me to the contrary.
> 
> There seem to be two kinds of solutions:
> 
>   1) make the userspace part aware of the memory allocation problems
> 
>   2) limit the number of pages that can be dirtied

    3) Use a real disk file to back the page cache. Exactly like coda
       does it.

> I don't really like 1) because that really kills the point of
> implementing the filesystem in userspace.
> 
> So I would go along the lines of 2).  However there is no way to know
> when pages are dirtied (ther is no fault), so accounting the dirty
> pages exactly is not possible.  However accounting the _writable_
> pages should be possible with no overhead, since there is a fault when
> the page of a mapping is first touched.
> 
> Limiting these pages for FUSE, would mean that the user could do
> writable mmap, but with the performance penaly of having a limited
> number of pages present in memory.  If the userspace FS refuses to
> write back data, the filesystem user will be blocked until the
> writeback is completed.  No deadlock (hopefully).

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.

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

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