Re: Re: [PATCH v6 3/3] fuse: add an implementation of open+getattr

[Horst Birthelmer]

On Mon, Mar 02, 2026 at 09:06:14PM -0800, Darrick J. Wong wrote:
> On Mon, Mar 02, 2026 at 09:03:26PM +0100, Bernd Schubert wrote:
> > On 3/2/26 19:56, Joanne Koong wrote:
> > > On Sat, Feb 28, 2026 at 12:14 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> > >>
> > >> On Fri, Feb 27, 2026 at 10:07:20AM -0800, Joanne Koong wrote:
> > >>> On Fri, Feb 27, 2026 at 9:51 AM Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > >>>>
> > >>>> On Thu, Feb 26, 2026 at 11:48 PM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> > >>>>>
> > >>>>> On Thu, Feb 26, 2026 at 11:12:00AM -0800, Joanne Koong wrote:
> > >>>>>> On Thu, Feb 26, 2026 at 8:43 AM Horst Birthelmer <horst@xxxxxxxxxxxxxx> wrote:
> > >>>>>>>
> > >>>>>>> From: Horst Birthelmer <hbirthelmer@xxxxxxx>
> > >>>>>>>
> > >>>>>>> The discussion about compound commands in fuse was
> > >>>>>>> started over an argument to add a new operation that
> > >>>>>>> will open a file and return its attributes in the same operation.
> > >>>>>>>
> > >>>>>>> Here is a demonstration of that use case with compound commands.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Horst Birthelmer <hbirthelmer@xxxxxxx>
> > >>>>>>> ---
> > >>>>>>>  fs/fuse/file.c   | 111 +++++++++++++++++++++++++++++++++++++++++++++++--------
> > >>>>>>>  fs/fuse/fuse_i.h |   4 +-
> > >>>>>>>  fs/fuse/ioctl.c  |   2 +-
> > >>>>>>>  3 files changed, 99 insertions(+), 18 deletions(-)
> > >>>>>>>
...
> > > 
> > > The overhead for the server to fetch the attributes may be nontrivial
> > > (eg may require stat()). I really don't think we can assume the data
> > > is locally cached somewhere. Why always compound the getattr to the
> > > open instead of only compounding the getattr when the attributes are
> > > actually invalid?
> > > 
> > > But maybe I'm wrong here and this is the preferable way of doing it.
> > > Miklos, could you provide your input on this?
> > 
> > Personally I would see it as change of behavior if out of the sudden
> > open is followed by getattr. In my opinion fuse server needs to make a
> > decision that it wants that. Let's take my favorite sshfs example with a
> > 1s latency - it be very noticeable if open would get slowed down by
> > factor 2.
> 
> I wonder, since O_APPEND writes supposedly reposition the file position
> to i_size before every write, can we enlarge the write reply so that the
> fuse server could tell the client what i_size is supposed to be after
> every write?  Or perhaps add a notification so a network filesystem
> could try to keep the kernel uptodate after another node appends to a
> file?
> 

Bernd already had that idea, that we add an optional getattr to a write
in a compound.
If the fuse server supports it, you would get that data.
I'm really not happy about that idea, since we would have to support 'pages' 
then for the compound.

Regarding the notification. Isn't that doable with the current code already?

> Just my unqualified opinion ;)
> 
> --D
> 
> > Thanks,
> > Bernd

Thanks,
Horst