On Thu, 21 Sept 2023 at 09:33, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > In my example, the server happens to setup the mapping > of the backing file to inode > *before the first open for read on the inode* > and to teardown the mapping > *after the last close on the inode* (not even last rdonly file close) > but this is an arbitrary implementation choice of the server. Okay. So my question becomes: is this flexibility really needed? I understand the need to set up the mapping on open. I think it also makes sense to set up the mapping on lookup, since then OPEN/RELEASE can be omitted. Removing the mapping at a random point int time might also make sense, because of limitation on the number of open files, but that's debatable. What I'm getting at is that I'd prefer the ioctl to just work one way: register a file and return a ID. Then there would be ways to associate that ID with an inode (in LOOKUP or OPEN) or with an open file (in OPEN). Can you please also remind me why we need the per-open-file mapping mode? I'm sure that we've discussed this, but my brain is like a sieve... Thanks, Miklos
