From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 C13FB2A1BA; Thu, 12 Feb 2026 09:48:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770889733; cv=none; b=qQzeRx+JW2lqpwxxeUKGIdxdJ5+2og9a2oyWaRYnHhLZmB58Qysajw6hScI9jJdRJXk5zgaWyJndBLn/GNwc+CHpejLCZxSOHkyx3H938KS1Ao2WF9y6aDjX5mYntL/pCgiGMCPPImaqBI22++15CVrpxg3v3J9mQ+6vXjyRVTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770889733; c=relaxed/simple; bh=hD0lkAh5BSVhWcPi9b1RpkGwyQbvz/wmvOExF+ZvG4s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=npA8K9cGkNa1IbIfXDPzG/I5YA43CfYp56AFhsa93T+Nrb3TtIwGrWgg/9ngc3c1HrakPV5jZUxaEv5F6ZCIDIbJtgnSPUiyZRu3vRGKbdUwS1A+4DG9/faBG5OUg6p2Z0+2S9w+2DSbq43T6vtFklx76AHSbW5I7cKLGy9vBac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com; spf=pass smtp.mailfrom=bsbernd.com; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b=HrUJudG3; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Yyg7pROo; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b="HrUJudG3"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Yyg7pROo" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 9760C7A009C; Thu, 12 Feb 2026 04:48:50 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 12 Feb 2026 04:48:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsbernd.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770889730; x=1770976130; bh=H7yihoYeRLt0nKbeZEzZZ8rWMnZAbmFXawWreuTtdxE=; b= HrUJudG3ktoltjAL9YTLeOlwkiEnd5rcvyT5GYtV27UaGCo/NASeiuLoaW4fSgyR sfckBHbfSAZY5Mkh5dLURYG2nRtvTbggbc/fzsYIe8bAqx5a7EtAgUPcyTSJqsbM R6HOqNfSy+xi2ZkKmDyvcmM7bcEou/ojAMVdqagBBlIeiinuV3DQSqEYDVx7UWOv K9vCsXI/ncPIfdVHTCwGGYPPUTSock2Woku0uzasklLRAZsbmLU4PetkTS3e12mx WS5QEwcJfRgrU1EeVCndvAa0fgToKVZZR8r0f0jsLaZw5BUJgOAV/Nuls/DaVGrD +ve9NwZ0qh5FDb3WE2vbuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770889730; x= 1770976130; bh=H7yihoYeRLt0nKbeZEzZZ8rWMnZAbmFXawWreuTtdxE=; b=Y yg7pROok4EGodgmLeQANQJE6sk/klTl9ADOUCm3qBMwnZGhkeJs6+IsOKyACFVRy YCnAYNBJO6Y0H4rhM6jABuQ34s8QwinFHraIp4KGpqSoml1bysGIpORAog/PCEQ3 LwIBchN58d7kY2LyHi+YTRQZeMH0q1/4Ii+cRfGWUk+yhXurDzhxbD/Rw1pSjauN hTAM47HbFt8UCfIE2jOG7z/wN+EYlhP+jjSXMmnbaOL65RNHMgngBrPJ6fdbMUti oYAbnt4xKey7m0mmGlHPRcbAOuCWxQPhUrfNDhb7MF4kq+4C12mqrmmZg3QlGh5U o9L4FZzKsqTrlTs0/lQIg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdehtdeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeeuvghrnhgu ucfutghhuhgsvghrthcuoegsvghrnhgusegsshgsvghrnhgurdgtohhmqeenucggtffrrg htthgvrhhnpeehhfejueejleehtdehteefvdfgtdelffeuudejhfehgedufedvhfehueev udeugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsvghrnhgusegsshgsvghrnhgurdgtohhmpdhnsggprhgtphhtthhopeekpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtg hpthhtohephhhorhhsthessghirhhthhgvlhhmvghrrdgtohhmpdhrtghpthhtohepsghs tghhuhgsvghrthesuggunhdrtghomhdprhgtphhtthhopehjohgrnhhnvghlkhhoohhngh esghhmrghilhdrtghomhdprhgtphhtthhopehluhhishesihhgrghlihgrrdgtohhmpdhr tghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpd hrtghpthhtoheplhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhr ghdprhgtphhtthhopehhsghirhhthhgvlhhmvghrseguughnrdgtohhm X-ME-Proxy: Feedback-ID: i5c2e48a5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Feb 2026 04:48:48 -0500 (EST) Message-ID: Date: Thu, 12 Feb 2026 10:48:47 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] fuse: add compound command to combine multiple requests To: Miklos Szeredi Cc: Horst Birthelmer , Bernd Schubert , Joanne Koong , Luis Henriques , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Horst Birthelmer References: <20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@ddn.com> <20260210-fuse-compounds-upstream-v5-1-ea0585f62daa@ddn.com> From: Bernd Schubert Content-Language: en-US, de-DE, fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/12/26 10:07, Miklos Szeredi wrote: > On Wed, 11 Feb 2026 at 21:36, Bernd Schubert wrote: > >> With simple request and a single request per buffer, one can re-use the >> existing buffer for the reply in fuse-server >> >> - write: Do the write operation, then store the result into the io-buffer >> - read: Copy the relatively small header, store the result into the >> io-buffer >> >> - Meta-operations: Same as read > > Reminds me of the header/payload separation in io-uring. > > We could actually do that on the /dev/fuse interface as well, just > never got around to implementing it: first page reserved for > header(s), payload is stored at PAGE_SIZE offset in the supplied > buffer. Yeah, same here, I never came around to that during the past year. > > That doesn't solve the overwriting problem, since in theory we could > have a compound with a READ and a WRITE but in practice we can just > disallow such combinations. > > In fact I'd argue that most/all practical compounds will not even have > a payload and can fit into a page sized buffer. That is what Horst had said as well, until I came up with a use case - write and immediately fetch updated attributes. A bit side tracking background, I disabled auto-invalidate in the DDN file system, because we use DLM anyway (additional patches for background writes and mmap in our branches, should be published to the list asap). And then that disabled auto-invalidation introduced another xfstest failure, I think generic/323, but I would need to look it up. I didn't have time for the details yet, but I think page read beyond EOF. And that made me think that all operations that change file size and time stamps could immediately return the updates attributes, if the file system supports it - with our DLM we would support that. > > So as a first iteration can we just limit compounds to small in/out sizes? Even without write payload, there is still FUSE_NAME_MAX, that can be up to PATH_MAX -1. Let's say there is LOOKUP, CREATE/OPEN, GETATTR. Lookup could take >4K, CREATE/OPEN another 4K. Copying that pro-actively out of the buffer seems a bit overhead? Especially as libfuse needs to iterate over each compound first and figure out the exact size. Thanks, Bernd