On Tue, Oct 22, 2024 at 12:38:23AM +1100, Dave Chinner wrote: > On Mon, Oct 14, 2024 at 02:50:37PM -0400, Brian Foster wrote: > > So for a hacky thought/example, suppose we defined a transaction mode > > that basically implemented an exclusive checkpoint requirement (i.e. > > this transaction owns an entire checkpoint, nothing else is allowed in > > the CIL concurrently). > > Transactions know nothing about the CIL, nor should they. The CIL > also has no place in ordering transactions - it's purely an > aggregation mechanism that flushes committed transactions to stable > storage when it is told to. i.e. when a log force is issued. > > A globally serialised transaction requires ordering at the > transaction allocation/reservation level, not at the CIL. i.e. it is > essentially the same ordering problem as serialising against > untracked DIO on the inode before we can run a truncate (lock, > drain, do operation, unlock). > > > Presumably that would ensure everything before > > the grow would flush out to disk in one checkpoint, everything > > concurrent would block on synchronous commit of the grow trans (before > > new geometry is exposed), and then after that point everything pending > > would drain into another checkpoint. > > Yup, that's high level transaction level ordering and really has > nothing to do with the CIL. The CIL is mostly a FIFO aggregator; the > only ordering it does is to preserve transaction commit ordering > down to the journal. > > > It kind of sounds like overkill, but really if it could be implemented > > simply enough then we wouldn't have to think too hard about auditing all > > other relog scenarios. I'd probably want to see at least some reproducer > > for this sort of problem to prove the theory though too, even if it > > required debug instrumentation or something. Hm? > > It's relatively straight forward to do, but it seems like total > overkill for growfs, as growfs only requires ordering > between the change of size and new allocations. We can do that by > not exposing the new space until after then superblock has been > modifed on stable storage in the case of grow. > > In the case of shrink, globally serialising the growfs > transaction for shrink won't actually do any thing useful because we > have to deny access to the free space we are removing before we > even start the shrink transaction. Hence we need allocation vs > shrink co-ordination before we shrink the superblock space, not a > globally serialised size modification transaction... > Not sure what you mean here, at least I don't see that requirement in the current code. It looks like shrink acquires the blocks all in the same transaction as the shrink. If something fails, it rolls or returns the space depending on what actually failed.. Brian > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
