LTO anyone

SGI hardware problems, solutions, tips, hacks, etc.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Mon Jun 04, 2012 3:40 pm

As few brief followup notes in reference to using an LTO autoloader under IRIX.

I ran across a conversation on tek-tips.com entitled "xfsdump and LTO autoloaders" that sees to suggest it may be possible to use and control an (LTO) autoloader under IRIX/xfsdump: http://www.tek-tips.com/viewthread.cfm?qid=764503 (that link has been been down about half the time I tried it, if anyone else has access problems I've attached a quote of the contents as a text file).

The method suggested in the reply was to have xfsdump call a script that controls the autoloader. It would appear that script uses the IRIX program "stacker" as a means to control the autoloader.

Since the stacker man page only mentions devices several generations removed from an LTO-based tape autoloader, the safe assumption is that it won't work (which was the same erroneous assumption previously made about /var/sysgen/master.d/scsi and kernel configuration files for tape drives larger than DDS4 or DLT IV).

Bjornl, *if* you have the time and inclination to experiment, I for one would appreciate your effort to provide clarification one way or the other (just trying the MAKEDEV tape /autoconfig routine followed by a reboot and then "stacker -D... -c <device as listed in /dev/scsi>" would probably tell the story).
Attachments
xfsdump_and_LTO_ autoloaders.txt
(1.67 KiB) Downloaded 36 times
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

User avatar
jan-jaap
Donor
Donor
Posts: 4881
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands
Contact:

Re: LTO anyone

Unread postby jan-jaap » Tue Jun 05, 2012 1:15 am

recondas wrote:Jan-jaap mentioned using a script (under linux) to cycle the loader in this post - perhaps he'll catch this and offer his opinion on doing the feasibility of doing the same under IRIX.


Unfortunately, the last time I used the autoloader was nearly 10 years ago, I sold the autoloader years ago, and upgraded the server twice, so all relevant scripts are long gone.

I found back a little patch to xfsdump to support autoloaders. Not sure how relevant it is today, and not very useful on IRIX.

IIRC, it worked like this:

* Create a script to unload, cycle and load the next tape. You can test this standalone, without xfsdump. I believe you use 'mtx' for this (on Linux).
* Call xfsdump with a media size argument and the changer script as arguments. Use a small media size to test the media changer script.
* Add some magic to keep full and incremental backups on separate tapes.
* Sit back and enjoy!

My problem with the autoloader was that it (being a SCSI device) had to be turned on 24/7, using ~ 100W, just to run a full backup every week and a small incremental nightly backup. It was also rather noisy and not terribly reliable.

These days I use an external eSATA disk box to do server backups. The backup script powers up the disk box (USB controlled power outlet!), mounts the disks, does it's thing, and switches everything off again. Much faster, quieter, less power hungry, more reliable and I can replace it quickly if something breaks.
Attachments
xfsdump-mediachange.diff.gz
(937 Bytes) Downloaded 23 times
:PI: :Indigo: :Indigo: :Indy: :Indy: :Indy: :Indigo2: :Indigo2: :Indigo2IMP: :Octane: :Octane2: :O2: :O2+: Image :Fuel: :Tezro: :4D70G: :Skywriter: :PWRSeries: :Crimson: :ChallengeL: :Onyx: :O200: :Onyx2: :O3x02L:
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Tue Jun 05, 2012 7:49 am

recondas wrote:Since the stacker man page only mentions devices several generations removed from an LTO-based tape autoloader, the safe assumption is that it won't work

You might want to re-read that stacker man page. It lists a few devices by name and says "and all tape robots that conform to the SCSI-2 Medium Changer command set." (Last line of the first paragraph.) That means it should work with anything reasonably modern in addition to the few ancient drives it names that pre-date the standardized command set.

I've got Dell and Exabyte autoloaders that I could hook up to one of my IRIX boxes and do some testing of the media changers...but not until the weekend. I'll try to remember to do that and report my findings here.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Tue Jun 05, 2012 11:04 am

