Re: [PATCH] btrfs: use atomic64_t for free_objectid

[David Sterba <dsterba@suse.cz>]

On Thu, Feb 13, 2025 at 05:47:00PM +0000, Mark Harmstone wrote:
> On 10/2/25 22:34, David Sterba wrote:
> > > 
> > On Wed, Feb 05, 2025 at 03:08:59PM +0000, Mark Harmstone wrote:
> >> On 31/1/25 19:38, Boris Burkov wrote:
> >>> My understanding is that the motivation is to enable non-blocking mode
> >>> for io_uring operations, but I'll let Mark reply in detail.
> >>
> >> That's right. io_uring operates in two passes: the first in non-blocking
> >> mode, then if it receives EAGAIN again in a work thread in blocking mode.
> >>
> >> As part of my work to get btrfs receive to use io_uring, I want to add
> >> an io_uring interface for subvol creation. There's two things preventing
> >> a non-blocking version: this, and the fact we need a
> >> btrfs_try_start_transaction() (which should be relatively straightforward).
> > 
> >>>>>>> Even if we were to grab a new integer a billion
> >>>>>>> times a second, it would take 584 years to wrap around.
> >>>>>>
> >>>>>> Good to know, but I would not use that as an argument.  This may hold if
> >>>>>> you predict based on contemporary hardware. New technologies can bring
> >>>>>> an order of magnitude improvement, eg. like NVMe brought compared to SSD
> >>>>>> technology.
> >>>>>
> >>>>> I eagerly look forward to my 40GHz processor :)
> >>>>
> >>>> You never know about unexpected break-throughs. So fingers crossed.
> >>>> Though I'd be surprised.
> >>
> >> More like 40THz, and somebody finding a way to increase the speed of
> >> light... There's four or five orders of magnitude to go before 64-bit
> >> wraparound would become a problem here.
> > 
> > Thinking about the margins again, there is probably enough that we don't
> > have to care. I'd still keep the upper limit check as for any random
> > event like fuzzing, bitflips and such.
> > 
> > The use case for nonblocking io_uring makes sense and justifies the
> > optimization. As mentioned, there are other factors slowing down the
> > inode creation and number allocation so it's "fingers crossed* safe.
> 
> Thanks David. Am I okay to push this patch to for-next then?

Yes, but please send an updated version first, we need the reasoning for
the choice and that it's still safe regarding amount of time to reach
the maximum. Basically the objections and answers from this thread
summarized.