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 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.lore.kernel.org (Postfix) with ESMTPS id 5AEBAC54E67 for ; Wed, 27 Mar 2024 20:31:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xsbDq/umAVs2THPOn+dgmzNcXWhcjS94eKkuWI7aCcw=; b=m5bXyx7bO+D0LY1jLDP7gbk9Mh dzDT70ZVu0VQ6NjpmsVI4aFnKUPsKJqUwCiDl2Ag2aJT1cxJlDjr1Q+opisYgYLh0tf03tQLdDG7D age07mSzjc1t1qaXRqOvC7eMtqGyjIz3Jceupz90xSAi24eiAA6wKlU8LTw2yAFpHTNuRmN+xtjra EDD/g5b6XluFRBGaBIjAzc/hJZiI+Ud55WUIqU7HBKk2YvL1ESE7xbg94RusX8A5vtn/CuHYzYLg6 Dpm40Az1gu4N5pSezruKbbe41U4fxD9tn40jCCsR0tUjAjwgUxtxZgVb4H6wBg+GFlwwScaaRufv6 NoYi/T4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpZw9-0000000B1Wv-3mZR; Wed, 27 Mar 2024 20:31:53 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpZw6-0000000B1Vd-2xeg for linux-nvme@lists.infradead.org; Wed, 27 Mar 2024 20:31:52 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1dffa5e3f2dso2091075ad.2 for ; Wed, 27 Mar 2024 13:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1711571509; x=1712176309; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xsbDq/umAVs2THPOn+dgmzNcXWhcjS94eKkuWI7aCcw=; b=KpChYEa/GCUk4m/TNaM4Cw9ekYXpfsS7JIQ+10EsY0679lcvopzrPjaNUiMXDUWNzR 0M5Mq36npqMPRseqecCxv44QpffVPYjmSAyBnx+Aq86LzsP8BZtfv8TSdcjRNux3qgsV KwjTzvOhRbabVlVdZ4jHw1Ps24GARNBKZejgI0ElZyhLGaF/M+wyZAedchTWhcQERcEP rx2PHmLqeS0tmJLckQseMOeT6F/p/TxQC6tYNYV7uQNRCbDkdoNiTOV87OHQnIW6n6mu ucFbKRZzv8y/NHDB5H4I+iDBQzin1iDLh7z92zF/Tyt5HM03JgUXtHPrABtmNGyYVkd6 kbrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711571509; x=1712176309; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xsbDq/umAVs2THPOn+dgmzNcXWhcjS94eKkuWI7aCcw=; b=Tiy6PUArmTHgrAGU8uPr974THMjZQgP0ZH/phvvHZM/18C7wW471bOSe1yZJtiJMg3 pYwOBVFVQm0KYiLZd8s/pYT67L5HQ7+h3yciK2w0QpaCyWPZHk/v22rDqgvUDDtTFScB Q2nxucn9jPVx5ik7DWMNPR7tPsjdLwDJOIF64Vxslq19mX4IXLLF5g5TYLgD7p6acP2H b3m1koWZtG0UCtTNvYlLqyAACKzgeAEglzItP9tk/OvU9gvI3YYg5PKAuMFA4uNBhtCp OR2mHYVW+3F4t3UHH143EMyQ4YRYaTtJ121mJXHgInrBpA80pYy9Qs3Nymvl0A0jj/Al 9Hug== X-Forwarded-Encrypted: i=1; AJvYcCX/POQPKHgIOTapMRSo8NeV2SPe4J1mRLSgpkgB1LgPt//zARneoJEI93JK4e2WQpvN8hJfRYgXxavwZeF6Wphd+5iiTgP1u/mgMSUbuvA= X-Gm-Message-State: AOJu0YyfiAvGr7SQwDXaXKsbOY2UfAJC+sQR61fDlFCb1Lq/22psifX0 727lgCO+eyacqm2XnwPF4OVuoUMpA/SLJdyTEh2CBm6UmFkcmdL0MODHyKYHN7I= X-Google-Smtp-Source: AGHT+IHM4Tr0BQ+ZyOuGEh7PBr8lX9a5mFa0hqjuG33bAQkeUreuKwQCfXdzVyFJvoKTjvvS6rj26w== X-Received: by 2002:a17:903:8cd:b0:1df:fa1a:529f with SMTP id lk13-20020a17090308cd00b001dffa1a529fmr955250plb.24.1711571509203; Wed, 27 Mar 2024 13:31:49 -0700 (PDT) Received: from dread.disaster.area (pa49-181-56-237.pa.nsw.optusnet.com.au. [49.181.56.237]) by smtp.gmail.com with ESMTPSA id l13-20020a170903120d00b001deed044b7dsm4122560plh.185.2024.03.27.13.31.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 13:31:48 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rpZw1-00CItN-2k; Thu, 28 Mar 2024 07:31:45 +1100 Date: Thu, 28 Mar 2024 07:31:45 +1100 From: Dave Chinner To: Matthew Wilcox Cc: John Garry , axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, jejb@linux.ibm.com, martin.petersen@oracle.com, djwong@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com, jack@suse.cz, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com, linux-scsi@vger.kernel.org, ojaswin@linux.ibm.com, linux-aio@kvack.org, linux-btrfs@vger.kernel.org, io-uring@vger.kernel.org, nilay@linux.ibm.com, ritesh.list@gmail.com Subject: Re: [PATCH v6 00/10] block atomic writes Message-ID: References: <20240326133813.3224593-1-john.g.garry@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240327_133151_202480_A175A606 X-CRM114-Status: GOOD ( 31.81 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org On Wed, Mar 27, 2024 at 03:50:07AM +0000, Matthew Wilcox wrote: > On Tue, Mar 26, 2024 at 01:38:03PM +0000, John Garry wrote: > > The goal here is to provide an interface that allows applications use > > application-specific block sizes larger than logical block size > > reported by the storage device or larger than filesystem block size as > > reported by stat(). > > > > With this new interface, application blocks will never be torn or > > fractured when written. For a power fail, for each individual application > > block, all or none of the data to be written. A racing atomic write and > > read will mean that the read sees all the old data or all the new data, > > but never a mix of old and new. > > > > Three new fields are added to struct statx - atomic_write_unit_min, > > atomic_write_unit_max, and atomic_write_segments_max. For each atomic > > individual write, the total length of a write must be a between > > atomic_write_unit_min and atomic_write_unit_max, inclusive, and a > > power-of-2. The write must also be at a natural offset in the file > > wrt the write length. For pwritev2, iovcnt is limited by > > atomic_write_segments_max. > > > > There has been some discussion on supporting buffered IO and whether the > > API is suitable, like: > > https://lore.kernel.org/linux-nvme/ZeembVG-ygFal6Eb@casper.infradead.org/ > > > > Specifically the concern is that supporting a range of sizes of atomic IO > > in the pagecache is complex to support. For this, my idea is that FSes can > > fix atomic_write_unit_min and atomic_write_unit_max at the same size, the > > extent alignment size, which should be easier to support. We may need to > > implement O_ATOMIC to avoid mixing atomic and non-atomic IOs for this. I > > have no proposed solution for atomic write buffered IO for bdev file > > operations, but I know of no requirement for this. > > The thing is that there's no requirement for an interface as complex as > the one you're proposing here. I've talked to a few database people > and all they want is to increase the untorn write boundary from "one > disc block" to one database block, typically 8kB or 16kB. > > So they would be quite happy with a much simpler interface where they > set the inode block size at inode creation time, and then all writes to > that inode were guaranteed to be untorn. This would also be simpler to > implement for buffered writes. You're conflating filesystem functionality that applications will use with hardware and block-layer enablement that filesystems and filesystem utilities need to configure the filesystem in ways that allow users to make use of atomic write capability of the hardware. The block layer functionality needs to export everything that the hardware can do and filesystems will make use of. The actual application usage and setup of atomic writes at the filesystem/page cache layer is a separate problem. i.e. The block layer interfaces need only support direct IO and expose limits for issuing atomic direct IO, and nothing more. All the more complex stuff to make it "easy to use" is filesystem level functionality and completely outside the scope of this patchset.... -Dave. -- Dave Chinner david@fromorbit.com