Date: Mon, 5 Mar 2001 00:06:08 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Walter Hop" <walter@binity.com>, "FreeBSD Questions" <freebsd-questions@FreeBSD.ORG> Subject: RE: tar just doesn't want to be KILLed Message-ID: <008601c0a54b$22a45860$1401a8c0@tedm.placo.com> In-Reply-To: <139127338372.20010305022456@binity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Walter Hop >Sent: Sunday, March 04, 2001 5:25 PM >To: FreeBSD Questions >Subject: tar just doesn't want to be KILLed > > >Hi *, > >am I right in assuming that... > >1. there's no way to get rid of an instance of tar (that's probably > waiting for some IO to complete? Yes and no - it depends. If the tapedrive is on the same SCSI bus as the disk, then yes, you are hosed. However, if the tapedrive is on a separate SCSI card - particularly if it's an external tapedrive - then no. Often, power-cycling the tapedrive will get it unstuck. It's precisely this reason that for my production servers, all tapedrives go on separate SCSI cards, and all are in external cases. >2. there's no way to umount a mount point held by such a process? > >[If so, I would be interested to hear about the design considerations >that led to this! I guess that tar never returns from a syscall and can't >react to the signal? Correct. > Hasn't anybody tried to implement a workaround for >this in all those years?] > Yes. The problem is that under the UNIX architecture, the device driver is what is responsible for this. On disk I/O, if the SCSI device driver (I'll ignore ATAPI here but the principle is the same) sends a command to the disk and doesen't get a response then it's safe to assume that after 30 seconds, something is wrong and we need to reset the SCSI bus or do something like that to shake free the hardware. After all, your not going to take 30 seconds to write a byte of data to the disk unless something is seriously screwed. On tape I/O, however, if the SCSI device driver sends a command to the tape drive unit and doesen't get a response, then how long are you supposed to wait until deciding that the unit is not responding? What if it's rewinding a tape? What if you sent a "format media" command to the tape drive, and this particular model was designed by an engineer that felt that format media meant the drive needed to write zeros the entire length of the tape? What if you write to the tape drive, and just then the drive runs out of tape and ejects the tape, and sits there waiting for the next one to be inserted? After all, unlike a disk, the tape device does NOT know how much physical tape is on a cartridge and so does not know exactly how much data it can write to the tape. (At least, most drives don't) Certainly, you could sit down with the tape driver and put in some timers that would start shaking the SCSI bus that the tape is attached to, if the tape drive goes away and hides. But, sure as shooting, your going to screw up someone's setup, and get a bunch of complaints. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008601c0a54b$22a45860$1401a8c0>