jpstewart wrote:You might want to re-read that stacker man page. It lists a few devices by name and says "and all tape robots that conform to the SCSI-2 Medium Changer command set." (Last line of the first paragraph.)
You're preachin' to the choir on that one. I think there's a real good chance it will work - that's way the rest of that sentance read "which was the same assumption previously made about /var/sysgen/master.d/scsi and kernel configuration files for tape drives larger than DDS4 or DLT IV".
jpstewart wrote:I've got Dell and Exabyte autoloaders that I could hook up to one of my IRIX boxes and do some testing of the media changers...but not until the weekend. I'll try to remember to do that and report my findings here.
Thanks - since there isn't anything definitive in TechPubs (or anywhere else I could find), that's probably the only way we'll know one way or the other.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Tue Jun 05, 2012 1:39 pm

recondas wrote:I think there's a real good chance it will work

Ah, I think I mis-interpreted your earlier remark:
recondas wrote:the safe assumption is that it won't work

to mean "the most likely outcome is that it won't work". Apparently that's not what you meant by "safe assumption". Sorry about the confusion.

Anyway, I'll try to remember to test my autoloaders on the weekend. If I don't post results in this thread by Monday, somebody start nagging me for results. :lol:
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Tue Jun 05, 2012 4:32 pm

jpstewart wrote:Ah, I think I mis-interpreted your earlier remark.... Sorry about the confusion.
Looking back at that (run-on) sentence, I think I can lay claim to *all* of the recent confusion, so that apology should rightfully be mine. :D

In any case, thanks for your offer to extend the available knowledge on IRIX tape backups.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Sun Jun 10, 2012 11:05 am

And the results are in: stacker works just fine with both of my autloaders.

The LTO loader is made by Seagate but badged as a Gateway (and is identical to the Dell Powervault 122t and HP Storagworks 1/8 Autoloader, among others IIRC). Here's how IRIX sees it:

Code: Select all

# scsicontrol -i /dev/scsi/sc1*
/dev/scsi/sc1d5l0:  Jukebox       SEAGATE LTO LDR CLL1600 S17r
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d6l0:  Tape          SEAGATE ULTRIUM06242-XXX1608
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:  16bit synch
Device is  ready

# stacker -c /dev/scsi/sc1d5l0
/dev/scsi/sc1d5l0: 1 drive(s), 8 slot(s), 1 robot(s), 0 port(s)

The other is an Exabyte EZ17 Autoloader with a VXA-2 tape drive. I didn't try to write to the VXA tapes under IRIX since my VXA drive isn't working well under any OS. (Although after 8 years of daily backups, it's death wasn't entirely unexpected!) But the robot still works just fine. IRIX reports:

Code: Select all

# scsicontrol -i /dev/scsi/sc1*
/dev/scsi/sc1d5l0:  Jukebox       EXABYTE Exabyte EZ17    1.11
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d6l0:  Tape          EXABYTE VXA-2           2153
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:  16bit synch
Device is  not ready

# stacker -c /dev/scsi/sc1d5l0
/dev/scsi/sc1d5l0: 1 drive(s), 7 slot(s), 1 robot(s), 0 port(s)

Both autoloaders show up identically in the IRIX hinv output:

Code: Select all

Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
  Jukebox: unit 5 on SCSI controller 1
  Tape drive: unit 6 on SCSI controller 1: unknown

(PROM-level hinv simply reports "SCSI Device" instead of "Jukebox".)

Both autoloaders could load and unload tapes in any order with stacker -l/-u as expected, and scsicontrol would report "Device is ready" when a tape was loaded, and "Device is not ready" without media in the drive.

If I'm interpreting things correctly, it's the "ANSI vers 2" part in the scsicontrol output that identifies them as SCSI-2 compliant drives which stacker knows how to talk to. I'd expect any tape autoloader reporting that to work.

