On Thu, Feb 20, 2025 at 07:16:05AM +0100, Christoph Hellwig wrote: > 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. That seems like a good idea. --D
