From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5785C4332F for ; Tue, 12 Dec 2023 15:19:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376647AbjLLPTA (ORCPT ); Tue, 12 Dec 2023 10:19:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376636AbjLLPS7 (ORCPT ); Tue, 12 Dec 2023 10:18:59 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7F8BF3; Tue, 12 Dec 2023 07:19:04 -0800 (PST) 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=hJFVEyxAqaTyWKn0xSoqtwuxX6IerRG8qVGzGaggA8w=; b=eVfUKNx7/zwo0Jk2745c8DeHo7 jfdzDxn3mUmUlDnLLxBVOcyh2AwO1sarWBBQ3lZ0oVuNEwQkVEFl5cl0ug7S5ZnP2S8Gjy8/vMHO5 yiwOgVoZglwFhIkNpijSLvb6/eZS6Ra2SZdHovI6kYsvtHLuBh/4nRswsA04x3YNKZ8GklgBiUxNP XPfJx7dYDDO7OekU/2bEJjDJhNXxmnrwrgnAXftScECU4kXCjj18edbJCSo13/rerkQ7+CodIy33Z iloe7U278Oi8ZvdZg9v4rxyYR/S8ouHhc2lCnYMe+nF8dsJ+jAkhwvFNPG/kzRrReBWxJ1YAqCil7 PhskmXsQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1rD4XG-00C1V5-06; Tue, 12 Dec 2023 15:19:02 +0000 Date: Tue, 12 Dec 2023 07:19:02 -0800 From: Christoph Hellwig To: Theodore Ts'o Cc: Christoph Hellwig , John Garry , Ojaswin Mujoo , linux-ext4@vger.kernel.org, Ritesh Harjani , linux-kernel@vger.kernel.org, "Darrick J . Wong" , linux-block@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, dchinner@redhat.com Subject: Re: [RFC 0/7] ext4: Allocator changes for atomic write support with DIO Message-ID: References: <8c06c139-f994-442b-925e-e177ef2c5adb@oracle.com> <20231212151613.GA142380@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231212151613.GA142380@mit.edu> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 12, 2023 at 10:16:13AM -0500, Theodore Ts'o wrote: > On Tue, Dec 12, 2023 at 05:10:42AM -0800, Christoph Hellwig wrote: > > On Tue, Dec 12, 2023 at 07:46:51AM +0000, John Garry wrote: > > > It is assumed that the user will fallocate/dd the complete file before > > > issuing atomic writes, and we will have extent alignment and length as > > > required. > > > > I don't think that's a long time maintainable usage model. > > For databases that are trying to use this to significantly improve > their performance by eliminating double writes, the allocation and > writes are being done by a single process. So for *that* use case, it > is quite maintainable. That's not the freaking point. We need to have proper kernel interfaces that don't rely on intimate knowledge and control of details. We need to build proper genral purpose interfaces and not layer hacks on top of hacks.