From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp02-ext3.udag.de (smtp02-ext3.udag.de [62.146.106.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B89133B71B3 for ; Fri, 5 Jun 2026 09:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.146.106.33 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780651716; cv=none; b=CLV+n6UIONfb46/iR8BW5UM54s6NsnuS1bDAWat0xqVlH2yxwItz4u+0m4GTuC0evFI110XOVTVoptedKztY6EVZqTep1l0lwBxWkvnjsjlrQUU1XHKwcMYu+4nZbJRsRy6Q8xxUVPWIk0+t2AOodygAi80T1GvEV1S2ld1w0lI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780651716; c=relaxed/simple; bh=p3Crr8QYVZKz9ODWCw7ilty4PbjLo1138MwpMaPmhsk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uTmqiiWTp1fKrtHlZnNn13XH+mxOzIrRncOlUINJCk5+SCrbRF3iG8pzd4+KskDQFmgm62J30HqH6Gp438qGZVuqPpKxwUl9bLUd9r8xcN/e4o2VCizA4arOaVlGwlm3HXYTrzzzHFFDKwt3zmSL6RIlHpXW4scYkRiLYN2IE0Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de; spf=pass smtp.mailfrom=birthelmer.de; arc=none smtp.client-ip=62.146.106.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=birthelmer.de Received: from localhost (065-142-067-156.ip-addr.inexio.net [156.67.142.65]) by smtp02-ext3.udag.de (Postfix) with ESMTPA id C648BE0392; Fri, 5 Jun 2026 11:28:30 +0200 (CEST) Authentication-Results: smtp02-ext3.udag.de; auth=pass smtp.auth=birthelmercom-0001 smtp.mailfrom=horst@birthelmer.de Date: Fri, 5 Jun 2026 11:28:30 +0200 From: Horst Birthelmer To: Amir Goldstein Cc: Horst Birthelmer , Miklos Szeredi , Bernd Schubert , Joanne Koong , Luis Henriques , linux-kernel@vger.kernel.org, fuse-devel@lists.linux.dev, Horst Birthelmer Subject: Re: Re: Re: [PATCH v7 0/4] fuse: compound commands Message-ID: References: <20260604-fuse-compounds-upstream-v7-0-27331d085c2a@ddn.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jun 05, 2026 at 11:15:03AM +0200, Amir Goldstein wrote: > On Fri, Jun 5, 2026 at 10:49 AM Horst Birthelmer wrote: > > > > On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote: > > > On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer wrote: > > > > > > > > This series adds a single new opcode, FUSE_COMPOUND, that bundles a > > > > sequence of subrequests into one round trip. The wire format is > > > > > > > > fuse_in_header (opcode FUSE_COMPOUND) > > > > fuse_compound_in > > > > fuse_compound_req_in > > > > fuse_in_header > > > > payload > > > > ... (repeated per subop) > > > > > > > > Compound is opt-in per connection and discovered by trial: the kernel > > > > assumes support and clears its flag on the first -ENOSYS reply. > > > > -EOPNOTSUPP declines a specific combination without disabling the > > > > feature. In both cases the kernel replays the subops individually > > > > via fuse_simple_request(), so callers never need a separate > > > > non-compound code path. > > > > > > > > The series ships two consumers: > > > > > > > > - open + getattr, used when fuse_file_open() needs both ff->fh and > > > > fresh attrs (O_APPEND, or cached attrs already stale). This > > > > closes the open-then-stat race described in [1]. > > > > - dentry revalidate, fusing LOOKUP + GETATTR when both the entry > > > > and the attribute caches are stale. > > > > > > I am not sure if the intention for fusex is to carry over or phase out GETATTR > > > in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND > > > should or should not be added to current FUSE protocol, we need to answer the > > > more concrete question: > > > > > > Is FUSE_COMPOUND intended to improve existing unmodified servers > > > which link with newer libfuse and run on a newer kernel? > > > > > > If not, then maybe we should start with OPEN/LOOKUP + STATX > > > from the start. > > > > To your first question about phase out of GETATTR, I don't think so, > > since fusex will use the same opcodes, so it will be there and we will > > have to fall back IMHO. > > > > I have told this to a couple of people I have talked to about fusex > > I would actually favor to negotiate supported opcodes and features in fusex > > and adjust and overwrite the write operations accordingly. This of course is > > miles away from the current state. > > > > I don't think compounds will do anything for fuse servers that do not support it > > and that don't have special cases that could be made faster when basically knowing > > on a semantical level what the kernel actually wants (this is like some sort of > > lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are > > sending is most likely followed by the CREATE right down below ... but the fuse > > server cannot know that unless the kernel tells it) > > > > It could have been when the compound handling of not supported operations would > > have been in libfuse (which theoretically it still is), then you will save > > user/kernel space switches, but when the kernel has to step in to do the 'legacy' > > calls you actually will lose that intial try, where the fuse server tells you > > ENOSYS or EOPNOTSUP. > > > > So when linked with a not yet existing new libfuse, we could get faster due to the > > lesser switches to user space. Do you think that answers your initial question? > > > > I actually have an implementation of the atomic open (this is counter productive > > for upstream, but I'm using it here as a concrete example to calrify the more general > > point) and since our fuse server can do the atomic open way more efficiently > > (everybody knows by now that distributed locks cost you performance) > > I get 15%-20% more performance on metadataa tests. > > > > The definitve answer here is probably somewhere around 'your milage may vary'. > > I'm really interested in further discussion about this ... and your opinion here. > > Would you want to use compounds for some case? > > No, I do not have any use cases for compounds that I am aware of. > > Compounds of READDIR+STATX was discussed as an technical alternative > to READDIRPLUS2 which would need to return backing_ids, but I am still > if this direction is worth pursuing. > > > > > BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it? > > > > Yes, I was asking whether FUSE_STATX is expected to supersede > FUSE_GETATTR in fusex. I don't know that answer. I would support that idea, if it was up to me. Fortunately it's not ;-) > > Thanks, > Amir. Thanks, Horst