On 12/03/2025 13:54, Christoph Hellwig wrote:
+
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.
ok, we can do that.
I have my own stress test for atomic writes on fragmented FSes, but I
have not encountered a such a problem. But we need to formalize
something though.
(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.
ok.
Thanks,
John
