On 8/21/24 16:28, Miklos Szeredi wrote: > On Tue, 20 Aug 2024 at 23:18, Bernd Schubert <bschubert@xxxxxxx> wrote: >> >> This is to update attributes on open to achieve close-to-open >> coherency even if an inode has a attribute cache timeout. >> >> Signed-off-by: Bernd Schubert <bschubert@xxxxxxx> >> >> --- >> libfuse patch: >> https://github.com/libfuse/libfuse/pull/1020 >> (FUSE_OPENDIR_GETATTR still missing at time of writing) >> >> Note: This does not make use of existing atomic-open patches >> as these are more complex than two new opcodes for open-getattr. > > The format of the requests would be very similar to the atomic open ones, right? Atomic open patches are using fuse_open_out + fuse_entry_out open-getattr is using fuse_open_out + attr_outarg We could switch open-getattr to the atomic-open format, but then need to introduce a flag to tell fuse-server that this is a plain atomic and much simpler than atomic-open (atomic-open is also on the server side rather complex). For open-getattr we need don't need to revalidate the entry with all the fields provided by fuse_entry_out. Fine with me if you prefer a new struct to be used by atomic-open and open-getattr with a flag and padding. Like enum atomic_open_flags { ATOMIC_OPEN_IS_OPEN_GETATTR = 1ULL < 0; }; struct atomic_open { uint64_t atomic_open_flags; struct fuse_open_out open_out; uint8_t future_padding1[16]; struct fuse_entry_out entry_out; uint8_t future_padding2[16]; } What do you think? Thanks, Bernd
