Re: [fuse-devel] mmap & running out of file descriptors

[Miklos S. <mi...@sz...>]

On Tue, Aug 27, 2013 at 3:40 PM, Mike Shal <ma...@gm...> wrote:

> Thanks for the suggestion. I tried setting RLIMIT_NOFILE to the max
> available (so, it was upped from 1024 to 4096), but gold still blows
> through all 4096 descriptors (it's a very large linking command).

As root I got 2^20 fd's  You could consider starting as root and
dropping privs after having set the limit.

> Since it runs correctly through fusexmp, I tried changing from the
> fusexmp_fh style to the fusexmp style (ie: on a read call, do
> open()/read()/close() instead of caching the fd in fi->fh). Unfortunately,
> performance suffered when doing so.
>
> I was able to get it working without too much of a performance penalty by
> combining fusexmp style accesses with Nikolaus' suggestion of per-process
> fd limits. So the first N file descriptors for a process use fi->fh, and if
> it tries to open more, I just set fi->fh to 0 and close the fd. The read
> callback then checks if fi->fh is 0, and does the open()/read()/close() in
> that case. Otherwise it can just use fi->fh directly (similar for write
> calls).
>
> The other thing I've found that works is Matt's passthrough patch:
> http://fuse.996288.n3.nabble.com/quot-Passthrough-quot-file-descriptor-patch-td8002.html
>
> (My passthrough patch is apparently buggy, so it didn't work here).
>
> Matt's patch allowed me to call fuse_set_pass_fd() in the open call, and
> then close the fd in my fuse fs. So even if gold runs out of fds, I don't
> also run out of fds in fuse (without resorting to fusexmp style accesses).
> Not to mention the fact that passthrough fds are the only way (that I'm
> aware of) to get FUSE performance close to that of the native filesystem.
>
> Can we please reconsider getting an official passthrough implementation?
> What is preventing us from doing so?

The thing is, it's a bloody hack.  It's a simple and effective one,
I'm not arguing that, but a hack nonetheless.

I'd like to see people making an effort at extracting the most
performance from the current, less hacky, interfaces and if after that
we are still not close to the passthrough performance, then okay.

Going down the path of accepting interface hacks for the sake of
performance is questionable.  Yes, maybe this one is worth it but then
people will complain that they want parts of files mapped by the
kernel, etc...  That way lies chaos.

Your usecase is special and one that I haven't yet heard.  But then is
passthough the only solution to that?

Thanks,
Miklos