----- Original Message ----- > Before this patch, whenever a directory was deleted, it called function > __gfs2_dir_exhash_dealloc to deallocate the directory's leaf blocks. > But __gfs2_dir_exhash_dealloc never knew if any given leaf block had > leaf continuation aka "next" blocks, so it read every single leaf block > in, only to determine in 99% of the cases that there was none. Still, > this reading in of all the leaf blocks was very slow. > > This patch adds a new disk flag that indicates whether a directory is > clean of any "next leaf" blocks. If so, it takes an optimized path that > just deletes the leaf blocks and zeroes out the hash table. > > It would seem to make more sense to have the new bit indicate when a > directory contains "next leaf" blocks rather than the inverse, but we > need to treat file systems created by older versions of gfs2 as if > they have "next leaf" blocks. > > Signed-off-by: Bob Peterson <[email protected]>
By the way, I should also mention that this new faster leaf deallocate keeps a separate transaction and locking for each resource group affected. The older way of deleting leaf blocks formulated an "rlist" and potentially locked several rgrps for the duration of its entire delete. The new algorithm only keeps one single rgrp locked at a time, thus allowing more processes to run in parallel. Bob
