From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 622F5241678; Wed, 12 Mar 2025 13:54:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741787691; cv=none; b=aRb558i7/Bn3OeHy6doGwz9bQHnvy7DlTXQyJn7YBaNP0Scn3zAHVeJ8Xiufwx9t3EclXxx3lxJOCntXLyNVhcWPYcYZycU8ssD+tPk0T00Q2OyhnGfWCIFuANvXsiOZvT54d6Ixnr/Pdw8ZAuPbfUMQjdJmpuTez3uWh1fRAdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741787691; c=relaxed/simple; bh=s7HppErOuRAEfWoZvC9h8SjPc+omLVLEhgLC3zn/b5g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qUsmCd+IsB66Mb5k2gO5DquCGsvigUmRnyYF0iRh3o8tWA1ff6bsECZ4haLVu24Pd/ztiPJK7Foh/BkSzRALaarowNWzDCHljQDwo9OnXnCR2tlDmVNYyqVgM4s/NN9qJNGAvF3N1MTX/pfdCJCmWjwAWlGecQ4CJTGGiSzRfyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=HfhH08SS; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="HfhH08SS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=lfneeWODElFymFhQnucV3WL3Lau0GPYLjMhVhcnqKW8=; b=HfhH08SSMP3zY3OeXVKlQ3ZbtD ASMEE5hDn5masctrOVgF4cgC5EpNYAB77QksrAgCFHdpJzMsbHkTTMUM6FwdzJmiss4zMryqtPdQB xojhyVY1j+DMG870wbf+qKWdUh0W57WSV9F3/c4VkIcapXkB0QvTkNqnHFyKfhIolGZDS2MEq0Z9J t2NbIASiMHHmR/lIQzzMN0rW4BA+67yGNabsnUopfPZLcHt9jEFr2PZSlMe/gz39DoHjsSW1mS+mo Tlj1lWHOH3I2o8qgH0N35ZlkI+5ynaSPoAI7Na9ex7Ju3EHr5fbxZCjQtyaUFP2M7AOE59OpOG5Rn +tjZnE9w==; Received: from hch by bombadil.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tsMXp-00000008d2W-415a; Wed, 12 Mar 2025 13:54:49 +0000 Date: Wed, 12 Mar 2025 06:54:49 -0700 From: Christoph Hellwig To: John Garry Cc: Christoph Hellwig , brauner@kernel.org, djwong@kernel.org, cem@kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com, ritesh.list@gmail.com, martin.petersen@oracle.com Subject: Re: [PATCH v5 07/10] xfs: Commit CoW-based atomic writes atomically Message-ID: References: <20250310183946.932054-1-john.g.garry@oracle.com> <20250310183946.932054-8-john.g.garry@oracle.com> <63587581-17a5-431e-9fe3-a1a24ea4fa21@oracle.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=us-ascii Content-Disposition: inline In-Reply-To: <63587581-17a5-431e-9fe3-a1a24ea4fa21@oracle.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Mar 12, 2025 at 09:04:07AM +0000, John Garry wrote: > > As already mentioned in a previous reply: "all" might be to much. > > The code can only support a (relatively low) number of extents > > in a single transaction safely. > > Then we would need to limit the awu max to whatever can be guaranteed > (to fit). Yes. And please add a testcase that creates a badly fragmented file and verifies that we can handle the worst case for this limit. (although being able to reproduce the worst case btree splits might be hard, but at least the worst case fragmentation should be doable) > > Assuming we could actually to the multi extent per transaction > > commit safely, what would be the reason to not always do it? > > > > Yes, I suppose that it could always be used. I would suggest that as a later > improvement, if you agree. I remember running into some problems with my earlier version, but I'd have to dig into it. Maybe it will resurface with the above testing, or it was due to my optimizations for the extent lookups.