From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp03-ext2.udag.de (smtp03-ext2.udag.de [62.146.106.30]) (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 2AAC4224AF1; Fri, 27 Feb 2026 07:59:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.146.106.30 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772179156; cv=none; b=N80yYmTaC5c2x4hvUmDm8BOANbBzq87l9iYlCdrgNsy/tD7j84UckRrRT0gOf9q7bUdVSR7ON4z4dzU8Ah+9/mlxgnEinB7sOXOEZIzCklCZ6rbyUT+OP9O/LcjLjMt/dwOFClaBoxvNdF4KbyMCiIadp8e83DTX7SlOjmShxJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772179156; c=relaxed/simple; bh=bmau9RDs3mDfOg2ffgizp4vABJGxgaSC65euswtDGis=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UEWhIS5WWRJdyfqv79fjMgi54za7uuq1o6IYP+3XKoKgD1Fd+FgAr3Lefc2M9CyPFm8b9oOL0DLAHfvwCp0mKPRfxOn51i2EAu7StS82pvF7twGji4MlzldtDB5YTvjQQk042CfIOmi+HztRF8xIk4FjSCCFbR+b8RjhO5eGNXU= 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.30 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 (200-143-067-156.ip-addr.inexio.net [156.67.143.200]) by smtp03-ext2.udag.de (Postfix) with ESMTPA id 7E4D1E02DD; Fri, 27 Feb 2026 08:59:12 +0100 (CET) Authentication-Results: smtp03-ext2.udag.de; auth=pass smtp.auth=birthelmercom-0001 smtp.mailfrom=horst@birthelmer.de Date: Fri, 27 Feb 2026 08:59:11 +0100 From: Horst Birthelmer To: Jim Harris Cc: Miklos Szeredi , Bernd Schubert , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Max Gurtovoy , Konrad Sztyber , Luis Henriques Subject: Re: Re: [PATCH] fuse: skip lookup during atomic_open() when O_CREAT is set Message-ID: References: <20260220204102.21317-1-jiharris@nvidia.com> <6D884659-21B7-438D-8323-477EA22ACD43@nvidia.com> Precedence: bulk X-Mailing-List: linux-fsdevel@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: <6D884659-21B7-438D-8323-477EA22ACD43@nvidia.com> On Thu, Feb 26, 2026 at 11:11:22PM +0000, Jim Harris wrote: > > > > On Feb 24, 2026, at 8:33 AM, Miklos Szeredi wrote: > > > > External email: Use caution opening links or attachments > > > > > > On Mon, 23 Feb 2026 at 19:55, Horst Birthelmer wrote: > > > >> What is wrong with a compound doing LOOKUP + MKNOD + OPEN? > >> If the fuse server knows how to process that 'group' atomically > >> in one big step it will do the right thing, > >> if not, we will call those in series and sort out the data > >> in kernel afterwards. > >> > >> If we preserve all flags and the real results we can do pretty > >> much exactly the same thing that is done at the moment with just > >> one call to user space. > >> > >> That was actually what I was experimenting with. > >> > >> The MKNOD in the middle is optional depending on the O_CREAT flag. > > > > Okay, I won't stop you experimenting. > > > > My thinking is that it's simpler as a separate op (dir handle and name > > are the same for LOOKUP and MKNOD). But adding this special "stop if > > error or non-regular, else skip create if positive" dependency would > > also work. > > > > Thanks, > > Miklos > > Thanks for the feedback everyone. Sounds like compounds will be the way forward to optimize this path, once they are ready. > > Do we think compounds will be land for 7.1? Or later? I honestly have no idea. I'm going as fast as I can. BTW, the post you are responding to, wasn't meant to reject the patch IMHO, but the change in behavior could actually become a real problem. I have the same fear for the compound of open+getattr, which actually solves a bug, but could be trouble for people making the wrong assumptions in their fuse servers. > > Best regards, > > Jim > Cheers, Horst