Note that these are simple, single-drive autoloaders. I don't have a fancy tape library with multiple drives and special tape input/output ports to test on, although stacker certainly seems to support those features, too.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Sun Jun 10, 2012 1:40 pm

jpstewart wrote:And the results are in: stacker works just fine with both of my autloaders.
Nicely done! Have you had the opportunity to try a back up? If you don't have an IRIX kernel configuration file for the Seagate LTO tape mechanism in your loader, I think there's a good chance you could use the info in the the wiki article to modify the Certance kernel config file (listed earlier) - at one time Certance was Seagate.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Mon Jun 11, 2012 7:49 am

recondas wrote:Have you had the opportunity to try a back up?

No, I didn't bother. It seemed like you'd already covered a wide array of LTO drives in your writings, so I didn't see the need to duplicate your work.

I was mainly trying to give bjornl some encouragement to try his tape library. Between your LTO kernel configurations and the stacker utility, I fully expect it to work as well as my autoloaders did.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Mon Jun 11, 2012 4:02 pm

Umm...I got caught up in the hardware aspect of it all, and I forgot to address bjornl's software inquiry:

bjornl wrote:Any software recommendation? Amanda? I don't think cpio or tar will can handle the automatic changer.

Actually GNU tar will handle the changer robot. Use the -F option to specify a shell script which basically only needs to run "stacker -u $x; stacker -l $x+1". (You'll probably need to store $x in a temp file somewhere so it can be retrieved each time the script runs. It's slightly easier with mtx on Linux where you can just run "mtx next".)

Whether or not you actually want to use GNU tar on an IRIX machine is a different question entirely!
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

User avatar
bjornl
Posts: 339
Joined: Tue May 09, 2006 11:55 am
Location: Sweden

Re: LTO anyone

Unread postby bjornl » Sun Jun 17, 2012 10:37 am

Finally I have had time to do some tinkering with the LTO library. I connected it to a O2 with IRIX6.5.30m, and began testing.
Here's what I have found.

When I just added the following to the /var/sysgen/master.d/scsi I got a lot of errors with the autoconfig.

Code: Select all

   { DATTAPE, TPDAT, 2, 7, "HP", "Ultrium", /*LTO-1*/, 0, 0, {0},
     MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_COMPRESS|MTCAN_PREV|
       MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
       MTCAN_SILI|MTCAN_SEEK|MTCAN_CHTYPEANY,
     /* minimum delay on i/o is 4 minutes, because when a retry is
      * performed, the drive retries a number of times, and then
      * rewinds to BOT, repositions, and tries again. */
     40, 5*60, 20*60, 20*60, 3*3600, 512, 512*512,
     tpsc_default_dens_count, tpsc_default_hwg_dens_names,
     tpsc_default_alias_dens_names,
     {0}, 0, 0, 0,
     0, (u_char *)0 },
I had to remove '/*LTO-1*/,' in the first row and I just put it above the config info (except for the ',').
After that autoconfig worked fine. I had the same results of 'hinv' and 'mt status' as recondas before and after autocofig.
Even though there are two tape drives I only get one set of information with 'mt status', I thought I would get information on both.

Manually loading a tape (via the library's front panel) and doing a backup worked fine, but it seems that I have to load both drives
with tapes for the backup to work. Otherwise I get a 'NOT READY' message.

A full system backup with IRIX GUI for cpio took about 26 minutes for 3.2Gb which is very slow if recondas did 60Gb in 33 minutes.
This must be because of the much slower SCSI interface of the O2, or the ancient 4Gb drive I was backing up ;)
I tried to do a backup on both drives at the same time. I could not get two GUI backups going at the same time, nor two tar sessions,
but one GUI backup and one tar worked. Same backup, full system, simultaneous to two tapes took about 37 minutes.

