linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: John Garry <john.g.garry@oracle.com>,
	brauner@kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz,
	cem@kernel.org, linux-fsdevel@vger.kernel.org,
	dchinner@redhat.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
	ritesh.list@gmail.com, martin.petersen@oracle.com,
	linux-ext4@vger.kernel.org, linux-block@vger.kernel.org,
	catherine.hoang@oracle.com, linux-api@vger.kernel.org
Subject: Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time
Date: Wed, 23 Apr 2025 08:21:03 -0700	[thread overview]
Message-ID: <20250423152103.GD25675@frogsfrogsfrogs> (raw)
In-Reply-To: <20250423150110.GB25675@frogsfrogsfrogs>

On Wed, Apr 23, 2025 at 08:01:10AM -0700, Darrick J. Wong wrote:
> On Wed, Apr 23, 2025 at 10:32:09AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 22, 2025 at 12:27:39PM +0000, John Garry wrote:
> > > From: "Darrick J. Wong" <djwong@kernel.org>
> > > 
> > > Introduce a mount option to allow sysadmins to specify the maximum size
> > > of an atomic write.  If the filesystem can work with the supplied value,
> > > that becomes the new guaranteed maximum.
> > > 
> > > The value mustn't be too big for the existing filesystem geometry (max
> > > write size, max AG/rtgroup size).  We dynamically recompute the
> > > tr_atomic_write transaction reservation based on the given block size,
> > > check that the current log size isn't less than the new minimum log size
> > > constraints, and set a new maximum.
> > > 
> > > The actual software atomic write max is still computed based off of
> > > tr_atomic_ioend the same way it has for the past few commits.
> > 
> > The cap is a good idea, but a mount option for something that has
> > strong effects for persistent application formats is a little suboptimal.
> > But adding a sb field and an incompat bit wouldn't be great either.
> > 
> > Maybe this another use case for a trusted xattr on the root inode like
> > the autofsck flag?
> 
> That would be even better, since you could set it at mkfs time and it
> would persist until the next xfs_property set call.

[/me hands himself another coffee]

The only problem is, setting the property while the fs is mounted does
not change the actual fs capability until the next mount since
properties are regular (and not magic) xattrs.

--D

> --D
> 

      reply	other threads:[~2025-04-23 15:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-22 12:27 [PATCH v8 00/15] large atomic writes for xfs John Garry
2025-04-22 12:27 ` [PATCH v8 01/15] fs: add atomic write unit max opt to statx John Garry
2025-04-22 12:27 ` [PATCH v8 02/15] xfs: add helpers to compute log item overhead John Garry
2025-04-22 12:27 ` [PATCH v8 03/15] xfs: add helpers to compute transaction reservation for finishing intent items John Garry
2025-04-22 12:27 ` [PATCH v8 04/15] xfs: rename xfs_inode_can_atomicwrite() -> xfs_inode_can_hw_atomicwrite() John Garry
2025-04-22 12:27 ` [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block John Garry
2025-04-23  0:38   ` Darrick J. Wong
2025-04-23  7:15     ` John Garry
2025-04-23  8:10       ` Christoph Hellwig
2025-04-23  8:28         ` John Garry
2025-04-23  8:33           ` Christoph Hellwig
2025-04-23 15:12             ` Darrick J. Wong
2025-04-23 15:46               ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 06/15] xfs: allow block allocator to take an alignment hint John Garry
2025-04-22 12:27 ` [PATCH v8 07/15] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-04-22 12:27 ` [PATCH v8 08/15] xfs: refine atomic write size check in xfs_file_write_iter() John Garry
2025-04-22 12:27 ` [PATCH v8 09/15] xfs: add xfs_atomic_write_cow_iomap_begin() John Garry
2025-04-23  8:12   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 10/15] xfs: add large atomic writes checks in xfs_direct_write_iomap_begin() John Garry
2025-04-23  8:16   ` Christoph Hellwig
2025-04-23  8:18     ` John Garry
2025-04-22 12:27 ` [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically John Garry
2025-04-23  8:23   ` Christoph Hellwig
2025-04-23 14:58     ` Darrick J. Wong
2025-04-23 15:53       ` Christoph Hellwig
2025-04-23 15:58         ` Darrick J. Wong
2025-04-23 16:38           ` John Garry
2025-04-22 12:27 ` [PATCH v8 12/15] xfs: add xfs_file_dio_write_atomic() John Garry
2025-04-23  8:25   ` Christoph Hellwig
2025-04-23  8:29     ` John Garry
2025-04-22 12:27 ` [PATCH v8 13/15] xfs: add xfs_compute_atomic_write_unit_max() John Garry
2025-04-23  8:26   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 14/15] xfs: update atomic write limits John Garry
2025-04-23  8:27   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time John Garry
2025-04-23  8:32   ` Christoph Hellwig
2025-04-23 15:01     ` Darrick J. Wong
2025-04-23 15:21       ` Darrick J. Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250423152103.GD25675@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=brauner@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).