Date: Fri, 6 Jun 1997 11:40:05 +0200 From: lada@ws6303.gud.siemens.at (Hr.Ladavac) To: lada@ws6303-f.gud.siemens.co.at, luigi@labinfo.iet.unipi.it Cc: jkh@time.cdrom.com, henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Extremely poor interactive response under heave SCSI load Message-ID: <199706060940.LAA07518@ws6423.gud.siemens.at>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 11:39:13 MET 1997 > From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: Re: Extremely poor interactive response under heave SCSI load > To: lada@ws6303-f.gud.siemens.co.at (Hr.Ladavac) > Date: Fri, 6 Jun 1997 10:34:13 +0200 (MET DST) > Cc: jkh@time.cdrom.com, henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG > X-Loop: FreeBSD.org > > > > > > 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 > ... > > 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. > > I have dnot read the previous messages in this thread so I might be wrong, > but it sounds like a fair bw allocation among flows, much the same as > you have when you are on a slow ppp link which does not implement priorities, > and you run an ftp transfer in parallel with a telnet session. > > Solutions exist for this problems, i.e. separate the flows (easy for > tcp/udp connections since the headers clearly identify packets) at the > bottleneck, and serve the various queues in a round-robin fashion. > The network drivers do not work like this because it is unlikely that > long queues develops at a 10Mbit/s interface (but they do on a ppp liink, > so perhaps this ought to be done in the tun device -- I might work on > this in the next months). > > A similar approach could be used for scheduling disk writes assuming one > has a way to determine which writes are related. This might not be trivial . I wish it were only delayed writes...the reads are delayed as well. At first I thought the PD did not disconnect, but since the other mounted volumes weren't affected even though they are all on the same SCSI bus, I have given up on that train of thought. What might be possible is to change the strategy routine for od driver to give reads priority over writes since read is *much* faster than write on a PD. In fact, one could clone the od driver into the pd driver with changed strategy. The other possibility is to make FFS give priority to metadata reads in comparison to normal reads and writes. However, I don't know whether that is really the problem (no FreeBSD box, as previosly stated ): or if that can be done at all. Sounds non-trivial, though. /Marino > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706060940.LAA07518>