Date: Mon, 27 Sep 2004 10:18:54 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: scrappy@hub.org Cc: keramida@linux.gr Subject: Re: what is fsck's "slowdown"? Message-ID: <200409271718.i8RHIsrP032923@gw.catspoiler.org> In-Reply-To: <20040924160535.N43964@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 >>>> 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. >> >> 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. >> [snip]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409271718.i8RHIsrP032923>