linux-kernel - Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250423152103.GD25675@frogsfrogsfrogs>
Date: Wed, 23 Apr 2025 08:21:03 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: John Garry <john.g.garry@...cle.com>, brauner@...nel.org,
	viro@...iv.linux.org.uk, jack@...e.cz, cem@...nel.org,
	linux-fsdevel@...r.kernel.org, dchinner@...hat.com,
	linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	ojaswin@...ux.ibm.com, ritesh.list@...il.com,
	martin.petersen@...cle.com, linux-ext4@...r.kernel.org,
	linux-block@...r.kernel.org, catherine.hoang@...cle.com,
	linux-api@...r.kernel.org
Subject: Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum
 atomic write limit at mount time

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@...nel.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
>