On 7/24/24 12:23 PM, Darrick J. Wong wrote: > On Wed, Jul 24, 2024 at 10:44:47AM -0500, Eric Sandeen wrote: >> On 7/24/24 10:41 AM, Eric Sandeen wrote: >>> On 7/23/24 7:46 PM, Dave Chinner wrote: >>>>> What about the log? If sb_agblocks increases, that can cause >>>>> transaction reservations to increase, which also increases the minimum >>>>> log size. >>>> Not caring, because the current default minimum of 64MB is big enough for >>>> any physical filesystem size. Further, 64MB is big enough for decent >>>> metadata performance even on large filesystem, so we really don't >>>> need to touch the journal here. > > <shrug> I think our support staff might disagree about that for the > large machines they have to support, but log expansion doesn't need to > be implemented in the initial proposal or programming effort. +1 Yeah I'd prefer to not get bogged down in that, it can be done later, or not. Let's focus on the core of the proposal, even though I'm academically intrigued by log growth possibilities. (he says, then comments more) >>> Seems fair, but just to stir the pot, "growing the log" offline, when >>> you've just added potentially gigabytes of free space to an AG, should >>> be trivial, right? > > Possibly -- if there's free space after the end and the log is clean. > Maybe mkfs should try to allocate the log at the /end/ of the AG to > make this easier? It can be any sufficiently large free space, right, doesn't have to be adjacent to the log. So as long as you've expanded more than 64MB there's a chance to move to a bigger log region, I think. >> Ugh I'm sorry, read to the end before responding, Eric. >> >> (I had assumed that an expand operation would require a clean log, but I >> suppose it doesn't have to.) > > ...why not require a clean filesystem? Most of these 10000x XFS > expansions are gold master cloud images coming from a vendor, which > implies that we could hold them to slightly higher cleanliness levels. Yeah I mean it only matters if you want to change the log size, right. So could even do # xfs_expand --grow-data=4T --grow-log=2G fs-image.img Error: Cannot grow a dirty log, please mount ... # But I think we're getting ahead of ourselves a little, let's see if the basic proposal makes sense before debating extra bells and whistles too much? It's probably enough at this point to say "yeah, it's possible if we decide we want it, the design does not preclude it." -Eric > --D > >> -Eric >> >> >
