On Wed, Aug 20, 2025 at 11:40:50AM +0200, Miklos Szeredi wrote: > On Wed, 20 Aug 2025 at 11:16, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > As an optimization of the above, the filesystem clearing the > > request_mask for these uncached attributes means that that attribute > > is not supported by the filesystem and that *can* be cheaply cached > > (e.g. clearing fi->inval_mask). > > Even better: add sx_supported to fuse_init_out, so that unsupported > ones don't generate unnecessary requests. That would work better -- if the fuse server knows it'll never respond to STX_SUBVOL then we could obliterate it from all the statx queries. How does one add a new field to struct fuse_init_out without breaking old libfuse / fuse servers which still have the old fuse_init_out? AFAICT, fuse_send_init sets out_argvar, so fuse_copy_out_args will handle a short reply from old libfuse. But a new libfuse running on an old kernel can't send the kernel what it will think is an oversized init reply, right? So I think we end up having to declare a new flags bit for struct fuse_init_in, and the kernel sets the bit unconditionally. libfuse sends the larger fuse_init_out reply if the new flag bit is set, or the old size if it isn't. Does that sound correct? --D
