Date: Tue, 9 Mar 1999 15:58:07 -0500 (EST) From: tom@tomqnx.com (Tom Torrance at home) To: mjacob@feral.com Cc: chris@shenton.org, scsi@freebsd.org, tom@tomqnx.com Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Message-ID: <m10KTZn-000I4EC@TomQNX.tomqnx.com> In-Reply-To: <Pine.LNX.4.04.9903090711140.17778-100000@feral-gw> from Matthew Jacob at "Mar 9, 1999 7:13:37 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Yes- I added the code that tries to unload the tape if things get screwed > up- but some tapes don't eject. > > Let's get a sense from y'all- is this a bad idea? Frankly, dump and tar > and other backup programs are fantastically broken if they don't, at each > open, always either explicitly position to a known locatio, or get > position information and use that, or explicitly space to EOD. It seems to > me that if you've lost position information you should try and force the > tape out. > > -matt Howdy, Matt! This is a very well put argument for never doing ANYTHING at the driver level that would cause a backup program to lose position information. When you are working with a modern device driver, it is a temptation to do lots of nice sophisticated things - because you can. The thing is, though, that you are doing something that used to be done in hardware. They were dumb. Essentially, they still are, in that they have no idea what is happening at the application layer. There is a class of error that must be handled at the application layer because the device driver has no idea what to do about it. EOM is one of them. The shear fact that you have detected a reflective spot on the tape does not mean that the application has finished writing to it. Depending on the sophistication of the application, it may still have to write EOV (end of volume) labels or some such foolishness before the double TM is written. It definitely has to know that following the next open, it has to write beginning of volume label(s) before writing any data, if it is doing volume labels at all (e.g. optional with 'tar'). Even simple things - like a normal I/O error, the application would like to know about. If you "man dump" you will see that dump wants to know about them, as it will force EOM processing after a default of 30 I/O errors on a volume irrespective of the amount of tape used. I am very surprised that these issues are not explicitely addressed by RFCs or SCSI standards, or whatever. In the event that they are not, I recommend that you look at the code of some backup programs of some sophistication (amanda and dump, perhaps) and determine what their expectations are. Give them what they want, unless you have a very good reason to do otherwise. Alternatively, do not take actions that other drivers do not. Applications have a right to expect consistant interfaces to their media, no matter what hardware/os they are dealing with. In summary, I think it a very poor idea for the tape driver to take any unilateral action that would affect tape positioning. It is worthy of note that you are taking the action in instances where EOM has NOT occured. Just My Humble (very long-winded) Opinion... Cheers, Tom > > > > > On 9 Mar 1999, Chris Shenton wrote: > > > [Changed CC from hackers@ to scsi@ --chris] > > > > Matthew Jacob <mjacob@feral.com> writes: > > > > > What errors? And what 'does not honor'? I know that Tom Torrance claimed > > > this happened- which I can't reproduce. > > > > I posted them in the previous message. It was on a 3.1-STABLE system > > built from source cvsupped about 3 days ago. Here's what dmesg says: > > > > (sa0:ahc0:0:5:0): SPACE. CDB: 11 1 ff ff ff 0 > > (sa0:ahc0:0:5:0): ILLEGAL REQUEST asc:2c,0 > > (sa0:ahc0:0:5:0): Command sequence error > > (sa0:ahc0:0:5:0): unable to backspace over one of double filemarks at EOD- opting for safety > > > > This occurs just after a dump completes and says "closing device sa0", > > before the next dump begins. So it overwrites each dump file due to > > the rewind. > > > > I don't see the PREVENT/ALLOW messages that Tom cites, but he's right > > about not seeing the messages if you're using an Xterm; I missed 'em > > for a day. > > > > Is there anything I can do to help locate the source of the bug? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m10KTZn-000I4EC>