linux-kernel - Re: [PATCH v5 07/10] xfs: Commit CoW-based atomic writes atomically

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: <Z9GSKbuollfpAZeX@infradead.org>
Date: Wed, 12 Mar 2025 06:54:49 -0700
From: Christoph Hellwig <hch@...radead.org>
To: John Garry <john.g.garry@...cle.com>
Cc: Christoph Hellwig <hch@...radead.org>, brauner@...nel.org,
	djwong@...nel.org, cem@...nel.org, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	ojaswin@...ux.ibm.com, ritesh.list@...il.com,
	martin.petersen@...cle.com
Subject: Re: [PATCH v5 07/10] xfs: Commit CoW-based atomic writes atomically

On Wed, Mar 12, 2025 at 09:04:07AM +0000, John Garry wrote:
> > As already mentioned in a previous reply:  "all" might be to much.
> > The code can only support a (relatively low) number of extents
> > in a single transaction safely.
> 
> Then we would need to limit the awu max to whatever can be guaranteed
> (to fit).

Yes.  And please add a testcase that creates a badly fragmented file
and verifies that we can handle the worst case for this limit.

(although being able to reproduce the worst case btree splits might
be hard, but at least the worst case fragmentation should be doable)

> > Assuming we could actually to the multi extent per transaction
> > commit safely, what would be the reason to not always do it?
> > 
> 
> Yes, I suppose that it could always be used. I would suggest that as a later
> improvement, if you agree.

I remember running into some problems with my earlier version, but I'd
have to dig into it.  Maybe it will resurface with the above testing,
or it was due to my optimizations for the extent lookups.