Hi Amir, Thank you for your detailed reply. My intent with this patch was to see if there was interest (a definite yes) and to see what path would best get us to our common goal. I'm thinking the best approach is to start with your ops_mask API. In fact, that solves the biggest single problem with my future patch set, which was that it was going to be huge and not realistically divisible, since you need everything for directory passthrough to work without the mask. Your way allows us to proceed in nice logical steps, which is much, much better. Thank you for that suggestion. So my follow-up question is: What can I do to help get the foundational patches you wrote upstreamed? In the meantime, a few thoughts on your comments. (Note that one of the beauties of your suggestion is that we don't need to agree on any of this to get started - we can discuss them in detail when we get to the specific ops that require them.) 1) Yes, let's use backing_id. I won't mention that again. 2) The backing path per dentry comes from the way dentry_open works. If we are going to attach a file to a lookup, we have to put something into the fuse_dentry or the fuse_inode. This makes more sense once you see points 3 & 4 below - without them, we have an open file, so why not just use it? 3) A cute idea that we had that seems to work is to allow negative dentries as backing dentries. It appears to work well - for instance, a create first looks up the (negative) dentry then creates the file into that dentry. If the lookup puts a negative dentry as the backing file, we can now just use vfs_create to create the backing file. This means that only FUSE_LOOKUP and (I think) FUSE_READDIRPLUS need to have the ability to accept backing_ids. I think is is both more elegant conceptually, simpler to code in the kernel *and* simpler to use in the daemon. 4) Having to open a file for it to be passed into a lookup is problematic. Imagine readdirplus on a large folder. We would need to open every single backing file, and it would stay open until the dentry was removed from the cache. Both of these suggest that rather than just passing a backing_id to FUSE_LOOKUP and FUSE_READDIRPLUS we should be able to pass a backing_id and a relative path. This is where the idea of putting the backing path into the fuse dentry comes from. I don't *think* this creates any security issues, so long as the relative path is traversed in the context of the daemon. (We might want to ban '..' and traverses over file systems.) Again, these are details we can debate when the patches are ready for discussion. But again, let's start with your patch set. What are the next steps in taking it upstream? And which are the next ops you would like to see implemented? I would be happy to take a stab at one or two. Paul
