a sync on the block device for the filesystem. That allows it to push the
bitmap blocks before the inode blocks which greatly reduces the number of
inode rollbacks that need to be done.
simple enough to be trusted.
Add account management functionality to the pam_unix module.
These changes should make it possible to use PAM in some ports.
Submitted by: Max Khon <fjoe@iclub.nsu.ru>
files at once on a filesystem running soft updates. The root of
the problem is that soft updates limits the amount of memory that
may be allocated to dependency structures so as to avoid hogging
kernel memory. The original algorithm just waited for the disk I/O
to catch up and reduce the number of dependencies. This new code
takes a much more aggressive approach. Basically there are two
resources that routinely hit the limit. Inode dependencies during
periods with a high file creation rate and file and block removal
dependencies during periods with a high file removal rate. I have
attacked these problems from two fronts. When the inode dependency
limits are reached, I pick a random inode dependency, UFS_UPDATE
it together with all the other dirty inodes contained within its
disk block and then write that disk block. This trick usually
clears 5-50 inode dependencies in a single disk I/O. For block and
file removal dependencies, I pick a random directory page that has
at least one remove pending and VOP_FSYNC its directory. That
releases all its removal dependencies to the work queue. To further
hasten things along, I also immediately start the work queue process
rather than waiting for its next one second scheduled run.
instead of just UDP; an alternate protocol is specified by '-P proto'.
This is useful for finding routers that are blocking packets based on
IP protocol. New handlers can be added fairly easily to do protocol-
specific things.
in libstdc++.
Until I have a chance to look at what that problem is and to carefully consider
the upgrade issues of turning it back on at a later date if we leave it turned
off for any extended peroid of time.
While I have yet to hear of any problems with us using thunks. The EGCS
mailing list notes some have problems with it and not using them are a
safer default. People wanting to use them, can set the appropiate
compiler flag.
Nik Clayton
Andrey A. Chernov
Doug Rabson
Julian Elischer
John Polstra
David E. O'Brien
Bill Fenner
Joseph Koshy
Kirk McKusick
Archie Cobbs
Peter Wemm
Luoqi Chen
Mark Murray