On Mon, Aug 26, 2024 at 09:27:03PM -0700, Christoph Hellwig wrote: > On Mon, Aug 26, 2024 at 12:14:04PM -0700, Darrick J. Wong wrote: > > They're not sparse like fsbnos on the data device, they're laid end to > > end. IOWs, it's a straight linear translation. If you have an rtgroup > > that is 50 blocks long, then rtgroup 1 starts at (50 * blocksize). > > Except with the zone capacity features on ZNS devices, where they > already are sparse. But that's like 200 patches away from the state > here.. Heh. > > group 0 on a !rtg filesystem can be 64-bits in block/rt count. This is > > a /very/ annoying pain point -- if you actually created such a > > filesystem it actually would never work because the rtsummary file would > > be created undersized due to an integer overflow, but the verifiers > > never checked any of that, and due to the same underflow the rtallocator > > would search the wrong places and (eventually) fall back to a dumb > > linear scan. > > > > Soooooo this is an obnoxious usecase (broken large !rtg filesystems) > > that we can't just drop, though I'm pretty sure there aren't any systems > > in the wild. > > So, do we really need to support that? I think we've always supported > a 64-bit block count, so we'll have to support that, but if a > 32bit > extent count was always broken maybe we should simply stop to pretend > to support it? I'm in favor of that. The rextslog computation only got fixed in 6.8, which means none of the LTS kernels really have it yet. And the ones that do are migrating verrrrry slowly due to the global rtbmp lock. > > > What's the maximum valid rtg number? We're not ever going to be > > > supporting 2^32 - 2 rtgs, so what is a realistic maximum we can cap > > > this at and validate it at? > > > > /me shrugs -- the smallest AG size on the data device is 16M, which > > technically speaking means that one /could/ format 2^(63-24) groups, > > or order 39. > > > > Realistically with the maximum rtgroup size of 2^31 blocks, we probably > > only need 2^(63 - (31 + 10)) = 2^22 rtgroups max on a 1k fsblock fs. > > Note that with zoned file system later on we are bound by hardware > size. SMR HDDs by convention some with 256MB zones. This is a bit > on the small side, but grouping multiple of those into a RT group > would be a major pain. I hope the hardware size will eventually > increase, maybe when they move to 3-digit TB capcity points. <nod> --D
