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

[Pavel Machek]

Hi!

> > I know I've asked before... but how is the "fuse-userspace-part
> > swapped out and memory full of dirty data on fuse" deadlock solved?
> 
> By either
> 
>   1) not allowing share writable mappings 
> 
>   2) doing non-blocking asynchronous writepage
> 
> In the first case there will never be dirty data, since normal writes
> go synchronously through the page cache.

Ok, this one works, I agree... But it will be way slower than coda's
file-backed approach, right?

> 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.

What if userspave daemon is not fast enough to handle writes (going
through slow network or something), is there some mechanksm to
throttle back the writer, or will it just OOM?
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/