There was some strange things with the devices. Sometimes I had one /dev/rmt/tps1d1v and one /dev/rmt/tps1d2v and later
one /dev/rmt/tps1d1v and one /dev/tape (which is a symbolic link to /dev/rmt/tps1d2v).

When I ran tar, I could not decide which device to use. Even if I type tar cv /dev/rmt/tps1d1v it tried to use /dev/tape which of
course was drive number 2.
With the GUI (cpio) it used the drive I selected.

I haven't found out about 'stacker' yet. I seem to have a problem with the hinv. I reports 13 jukeboxes when there is only 1.
I suspect stacker gets confused, because I can't do stacker -l/-u and therefore I can't try any scripts yet.

Code: Select all

CPU: MIPS R12000 Processor Chip Revision: 2.3
FPU: MIPS R12010 Floating Point Chip Revision: 0.0
1 270 MHZ IP32 Processor
Main memory size: 256 Mbytes
Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
FLASH PROM version 4.18
Integral SCSI controller 0: Version ADAPTEC 7880
  Disk drive: unit 2 on SCSI controller 0
  CDROM: unit 4 on SCSI controller 0
Integral SCSI controller 1: Version ADAPTEC 7880
  Tape drive: unit 1 on SCSI controller 1: DAT
  Tape drive: unit 2 on SCSI controller 1: DAT
  Jukebox: unit 3 on SCSI controller 1
  Jukebox: unit 4 on SCSI controller 1
  Jukebox: unit 5 on SCSI controller 1
  Jukebox: unit 6 on SCSI controller 1
  Jukebox: unit 7 on SCSI controller 1
  Jukebox: unit 8 on SCSI controller 1
  Jukebox: unit 9 on SCSI controller 1
  Jukebox: unit 10 on SCSI controller 1
  Jukebox: unit 11 on SCSI controller 1
  Jukebox: unit 12 on SCSI controller 1
  Jukebox: unit 13 on SCSI controller 1
  Jukebox: unit 14 on SCSI controller 1
  Jukebox: unit 15 on SCSI controller 1
On-board serial ports: tty1
On-board serial ports: tty2
On-board EPP/ECP parallel port
CRM graphics installed
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A3 revision 0
Video: MVP unit 0 version 1.4
 with no AV Card or Camera.
Vice: TRE
Cables and terminators are correct as far as I can tell, so why does this happen?

It results in the following

Code: Select all

# scsicontrol -i /dev/scsi/sc1*
/dev/scsi/sc0d2l0:  Disk          SGI     SEAGATE ST34572W0878
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:  16bit synch linkedcmds cmdqueing
Device is  ready
/dev/scsi/sc0d4l0:  CD-ROM        TOSHIBA CD-ROM XM-5701TA0167
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:  reladdr synch linkedcmds
Device is  not ready

/dev/scsi/sc1d10l0:   Jukebox      HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d11l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d12l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d13l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d14l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d15l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d1l0:  Tape          HP      Ultrium 1-SCSI  E32L
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:  16bit synch
Device is  not ready
/dev/scsi/sc1d2l0:  Tape          HP      Ultrium 1-SCSI  E32L
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:  16bit synch
Device is  not ready
/dev/scsi/sc1d3l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d4l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d5l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d6l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d7l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d8l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
/dev/scsi/sc1d9l0:  Jukebox       HP      C7200           162D
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready

When I try the stacker command on one of the jukeboxes I get

Code: Select all

# stacker -c /dev/scsi/sc1d8l0
/dev/scsi/sc1d8l0: 2 drive(s), 19 slot(s), 1 robot(s), 1 port(s)
which seem about right. There is 20 slots, but 1 is assigned as mailslot so I guess that's why it only says 19 slots.

I haven't cleared any old tape configurations, but as far as I know there have never been a tape drive attached to this machine.
I could try this anyway before my next attempt, and use a SGI with faster SCSI :-)

User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Sun Jun 17, 2012 12:50 pm

