Hi Antonio, I allowed myself to reply to this snip on-list because my answer is relevant to the wider audience. On Fri, Apr 12, 2024 at 8:45 AM Antonio SJ Musumeci <trapexit@xxxxxxxxxx> wrote: > > On Wednesday, April 10th, 2024 at 9:28 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Not sure if that allows you to implement passthrough with mergerfs, > but this is what the kernel implements. > > > Now that I've looked at things more closely I've realized that the passthrough requirements are in conflict with some design assumptions I made in mergerfs. Not that I can't hack around them but certainly isn't as clean as I'd like. Going to need to put critical sections around open and release to ensure no concurrent opens of the same node. > > While considering different ways to take advantage of passthrough it dawned on me that it would have been nice if there was a fh value that was attached to a node on first lookup and could be freed after last forget. That is roughly the plan for the next phase for getattr() passthrough: https://lore.kernel.org/linux-fsdevel/CAOQ4uxgVmG6QGVHEO1u-F3XC_1_sCkP=ekfEZtgeSpsrTkX21w@xxxxxxxxxxxxxx/ Not fh value per-se but a backing id, allocated and attached to fuse inode on LOOKUP reply, which sticks with this inode until evict/forget. OPEN replies on this sort of inode would have to either explicitly state FOPEN_PASSTHROUGH or we can allow the kernel to imply passthrough mode open in this case. Not sure. Sweet Tea said that he will be working on this new API, so now he has another prospective user to test and to validate the design choices. Thanks, Amir.
