--XuV1QlJbYrcVoo+x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Konrad has been busy and making promising-sounding changes, and I had
a moment of waiting time, so I thought I'd try LFS again.

My usual test (rsync's of htdocs,pkgsrc,src,xsrc into a vnd-hosted
LFS) doesn't get very far now; the writing rsync gets stuck on WCHAN
"buffers" and the process hangs (until i ^C it).  This happens with or
without the cleaner running, so it's not contention there, and with
only a single writing process into the LFS (ie, only 1 rsync at a
time). It happens pretty quickly, too; df says there are 7325 iused in
the LFS after a couple of rsync runs/hangs.

The same test a few days ago produced what was possibly a worse
manifestation of the same or similar problem; apparently there was a
race-to-root of vnode locks, fairly quickly hanging all disk-using
processes before I had a chance to observe what was waiting on what.
I can't reproduce that today, though perhaps it might happen with
parallel rsyncs if they got far enough :)

fsck_lfs is certainly fast now, though with such an empty fs it's
impossible to comment on real improvement under similar circumstances
as before.

Still staying tuned :)

--
Dan.


--XuV1QlJbYrcVoo+x
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iD8DBQFCY1EHEAVxvV4N66cRAs3OAKCCTUs5CmzWvo1lpPDFRSiYCawVhACghq8Q
iCm0wP0usmDI48I6qhUdDHg=
=eVmZ
-----END PGP SIGNATURE-----

--XuV1QlJbYrcVoo+x--