Date: Wed, 22 Dec 1999 09:37:55 +1030 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com>, Wilko Bulte <wilko@yedi.iaf.nl> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, FreeBSD current users <FreeBSD-current@FreeBSD.org> Subject: DLTs, disconnection and hangs--solved (was: Recent current hangs frequently for 1 to 2 seconds.) Message-ID: <19991222093755.A60684@freebie.lemis.com> In-Reply-To: <199912212004.MAA80595@apollo.backplane.com> References: <199912210108.RAA62736@apollo.backplane.com> <19991221100727.A52224@yedi.iaf.nl> <19991219143759.C465@freebie.lemis.com> <199912190416.UAA01125@apollo.backplane.com> <19991221095213.L440@freebie.lemis.com> <199912210019.QAA62510@apollo.backplane.com> <19991221110148.N440@freebie.lemis.com> <199912210108.RAA62736@apollo.backplane.com> <99Dec21.123129est.40326@border.alcanet.com.au> <199912212004.MAA80595@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 21 December 1999 at 10:07:28 +0100, Wilko Bulte wrote: > On Mon, Dec 20, 1999 at 05:08:27PM -0800, Matthew Dillon wrote: >>> It's possible you might be on to something. I've been running iostat >>> at 1 second intervals, and during the last hang I saw: >>> >>> tty ad2 da1 sa1 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 36 142 7.75 95 0.72 0.00 0.00 0 10.00 27 0.27 29 0 9 1 61 >>> 21 142 8.00 69 0.54 0.00 0.00 0 0.00 0 0.00 6 0 1 0 93 >>> 37 143 8.00 44 0.34 0.00 8.00 3 0.00 0 0.00 5 0 1 1 94 >>> 41 142 1.76 106 0.18 16.00 5.25 4 10.00 14 0.13 24 0 18 0 57 >>> 15 143 1.98 87 0.17 0.00 0.00 0 10.00 16 0.15 30 0 15 2 54 >>> >>> Note that the stop in tape activity corresponds with a start in disk >>> activity. I'll keep an eye on that and see if it looks the same the >>> next time. >> >> Tape drives may: >> >> * Not support disconnection (the SCSI bus is locked through the entire >> write sequence), or only partially support disconnection but run the >> bus so slowly that other devices are left out in the cold. > > DLT drives do support disconnect/reconnect. > >> * Implement a crappy SCSI command stack that breaks down when > > So do may disks :) > >> higher-speed operations are running on the same bus (e.g. the disks >> with their higher synchronous transfer rates). >> >> * Not properly terminate the SCSI bus (especially when mixing >> bus architectures. For example, a tape drive may only >> half-terminate a wide SCSI bus. Never use a tape drive to >> terminate a SCSI bus, not even an older SCSI bus. > > As has been discussed many times already: use external terminators attached > to the cable. SCSI termination is not difficult, it is just made that way > by some :( Who said this? There is nothing magic about SCSI cabling. There are sound technical reasons why they occasionally require the sacrifice of a young goat. >> * Introduce too much noise onto the SCSI bus due to bad design. > > Does not apply to DLT drives that I've seen. > > A more interesting question would be if the DLT drive has a more or less > recent firmware loaded. The discussion's worthwhile, but remember that I have had this when the DLT wasn't running as well. How do I find the firmware release? Is that the supplementary information (CC1E) in the dmesg output? sa1 at ahc0 bus 0 target 3 lun 0 sa1: <Quantum DLT4000 CC1E> Removable Sequential Access SCSI-2 device sa1: 10.000MB/s transfers (10.000MHz, offset 15) Anyway, I think I found the problem. I had been reconfiguring the disks, and in the process I removed a disk with swap on it and added another. The primary swap on the system disk is 50 MB, the swap I took away was 256 MB, the swap I added was 512 MB. But: I forgot to change /etc/fstab. So I was running with swap near full, and it wasn't until I realised it and mounted the other swap space that things started to improve. In the process, it used a further 10 MB of swap without any obvious increase in the number of processes (I was mainly running mail and editors). In the meantime I had noticed that the hangs were, for the most part, in biowr. I'm fascinated that the system was able to run without adequate swap without showing anything worse than poor performance. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991222093755.A60684>