Re: what is fsck's "slowdown"?

On  4 Sep, Don Lewis wrote:
> On  4 Sep, Marc G. Fournier wrote:
>> On Fri, 3 Sep 2004, Don Lewis wrote:
> 
>>> Would the file system in question happen to be full of UNREF files that
>>> fsck is deleting?
>> 
>> mostly 'ZERO LENGTH DIRECTORY' ...
> 
> I'm pretty sure that I understand the problem now.  During pass 4, fsck
> looks at each inode.  It checks each inode in the FSTATE and DFOUND
> states to see if their link counts need to be adjusted.  If the link
> count does not need to be adjusted, fsck checks to see if the inode is
> on the list of inodes whose initial link counts were zero, and if it
> finds the inode on this list, it clears the inode.
> 
> The problem is that the zero length directories get added to this list
> if their initial link count is zero, and they also don't get removed
> from the list because they are in the DCLEAR state, so the list doesn't
> shrink.  This bloats the list, which greatly slows down processing of
> normal files and directories.
> 
> Deleting unreferenced files is not the biggest bottleneck, so reversing
> the order of the list isn't going to help much.  Probably the biggest
> speedup could be gained by keeping the zero length directories off the
> list.

An even better solution would be to dispense with the zln list entirely
and just set a bit for these inodes in their struct inostat.  This
change is a bit more intrusive because of the need for some sort of
packing strategy because of the need to keep this structure small.  My
initial inclination would be to add two new states, FZERO and DZERO,
that pass1() would use to mark inodes with a zero link count.