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

Miklos Szeredi
2004-12-15T21:50:23Z

> >No partitioning is needed. If fuse doesn't consume too much memory
> >for dirty data buffers that memory is free to use for other purposes.
> >
> >But fuse would be limited in the number of pages which it can use for
> >dirty buffers exactly to prevent it from causing OOM.
> >
> >
> yes, that will work. wil need to be extra-careful when one fuse is
> loopback-mounted on another.

Since loopback doesn't use shared mapping (I think it uses sendfile)
this isn't a problem for fuse: all non-mmap writes are synchronous,
there'll be no dirty pages (only locked ones), so any allocation by
the userspace filesytem won't deadlock on page reclaim.

I think the solution to the writable mmap problem is also to make
those writes "quasi-synchronous", by not letting too many pages to get
dirty.

> I'm concerned that you're duplicating all the accounting done currently,
> and all of the writeback logic that is dependent on the number of dirty
> pages.

Maybe it can be done without duplication. Since all the memory
reclaim code is based on the "zone" concept, maybe this can be reused.
I don't know how far-feched is the idea of "virtual zones" which
borrow pages from the physical zones, but have their own limits.

> an additional concern is a fuse/non-fuse mix - how do you balance them out?

I wouldn't want to reserve any pages for fuse, only limit the number
of dirtiable pages. That means that if all pages are used up for
non-fuse purposes, that's OK.

> I'm no mmap expert. but doesn't writing to a mmaped page have to
> increase your dirty counter somehow?

For ramfs/tmpfs it doesn't. But I'm not saying that this is the
solution for fuse. This was a purely theoretical idea.

Thanks,
Miklos