On Wed, 20 Sept 2023 at 15:57, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Unlike Alession's version, this implementation uses the explicit ioctl > flag FUSE_BACKING_MAP_ID to setup an "inode unbound" backing file > and the explicit open flag FOPEN_PASSTHROUGH_AUTO_CLOSE > to unmap the backing id, when the backing file is assigned to the fuse file. That sounds about right. I'm not sure the flexibility provided by the auto/noauto mode is really needed, but taking this out later in the development process shouldn't be a problem. > > FOPEN_PASSTHROUGH (without AUTO_CLOSE) would let the server > manage the backing ids, but that mode is not implemented in the example. > > The seconds passthrough_hp commit: > - Enable passthrough of multiple fuse files to the same backing file > > Maps all the rdonly FUSE files to the same "inode bound" backing > file that is setup on the first rdonly open of an inode. > The implementation uses the ioctl flag FUSE_BACKING_MAP_INODE > and the open flag FOPEN_PASSTHROUGH (AUTO_CLOSE not > supported in this mode). I think the natural interface would be to setup the inode mapping in the lookup reply (using the normal backing ID). With your current method, what's the good time for establishing the mapping? After the lookup succeeded, obviously. But then it might already have raced with open... > > The "inode bound" shared backing file is released of inode evict > of course, but the example explicitly unmaps the inode bound > backing file on close of the last open file of an inode. > > Writable files still use the per-open unmap-on-release mode. What's the reason for using different modes on different types of opens? Thanks, Miklos
