On Wed, Feb 19, 2025 at 01:47:27PM -0800, Darrick J. Wong wrote: > I don't want to go adding opencoded logic loops all over the place, that > would be pretty horrid. But what if xfs_zone_alloc_ctx were instead a > general freecounter reservation context? Then we could hide all this > "try to reserve space, push a garbage collector once if we can't, and > try again once" logic into an xfs_reserve_space() function, and pass > that reservation through the iomap functions to ->iomap_begin. > > But a subtlety here is that the code under iomap_file_buffered_write > might not actually need to create any delalloc reservations, in which > case a worst case reservation could fail with ENOSPC even though we > don't actually need to allocate a single byte. I think the idea of per-reserving space before starting transactions is generally a good idea, and I'd be happy to look into reworking the conventional code towards that. But I'd rather not do that as part of this series if I can avoid it. > Having said that, this is like the 5th time I've read through this patch > and I don't see anything obviously wrong now, so my last question is: > Zoned files cannot have preallocations so that's why we don't do this > for FALLOC_FL_ALLOCATE_RANGE, right? Exactly. Should I add this to the commit log? It's mentioned mostly in the cover letter at the moment.
