Re: [PATCH 25/43] xfs: add support for zoned space reservations

Darrick J. Wong
2024-12-19T16:00:05Z

On Thu, Dec 19, 2024 at 06:50:59AM +0100, Christoph Hellwig wrote:
> On Tue, Dec 17, 2024 at 08:59:55AM -0800, Darrick J. Wong wrote:
> > Hrmm, they're rt extents that are available "now", or "for cheap"...
> >
> > XC_FREE_NOW_RTEXTENTS
> >
> > XC_FREE_RTEXTENTS_IMMED
> >
> > XC_FREE_RTEXTENTS_CHEAP
> >
> > Eh, I'm not enthusiastic about any of those. The best I can think of
> > is:
> >
> > XC_FREE_RTEXTENTS_NOGC, /* space available without gc */
>
> I really hate that, as it encodes the policy how to get (or not) the
> blocks vs what they are.

Yeah, me too. Want to leave it as XC_FREE_RTAVAILABLE?

> > > > going to use the greedy algorithm. Later I see XFS_ZR_GREEDY gets used
> > > > from the buffered write path, but there doesn't seem to be an obvious
> > > > reason why?
> > >
> > > Posix/Linux semantics for buffered writes require us to implement
> > > short writes. That is if a single (p)write(v) syscall for say 10MB
> > > only find 512k of space it should write those instead of failing
> > > with ENOSPC. The XFS_ZR_GREEDY implements that by backing down to
> > > what we can allocate (and the current implementation for that is
> > > a little ugly, I plan to find some time for changes to the core
> > > percpu_counters to improve this after the code is merged).
> >
> > Ah, ok. Can you put that in the comments defining XFS_ZR_GREEDY?
>
> This is what I added earlier this week:
>
> /*
> * Grab any available space, even if it is less than what the caller asked for.
> */
> #define XFS_ZR_GREEDY (1U << 0)
>
> Do you want the glory details on why we're doing it here as well?
> I guess it if can't be left as an exercise to the reader I'd probably
> rather place it in the caller.

Nah, that's enough to hint at what I should be looking for any time
there's a branch involving XFS_ZR_GREEDY.

--D