Nice!

As far as the issue with 13 jukeboxes appearing in your hinv, you might take a close look at the SCSI ID assigned to the autoloader. Having a single SCSI device appear multiple times is a classic indicator for a device assigned the same SCSI ID as the controller or another device in the SCSI chain. IRIX systems typically assign ID 0 to the controller, while most of the rest of the SCSI-using universe reserved SCSI ID 7 for the controller (see jan-jaap's signature file for some historic background), so SCSI devices transplanted from the PC world some times arrive pre-configured to use ID 0 (especially hard drives that were PC boot drives).

bjornl wrote:Even though there are two tape drives I only get one set of information with 'mt status', I thought I would get information on both.
Only which ever drive IRIX designates as the "master" - which is usually the one with the numerically lowest SCSI address. There should be a SYSLOG entry that indicates which was designated master, I got the following when I connected both an SDLT and an LTO drive:

Code: Select all

May 13 15:06:58 5B:tezro MAKEDEV_tape: ^ISCSI tape unit 6 on controller 5 assumed for main tape device
May 13 15:06:58 5B:tezro MAKEDEV_tape: ^Iln -fs rmt/tps5d6v tape
May 13 15:06:58 5B:tezro MAKEDEV_tape: ^Iln -fs rmt/tps5d6nrv nrtape
- the SDLT on SCSI controller 5 and the LTO on SCSI controller 6 (the external ports of an LSI 22320):

Code: Select all

Integral SCSI controller 5: Version LS1030, low voltage differential
  Tape drive: unit 6 on SCSI controller 5: DLT
Integral SCSI controller 6: Version LS1030, low voltage differential
  Tape drive: unit 10 on SCSI controller 6: DAT
bjornl wrote:There was some strange things with the devices. Sometimes I had one /dev/rmt/tps1d1v and one /dev/rmt/tps1d2v and later one /dev/rmt/tps1d1v and one /dev/tape (which is a symbolic link to /dev/rmt/tps1d2v).
You might peek inside /hw/tape - when I did have two drives connected, there were entries for both in /hw/tape (which is where I think all the tape symlinks in /dev eventually point to). There's a brief mention at the bottom of this post on updating the tape symlinks to point at the device string in /hw/tape that supports compression - by default IRIX set all of the tape drives I've tried to use the varible black size device string, but *not* the variable block sized device with compression.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

jpstewart
Donor
Donor
Posts: 429
Joined: Tue Sep 21, 2010 3:31 pm
Location: Southwestern Ontario, Canada

Re: LTO anyone

Unread postby jpstewart » Mon Jun 18, 2012 7:16 am

bjornl wrote:Even though there are two tape drives I only get one set of information with 'mt status', I thought I would get information on both.

As recondas mentioned, normally mt will only report status on the default drive...whichever one is linked to to /dev/tape. You can use mt -f /dev/rmt/tps1d1v status and mt -f /dev/rmt/tps1d2v status to get info on each drive.

bjornl wrote:When I ran tar, I could not decide which device to use. Even if I type tar cv /dev/rmt/tps1d1v it tried to use /dev/tape which of course was drive number 2.

Was that really the tar command you tried? It should be tar cvf /dev/rmt/tps1d1v <files to backup>. If that's not a typo in your post and you really did omit the f from the command line, then it will have just added /dev/rmt/tps1d1v to the list of files to be backed up to the default device (/dev/tape).

bjornl wrote:There is 20 slots, but 1 is assigned as mailslot so I guess that's why it only says 19 slots.

Yes. You also have "1 port(s)". That's your mailslot.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500, T5240
HP C8000

User avatar
bjornl
Posts: 339
Joined: Tue May 09, 2006 11:55 am
Location: Sweden

Re: LTO anyone

Unread postby bjornl » Mon Jun 18, 2012 1:50 pm

The issue with multiple jukeboxes was solved by changing the SCSI ID of the library. It was ID0. I set it to ID3 and now I only get one
jukebox in the hinv and scsicontrol. Thank you.
It seems like the stacker problem was solved by this because now the load/unload commands works as they are supposed to, on both drives.

The tar cv was not a typo, it was my mistake. I assumed I was supposed to leave out the f, unless I wanted to create a .tar file. I have
used it like that before, but this time there was multiple tapedrives so - new things to learn :-) Thank you.

