>Number:         35187
>Category:       kern
>Synopsis:       Certain file operations--such as chown--take inordinate amounts of time on LFS
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 05 06:25:00 +0000 2006
>Originator:     Blair Sadewitz
>Release:        4.99.5 as of dec 3-4
>Organization:
Organization?  Maybe next year ...
>Environment:
NetBSD amd64 4.99.5
>Description:
root    1128 98.0  0.1   172 1088 ttyE1 D     1:00AM 13:19.82 chown -R blair pkg
src

This process has been running for virtually the same amount of time as the CPU time column indicates.  All I'm doing is chown -R blair:wsrc /usr/pkgsrc.  On ffs, this would be of no consequence.

I find LFS advantageous for a number of reasons, but I'm hesistant to use it if things such as this, the tail end of a pax/tar job, chmod, etc. takes this much CPU time.  I have a 3GHz Pentium D, and if it weren't for the other core, my machine would be virtually unusable, at least interactively.

Yay, it finally finished 20 minutes later! ;)

What is going on here?  I have tried setting vfs.lfs.pagetrip as instructed, as well as different buffer queue strategies, etc, all to no avail.
Obviously, this problem is beyond my comprehension.  I can't be the only one annoyed by this, especially considering that LFS shines in situations (such as large RAIDframe arrays) where one may want to do operations like this on 2TB of files.
>How-To-Repeat:
Perform filesystem metadata operations on many files in an LFS filesystem.
>Fix:
I wish I knew, and if I ever meet the person who fixes this, you can have a few beers on me. ;)

Please ignore the last incomplete PR I filed, that happened because my keyboard response was lagged due to the aforementioned chown process.