On Thu, Oct 22, 2020 at 07:15:05PM +1100, Dave Chinner wrote: > On Wed, Oct 21, 2020 at 11:02:56PM -0700, Darrick J. Wong wrote: > > On Thu, Oct 22, 2020 at 04:15:33PM +1100, Dave Chinner wrote: > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > Phase 6 accesses inode chunk records mostly in an isolated manner. > > > However, when it finds a corruption in a directory or there are > > > multiple hardlinks to an inode, there can be concurrent access > > > to the inode chunk record to update state. > > > > > > Hence the inode record itself needs a mutex. This protects all state > > > changes within the inode chunk record, as well as inode link counts > > > and chunk references. That allows us to process multiple chunks at > > > once, providing concurrency within an AG as well as across AGs. > > > > > > The inode chunk tree itself is not modified in phase 6 - it's built > > > > Well, that's not 100% true -- mk_orphanage can do that, but AFAICT > > that's outside the scope of the parallel processing (and I don't see > > much point in parallelizing that part) so I guess that's fine? > > AFAICT, yes. Ok, good, I'm confident I understand what's going on here. :) Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> --D > > > in phases 3 and 4 - and so we do not need to worry about locking > > > for AVL tree lookups to find the inode chunk records themselves. > > > hence internal locking is all we need here. > > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > > > TBH I wonder if all the phase6.c code to recreate the root dir, the > > orphanage, and the realtime inodes ought to get moved to another file, > > particularly since the metadata directory patches add quite a bit more > > stuff here? But that's a topic for another patch... > > Probably should and yes, spearate patch :) > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
