Re: NIS client performance seems very poor under network load
On Fri, Sep 28, 2001 at 02:34:20AM -0400, Brandon D. Valentine wrote: On Thu, 27 Sep 2001, Jordan Hubbard wrote: Progress in these types of situations nearly always comes from people with enough self-interest in the problem area to actually commit to working on it. Rather than asking for people who have written an autofsd to step forward, why not instead start working on this project yourselves and ask for volunteers to HELP you address the problem? That's taking on the problem from the right end, IMHO. I agree wholeheartedly Jordan. My self-interest in the problem has at least motivated me enough to go reading the applicable source but I've not had time lately to work on actual patches. I've got a lot of irons in the fire at the moment, especially with students being back around (I'm a sysadmin at Vanderbilt University) Those students ought to be good for something. but when things quiet down I do intend to work on this. At the moment I sit daily in front of an SGI Indigo2 running IRIX because it's better than Linux and integrates quite well with our environment. I really want a FreeBSD workstation on my desk, so I'll likely end up writing the patches just so I can get that FreeBSD workstation integrated. But, no promises on a timeframe so if someone else wants to get started now, then by all means charge right ahead with it. Something I really liked about Irix was its userland mediad. Used to handle floppies and CDROM. Foreign filesystems were handled in userland daemons launched by medaid. This protected the kernel against corrupt filesystems. Made auto detection and mounting easy. I had cut some CD-R's with over 50,000 files and found I could increase the daemon's cache to 1MB or 2MB and greatly increase my access speed to the CDROM by caching the metadata. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
S ren Schmidt writes: There is NO support for bad144, if your disk is bad, ditch it, it has already outgrown its internal spare sectors, and is dying. Speaking of which, is there any portable way to monitor bad block lists on ATA drives? And the S.M.A.R.T. stuff that some vendors advertise? -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE DMA works, I'll be a...
Matthew Dillon writes: Well I'll be a cat in a hat! IDE DMA actually works on my old PPro-200 box with a new IDE drive! A solid 8 MBytes/sec out of the thing. My poor old 4 GB SCSI barracuda could only do 4.3 MB/sec. Time to replace the barracuda, I think. What did you use to measure? Bonnie? For kicks time something interesting such as a CVS checkout with both source and destination on the same drive. While the burst thruput is higher am curious what the effect on real world seeks is. 4G Barracuda that only does 4.3 MB/sec? An ST15150[NW]? My narrow 5400 RPM IBM DCAS has been faster than 7200 RPM ST15150-either-N-or-W on SGI, Mac, and FreeBSD hosts. Haven't done the same tests but ST34173's are faster than the ST15150's. HD on my good system is an IBM DCHS09. Haven't checked recently but bonnie used to peak at around 8.5 MB/sec. In practical applications such as a CVS checkout or sorting mail thru slocal I notice the practical limit seems to be 80 to 100 tps as reported by systat -v. And at that rate its often doing only 600k/sec (small transaction blocksize of 4k). Have seen it reach 120 to 140 on occasion. And once it it 150. Caught this just now in a make release, it just doesn't go much faster than 143 tps: Discs fd0 da0 sa0 sa1 pass0 pass1 pass2 intrn KB/t 0.00 9.49 0.00 0.00 0.00 0.00 0.00 8337 buf tps 0 143 0 0 0 0 0 8461 desiredvnodes MB/s 0.00 1.32 0.00 0.00 0.00 0.00 0.00 18768 numvnodes Recently I enabled optional flags on a 2.2.7 system's wd driver. For lack of any better guess, used 0x80ff. Got a noticable improvement on a Gateway P-133 and the OEM 1G HD but haven't bothered to attempt accurate measure. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot single with new loader?
Stefan Esser writes:
On 1999-01-11 23:11 +0100, Ollivier Robert robe...@keltia.freenix.fr wrote:
Beware of something that can be deadly for a make installworld. When
using SU, space freed by rm takes a bit more time to be taken into
account
and you can fill / or /usr up because the space recovered by install
is not yet freed.
It happened to me a few times for /usr and one time for /. Having
/bin/sh with a 0-byte size is not good for booting :-)
Yes, that forced me to turn off soft-updates for the / file system.
I was lucky not to have tried rebooting the system, since then there
would not have been a chance to invoke a shell (and lots of other
binaries that had not made it to /bin and /sbin) from within /usr/obj !
Maybe something like this was happening to me yesterday. I too have
softupdates on root and everything. Rebooted more times yesterday than
ever messing with a soundcard and updating kernel. 4 or 5 times
/etc/nologin did not get unlinked before the system halted. Forced me to
login as root to remove the troublemaker manually. The problem always
happened when I issued shutdown as myself (not root) but as a member of
group operator. But has now cured itself possibly due to replacing /etc/
login.{conf,access} and /etc/rc* with current versions. This is what /
etc/nologin contained altho shutdown -r now was the command used:
NO LOGINS: System going down at 18:00
--
David Kelly N4HHE, dke...@nospam.hiwaay.net
=
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
nologin file (was: Re: Symbios 875 activity LED?)
Probably belongs in -current rather than -scsi. Ollivier Robert writes: According to David Kelly: member of group operator) that /etc/nologin was not being deleted. It has been moved recently to /var/run/nologin: Noticed that in shutdown.8 (keep trying to type sendmail here). I see /etc/login.conf has the default user set to honor :nologin=/var/run/nologin:\ Apparently updating my login.conf cured my nologin lockout problems due to the above line as: nospam: [1009] ls -l /etc/nologin -rw-r--r-- 1 root wheel 41 Jan 16 21:27 /etc/nologin nospam: [1010] ls -lu `which shutdown` -r-sr-x--- 1 root operator 149920 Jan 16 20:32 /sbin/shutdown* nospam: [1011] Now that's interesting. /etc/nologin is newer than shutdown was last used. Think that's because I've started using control-alt-delete of recent. What does control-alt-delete launch that would create the above nologin file as I need to update that too? But am still concerned whatever it is is not unlinking it before system halt. -=-=- asami 1999/01/11 01:07:42 PST Modified files: etc login.conf rc include paths.h sbin/shutdownshutdown.8 usr.bin/loginlogin.1 Log: Move nologin from /etc to /var/run. This means one less file that has to be written to /etc. The only essential change is in paths.h, so any third-party software written correctly will pick it up in the next rebuild. -=-=- Arrgh. Now I see it. My /usr/include/paths.h is from November 8. This accounts for shutdown. So what else creates /etc/nologin? Short of a new make world I need to update paths.h and build a new shutdown. But what else? And is there a way to extract the above commit message out of cvs? Do I need to cvsup something special other than src-all? Only recently subscribed to cvs-all (and -current) and wonder if that's the only place to get it? -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CTM CVSUP differences
On Fri, 15 Jan 1999, Boris Staeblow wrote: Hello, Is it possible that there are slight differences between the CTM's and the real world ? Yes, there are differences. You can't get the optional security stuff via CTM while you can with CVSUP. Last time I tried it, this means you can't do a make release as Jordan's release Makefiles can't handle a total absense of that stuff (eBones? whatever its called). While you can download the missing security stuff, make release wants to check it out of your local cvs archive. I haven't found a way to put it there but I'm a cvs novice. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CTM CVSUP differences
Ollivier Robert writes: According to David Kelly: via CTM while you can with CVSUP. Last time I tried it, this means you can't do a make release as Jordan's release Makefiles can't handle a total absense of that stuff (eBones? whatever its called). It is available on internat.freebsd.org with CTM... And its legal for me to import it to the US? Thought something like that had to be available but it didn't come up last time I mentioned it. -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