Now I can start two tar sessions, one for each drive, but I find the performance illogical.
Either one tape doing a full system (3.2Gb) backup takes about 27 minutes.
Two tapes doing full system backups simultaneously takes about 22 minutes (?)

Possibly I interpret the time that timex gives me in a wrong way. Maybe the two sessions takes 22+22 minutes, which makes more sense.
I use two console windows and 'timex tar cvf /dev/rmt/tps1d1v /*' on each console (different target devices of course).

The next problem is to find 100+Gb to backup to force a tape change. I seems like I only have that much stored on a PC, which makes me
have to backup over the ethernet :( . I think I have to move to a SGI with gigabit networking.

I'm gonna try to use compression and see what performance that gives me. I will do that later, otherwise I have to find 200+Gb to backup ;)

User avatar
recondas
Moderator
Moderator
Posts: 5440
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: LTO anyone

Unread postby recondas » Mon Feb 24, 2014 5:47 pm

IBM Half-Height LTO Generation 4 SAS Tape Drive

Code: Select all

       /* IBM LTO-4 HH SAS */
        { TPLTO, TPLTO, 3, 11, "IBM", "ULTRIUM-HH4", 0, 0, {0},
           MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN_PART|MTCAN_PREV|
             MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|MTCANT_IMM|MTCAN_BUFFM|
             MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY|MTCAN_COMPRESS,
           40, 5*60, 20*60, 20*60, 3*3600, 512, 512*512,
           tpsc_default_dens_count, tpsc_default_hwg_dens_names,
             tpsc_default_alias_dens_names,
           {0}, 0, 0, 0,
           0, (u_char *)0 },

Code: Select all

mt status
        Controller: SCSI
        Device: IBM: ULTRIUM-HH4     B6W1
        Status: 0x20262
        Drive type: Linear Tape-Open

Quantum LTO-4 Half-height Model TC-L42AN SAS Tape Drive

Code: Select all

   /* Quantum LTO-4 HH SAS */
   { TPLTO, TPLTO, 7, 9, "QUANTUM", "ULTRIUM 4", 0, 0, {0},
      MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN_PART|MTCAN_PREV|
      MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|MTCANT_IMM|MTCAN_BUFFM|
      MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY|MTCAN_COMPRESS,
        40, 5*60, 20*60, 20*60, 3*3600, 4096, 512*512,
        tpsc_default_dens_count, tpsc_default_hwg_dens_names,
        tpsc_default_alias_dens_names,
     {0}, 0, 0, 0,
      0, (u_char *)0 },

Code: Select all

mt status
        Controller: SCSI
        Device: QUANTUM: ULTRIUM 4       21704506
        Status: 0x20242
        Drive type: Linear Tape-Open
        Media : READY, writable, at BOT
 
Both examples are connected to an LSI SAS1068 controller:

Code: Select all

 Integral SCSI controller 3: Version SAS/SATA LS1068
  Tape drive: unit 4 on SCSI controller 3: Linear Tape-Open

Note: I couldn't turn up a manufacturer-provided IRIX tape definition file for the SCSI or SAS versions of either drive, so the examples here are based on the LTO-4 definition file hhoffman created for his HP model 1760 SCSI LTO-4 tape drive (which in turn originated with an LTO-3 definition file). There's a basic I/O test for the Quantum drive in this thread: viewtopic.php?f=3&t=16727101&start=45#p7367228
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************


Return to “SGI: Hardware”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests