Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp2888342rdb; Mon, 12 Feb 2024 23:23:08 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVZ93xQ7IVDsgg8Rsxh4/nNxX7a7mQuMYp8T+gH5pJkd+qLz+9q2yk9mDpTzEZAZZKqXhIrB+Yz6avLC43vEBs9/f39yi+vm/2XUA7DsA== X-Google-Smtp-Source: AGHT+IEmVuNcmAdSGO7MVCkOLZEbPO3yznoMEsHkq8SLzyCPYRiBR3e7ESeuxXmeBWb1FHX5MtoN X-Received: by 2002:a05:6a20:6f9c:b0:19e:abbf:a47d with SMTP id gv28-20020a056a206f9c00b0019eabbfa47dmr7216299pzb.6.1707808988145; Mon, 12 Feb 2024 23:23:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707808988; cv=pass; d=google.com; s=arc-20160816; b=HVPdB9uyC/FlK8fuMfTpEhi70N19h48T/9j5ExCkpvUCs27RVIgqMHkTQTUNXblQZh /58EvQ+0ELVHmglUkgAehfQLkN4baYxNjx/gd0Wh2AiCCiDt6y0HWdXIRJ1RxuqyIEOh sBFr8iggHRyxrgAQDTlfG4OsnNY8MPOGLWCqVgXLszxvdReIuqOIJp2zDhF7niGvGjXB jDV+ZcLjW9n0zMQfmcJaVSEHOjrpjqbO37OyEIfd0QMrc6HzWN/MhSS4eEmMRTksIWh8 ZRo920yEQQncHorw0by0hn/o7S0TsslRVUgGPwIa0BGk1nwg9qVsnJUyqXWjs112p2d7 5P4w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date; bh=AmzH5AXbOO0JjmsSxCnYaXuwDX3pDFXeVLwhZUC5f4s=; fh=yrgyLwfzHXY5c3Sbltq1Z4cYnRtG83gFbrwwQOjYNx8=; b=sPQyf7jinSuY0+wZ37Jk5YZZEnd/4XoxZrRPU7rv3MYdznfeLCycMqeMvEcJdlAxcD HtFOOqeFiOIuoOKPfmROI3llbixC7ui5cKnI3adaeW1hsWYa2e0b6riVY+WzKgHJfZKR 2iI9rp/RZiwbuwtT9E3RgRshqqo6wDHiev4hkKLIt/8hhLxPrRNJKNw7W/w3NE7KZAJw zWQh0TwKsfDyXwHsJzI5ckiOU7vsJ1ziDsf0PpUqbmDxquSB3El0NH85GcfSspb7A26x 4P60QB2P1A2airx4kdamc3Iy8cyfT9wotOAvkyqXbUl3W07/bfRsKWIIXGZtaGvtMqCO sXeA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-63043-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63043-linux.lists.archive=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=2; AJvYcCXz0+qLse5ZTdf/ta+rcDipPTMwrT/WqN2DPLPxzN1T2RR82zXzyxEkOLta/rei96lAChrVnPvXQft4EIzkOYtQv0NMLu+U6mUrvzmovw== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id y16-20020a17090322d000b001d9e1aaf21bsi1637349plg.138.2024.02.12.23.23.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 23:23:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-63043-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-63043-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63043-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D0EF8282EC8 for ; Tue, 13 Feb 2024 07:23:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DF63A17BCA; Tue, 13 Feb 2024 07:22:43 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (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 BA67E17998; Tue, 13 Feb 2024 07:22:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707808963; cv=none; b=NeTklPDbXHRPw8zEN2ZT3MwCxf/Hb6V0HHsfXyyOH0pojd3pZ6FOHVDEh8MnmUKNe3QBFQW9kx83lBPMb9l2QCt9Q5Gqk3N1D+83QqBiBxsYsn+OUfebdoD8TTsJGLIWBCBzIMp8f9dhBOybgqW2KVLlaMxnlemxJXhC0HEwnz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707808963; c=relaxed/simple; bh=q2/wWV0cG4bqeLz1hLZCxS1bX1xLeiDQn9NLNf8iJow=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q6TDxAsbkdWy92FJo9gzBhBCMgY8GJWIeLlOUoV6b2c7CJy5/IFpPtj3Np+8iZSv4p+Ypuo6R9lCSYJXdw7GoEh/vPRpPY70UjheWSmMfMy6jTxwAtzjY94R0U8K9ZP60ZEi9efA5jDu+mXUQpr+nXzjLmo47z6aNPgPfYVMv8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 70692227A87; Tue, 13 Feb 2024 08:22:37 +0100 (CET) Date: Tue, 13 Feb 2024 08:22:37 +0100 From: Christoph Hellwig To: John Garry Cc: hch@lst.de, djwong@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com, jack@suse.cz, chandan.babu@oracle.com, martin.petersen@oracle.com, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com, ojaswin@linux.ibm.com Subject: Re: [PATCH 0/6] block atomic writes for XFS Message-ID: <20240213072237.GA24218@lst.de> References: <20240124142645.9334-1-john.g.garry@oracle.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=us-ascii Content-Disposition: inline In-Reply-To: <20240124142645.9334-1-john.g.garry@oracle.com> User-Agent: Mutt/1.5.17 (2007-11-01) From reading the series and the discussions with Darrick and Dave I'm coming more and more back to my initial position that tying this user visible feature to hardware limits is wrong and will just keep on creating ever more painpoints in the future. Based on that I suspect that doing proper software only atomic writes using the swapext log item and selective always COW mode and making that work should be the first step. We can then avoid that overhead for properly aligned writs if the hardware supports it. For your Oracle DB loads you'll set the alignment hints and maybe even check with fiemap that everything is fine and will get the offload, but we also provide a nice and useful API for less performance critical applications that don't have to care about all these details.