Subject: Re: LFS on multi-processor systems
To: None <current-users@netbsd.org>
From: Brian de Alwis <bsd@cs.ubc.ca>
List: current-users
Date: 09/18/2007 16:22:30
I decided to try using LFS on an MP laptop [*].  This was on a kernel
from 4.99.31.  I used the defaults from sysinst of a 16k block size and
2k fragment size, and 1MB segment size.

I experienced pretty frequent hard hangs.  I tried boosting kern.maxvnodes
to 131072 and 262144, which overall seemed to lengthen the amount of time
before a crash, but it would still periodically hang almost right away.

I once got a "panic: lfs_rescount".

The best way to cause a hang was to do a build.sh while running X and
Firefox.

Watching vmstat -Wm, it looked like the various lfs inode pools were only
increasing (I saw the numbers go up to 233k), with nothing being given
back.  This contrasted sharply with the ffs inode pools which always
fluctuated around 4100.  I had wondered if the hangs were related to
this number hitting the maxvnodes, but then experienced 2 hard hangs
in succession just shortly after a reboot, when the numbers were well
below maxvnodes.  And I'm now reinstalling onto an FFS filesystem, but
seeing the same behaviour from the ffs inode pool as I saw with the
lfs inode pools.

It sure was nice having near-instantaneous fscks! :-)

Oh, I just saw from Blair's message that he used an 8k block size...
Maybe I'll give that a try.

[*] My FFS filesystem was recently hosed: my battery was running
    low, and the machine hung hard when I plugged in the adapter.
    On reboot, the filesystem was hosed, and fsck made many repairs.
    Subsequent fscks reported the filesystem as clean, but reinstalling
    the OS would result in panics about dup allocs.

-- 
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli