linux-kernel - Re: [PATCH 0/6] block atomic writes for XFS

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: <20240214074559.GB10006@lst.de>
Date: Wed, 14 Feb 2024 08:45:59 +0100
From: Christoph Hellwig <hch@....de>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Christoph Hellwig <hch@....de>, John Garry <john.g.garry@...cle.com>,
	viro@...iv.linux.org.uk, brauner@...nel.org, dchinner@...hat.com,
	jack@...e.cz, chandan.babu@...cle.com, martin.petersen@...cle.com,
	linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, tytso@....edu, jbongio@...gle.com,
	ojaswin@...ux.ibm.com
Subject: Re: [PATCH 0/6] block atomic writes for XFS

On Tue, Feb 13, 2024 at 09:55:49AM -0800, Darrick J. Wong wrote:
> On Tue, Feb 13, 2024 at 08:22:37AM +0100, Christoph Hellwig wrote:
> > 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
> 
> Er, what are you thinking w.r.t. swapext and sometimescow?

What do you mean with sometimescow?  Just normal reflinked inodes?

> swapext
> doesn't currently handle COW forks at all, and it can only exchange
> between two of the same type of fork (e.g. both data forks or both attr
> forks, no mixing).
> 
> Or will that be your next suggestion whenever I get back to fiddling
> with the online fsck patches? ;)

Let's take a step back.  If we want atomic write semantics without
hardware offload, what we need is to allocate new blocks and atomically
swap them into the data fork.  Basicall an atomic version of
xfs_reflink_end_cow.  But yes, the details of the current swapext
item might not be an exact fit, maybe it's just shared infrastructure
and concepts.

I'm not planning to make you do it, because such a log item would
generally be pretty useful for 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.
> 
> I suspect they might want to fail-fast (back to standard WAL mode or
> whatever) if the hardware support isn't available.

Maybe for your particular DB use case.  But there's plenty of
applications that just want atomic writes without building their
own infrastruture, including some that want pretty large chunks.

Also if a file system supports logging data (which I have an
XFS early prototype for that I plan to finish), we can even do
the small double writes more efficiently than the application,
all through the same interface.