I spent a little time with these patches. I wrote my own to set the backing file at lookup time by adding an optional second out struct. Is there a reason we should not do this? It seems the most natural solution. After a while, I began to wonder if what I was planning was actually the same as your vision. I decided to jot down my thoughts to see if you agree with them. Also I was confused as to why you were adding the ability to set backing files to GETATTR. So here are my notes. Design of fuse passthrough for all operations Goal: When a fuse filesystem implements a stacking filesystem over an underlying file system, and a significant fraction of the calls will simply be passed to the underlying file system, provide a mechanism to pass those calls through without going to user space. This is primarily to enhance performance, though it might simplify the daemon somewhat too. Current state: Currently passthrough allows a backing file to be set at file open time. If a backing file is set, all read/write operations will be forwarded to the backing file. Design: Add ability to set backing file on the found inode in response to a positive lookup. This file might be opened with O_PATH for performance reasons. The lookup api would be modified to have an optional second out struct that contains the backing file id. Note that we will use the backing file ioctl to create this id to remove any security concerns. The ioctl will also take a 64-bit integer to define which operations will be passed through, the operations mask. This will have one bit for each of the existing FUSE_OPERATIONS, at least the ones that act on inodes/files. Then when fuse fs is considering calling out to the daemon with an opcode, fuse fs will check if the inode has a backing file and mask. If it does, and the specific opcode bit is set, fuse fs will instead call out to a kernel function in backing.c that can perform that operation on the backing file correctly. Details: Question: Will it be possible to change the mask/backing file after the initial setting? My feeling is that it might well be useful to be able to set the mask, the file not so much. Situations would be (for example) a caching file system that turns off read forwarding once the whole file is downloaded. FUSE_OPEN will, if the backing file has been set, reopen it as a file (not a path) if needed. This is whether or not FUSE_OPEN is passed through. If FUSE_OPEN is passed through, user space will not get the chance to assign a file handle ID to the opened file. It will still be possible to pass FUSE_READ etc to the daemon - the daemon will still have the node id and be able to read data based on that. FUSE_LOOKUP can return a 0 node id, but only if *all* operations on that node as marked as passthrough. Suggestion: During FUSE_LOOKUP, if FUSE_GETATTR is set in the mask, ignore the passed in attributes and read them from the backing file. Random, non-exhastive list of considerations: FUSE_FORGET can only be marked passthrough if the node id is 0. FUSE_CREATE returns a new node id and file handle. It would need the ability to set backing files. If FUSE_LOOKUP is marked for passthrough, then looked up inodes will be prepopulated with a backing O_PATH file and a mask will all bits set. FUSE_RENAME takes two nodes and names, and moves one to the other. If one is passthrough and one is not, there is no obvious way of performing a rename. Either fall back to copy/delete or return EXDEV
