Re: [PATCH] fuse: Add support for fuse stacked I/O

The idea is that you want to be able to reason about open, create, etc. but
don't care about the data transfer.

I have N filesystems I wish to unionize. When I create a new file I want to
pick the drive with the most free space (or some other algo). creat is
called, succeeds, and now the application issuing this starts writing. The
FUSE fs doesn't care about the writes. It just wanted to pick the drive
this file should have been created on. Anything I'd do with the FD after
that I'm happy to short circuit. I don't need to be asked what to do when
fstat'ing this FD or anything which in FUSE hands over the 'fh'. It's just
a file descriptor for me and I'd simply be calling the same function.

Ideally I think one would want to be able to select which functions to
short circuit and maybe even have it so that a short circuited function
could propagate back through FUSE on error. But the read and write short
circuiting is probably the biggest win given the overhead.

On Fri, Jan 15, 2016 at 11:31 AM, Andy Lutomirski [off-list ref]
wrote:

On Jan 14, 2016 11:19 AM, "Linus Torvalds"
[off-list ref] wrote:

quoted

On Thu, Jan 14, 2016 at 10:57 AM, Nikhilesh Reddy [off-list ref]

wrote:

quoted

quoted

*I will send out a properly formatted patch shortly.*

So before you do that, can you explain in what cases fuse just wants
to pass through the IO?

Why aren't such cases just using unionfs or something?

In other words, I think that patch needs an explanation for the
*reason* for the new functionality.

Also, clarifying the functionality would be nice.  What is the
"underlying" fs you speak of?  What f_cred gets used?  Who opens the
underlying file, whatever that is?

Is the intent overlay-style stacking or is it something else entirely?

--Andy