Date: Fri, 6 Jun 1997 10:11:59 +0200 From: lada@ws6303.gud.siemens.at (Hr.Ladavac) To: jkh@time.cdrom.com, henrich@crh.cl.msu.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Extremely poor interactive response under heave SCSI load Message-ID: <199706060811.KAA00771@ws6423.gud.siemens.at>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 07:04:12 MET 1997 > Date: Fri, 6 Jun 1997 00:27:14 -0400 > From: Charles Henrich <henrich@crh.cl.msu.edu> > To: "Jordan K. Hubbard" <jkh@time.cdrom.com> > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: Extremely poor interactive response under heave SCSI load > Mime-Version: 1.0 > X-Operating-System: FreeBSD 2.2.2-RELEASE > X-Pgp-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F > X-Loop: FreeBSD.org > > On the subject of Re: Extremely poor interactive response under heave SCSI load, Jordan K. Hubbard stated: > > > > Has anyone else noticed that a system with a large mount of unused (hence > > > dis > > k > > > cache) ram while under heavy SCSI load (or not so heavy really, e.g: > > > > This has been a known bug for ages. If you really want to test it out, try > > running mkisofs on a large image and then try to do something; I first > > encountered this back in FreeBSD 2.0 days. ;-) > > > > I also doubt that the fix is trivial or John Dyson / David Greenman would > > have done something about it the first time I reported it back in December > > of 1994 (folks like Matt Dillon having also since reported on variations of > > it). > > There has to be some solution, forcing the scsi command queue to search for > alternate commands every so often or something.. It just sucks :) You're telling it :) The problem is extremely easy to reproduce if you have one of these PD drives and use them for backups. You will need a FFS on the PD media so that you can mount it. Then write to the PD. Since this operation is extremely slow, a nice amount of backlogged blocks will be made in cache--in fact, 16MB of RAM is more than enough-- especially if you do a dump to the PD. Now, my observations: 1) only the operations on the PD volume are slowed down. 2) sync returns immediately, but the access to the PD does not speed up. 3) it takes about 30 seconds for a cd to a directory on PD. Since it doesn't take much to achieve the above stall, and since the rest of the machine is unaffected, it might be relatively easy for someone with a PD drive to research the problem. Alas, I don't have a FreeBSD box any more--it has been commandeered away from me, Win95 got installed, and I don't have any access to FreeBSD boxen at all. /Marino > > -Crh > > Charles Henrich Michigan State University henrich@msu.edu > > http://pilot.msu.edu/~henrich >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706060811.KAA00771>