Re: [Mtx-general] mtx failure report, any suggestions on a fix?

[Steve L. <so...@Le...>]

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