what is fsck's "slowdown"?
truckman at FreeBSD.org
Mon Sep 27 10:19:16 PDT 2004
On 24 Sep, Marc G. Fournier wrote:
> Just curious as to whether or not this is going to get applied to the
> source tree ... ? Just checked my -current, and it isn't there yet, just
> wanted to see if maybe its been forgotten? :(
There are a couple of tweaks that I want to do. My plan is to re-post
the patch to current@ for further testing before I commit it. After it
has had time to be sufficiently exercised in -CURRENT, I'll MFC it to
RELENG_5 (after 5.3-RELEASE), and RELENG_4. The feedback I've gotten
from those who reviewed the patch has been positive, but I want to take
it slow because of the critical nature of fsck.
> On Sun, 5 Sep 2004, Don Lewis wrote:
>> On 4 Sep, To: scrappy at hub.org wrote:
>>> 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
>>> 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.
>> Here's a patch that eliminates the zln list and adds two new inode
>> states to tag zero files and directories that have a zero link count. It
>> seems to work in the light testing that I have done, but it needs
>> further and review before it gets committed.
More information about the freebsd-current