On Mon, 28 Apr 2025 at 21:00, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > <nod> I don't know what Miklos' opinion is about having multiple > fusecmds that do similar things -- on the one hand keeping yours and my > efforts separate explodes the amount of userspace abi that everyone must > maintain, but on the other hand it then doesn't couple our projects > together, which might be a good thing if it turns out that our domain > models are /really/ actually quite different. Sharing the interface at least would definitely be worthwhile, as there does not seem to be a great deal of difference between the generic one and the famfs specific one. Only implementing part of the functionality that the generic one provides would be fine. > (Especially because I suspect that interleaving is the norm for memory, > whereas we try to avoid that for disk filesystems.) So interleaved extents are just like normal ones except they repeat, right? What about adding a special "repeat last N extent descriptions" type of extent? > > But the current implementation does not contemplate partially cached fmaps. > > > > Adding notification could address revoking them post-haste (is that why > > you're thinking about notifications? And if not can you elaborate on what > > you're after there?). > > Yeah, invalidating the mapping cache at random places. If, say, you > implement a clustered filesystem with iomap, the metadata server could > inform the fuse server on the local node that a certain range of inode X > has been written to, at which point you need to revoke any local leases, > invalidate the pagecache, and invalidate the iomapping cache to force > the client to requery the server. > > Or if your fuse server wants to implement its own weird operations (e.g. > XFS EXCHANGE-RANGE) this would make that possible without needing to > add a bunch of code to fs/fuse/ for the benefit of a single fuse driver. Wouldn't existing invalidation framework be sufficient? Thanks, Miklos
