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. > > 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
