Re: [Mtx-general] mtx failure report, any suggestions on a fix?
Brought to you by:
elgreen,
robertnelson
|
From: Steve L. <so...@Le...> - 2003-07-01 00:53:38
|
On Saturday, June 28, 2003, at 10:09 PM, Eric Lee Green wrote: > On Saturday 28 June 2003 05:21 am, Steve Lidie wrote: >>> Try 'mt -f /dev/nst0 offline' , then wait at least fifteen seconds, >>> before >>> trying to use 'mtx unload'. That'll fix you. >> >> tkjuke can handle this transparently - I've just added an >> EJECT_BEFORE_UNLOAD configuration option. I have two questions: >> >> In my testing no delay is required after the offline command, so is >> your 15 delay really required? > > It's actually a SCSI driver issue. On Linux, 'mt offline' will wait > for the > tape to rewind, then eject, before it returns. On some other operating > systems, it will return immediately. On Solaris in particular beware of OK, this means I also need a delay for the offline to complete. All my devices are either on IRIX (no offline required) or Linux (offline doesn't complete until the media is really offline). So, I must assume this "offline delay" is/may be a function of the current tape position - i.e, a tape at EOI will take longer to go offline tham one positioned towards the beginning of the tape. True? > mixing their equivalent of 'mt' (I don't recall its name) and > 'tapeinfo', > because once you run 'tapeinfo', the Solaris tape driver basically > throws up > its hands and dies. For the port of the BRU-Pro tape server to Solaris > (which > was never released by the company that bought the technology, but it > once > existed), we basically had to write our own tape driver. > >> Do I even need to make the offline command optional, can tkjuke just >> do >> the offline is all cases? > > It must be optional, because on HP DDS autochangers, 'mt offline' > unloads the > tape currently in the drive -- then loads the next tape. Thus if you > have > tape 2 in the drive, do 'mt offline', then 'mtx -f /dev/sg1 unload 2', > you'll > get a SCSI error because tape 2 is already unloaded and in its slot, > and tape > 3 is in the drive now, and you can't unload tape 3 into slot 2 because > tape 2 > is there. > > With Seagate DDS changers, 'mt offline' unloads the tape currently in > the > drive, then puts it away into its shelf in the magazine. 'mtx -f > /dev/sg1 > unload 2' thus would be a NOP, since it's already put away. > > In general, there are three possible behaviors for 'mt offline': > > 1) It ejects the tape, but does not put it away. > 2) It ejects the tape, and puts it away into its original slot > 3) It ejects the tape, puts it away into its original slot, then loads > the > next tape. > > In the auto-detect code for BRU-Pro I tested for this by loading a > tape, then > doing 'mt offline', then checking 'mtx status' to see what happened. I > suggest that you issue 'mt offline' only for case 1. For cases 2 and > 3, all OK, a user defined configuration option. > sample loaders that I tested would work just fine with 'mtx unload' > without > an 'mt offline'. > FWIW, current tkjuke has just been bumped to version 2.x - it's now a master/slave program that displays multiple jukeboxes in a NoteBook widget, with each tab representing an individual jukebox. > -- > Eric Lee Green mailto:er...@ba... > Unix/Linux/Storage Software Engineer needs job -- > see http://badtux.org for resume |