mtx reverses the numbers given to tape drives by CentOS and scsi generic (sg) devices
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
we have some confusion when we run mtx commands to load a tape from an autoloader slot to tape drive. we have two LTO-5 tape drives connected to our backup server. They are recognized by the operating system as /dev/st0 and /dev/st1. We're also using a Quantum Scalar-i40 as our tape auto library which points to /dev/sg2 via a symlink /dev/changer.
When I load a tape from slot 36 to tape drive 1 via mtx, the mtx status seem fine.
# load tape in slot 36 to tape drive 1
[root@backup ~]# mtx -f /dev/changer load 36 1
Loading media from Storage Element 36 into drive 1...done
[root@backup ~]# mtx -f /dev/changer status
Storage Changer /dev/changer:2 Drives, 38 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Storage Element 36 Loaded):VolumeTag = JP6650
Storage Element 1:Full :VolumeTag=JP6657
***
Storage Element 36:Empty:VolumeTag=
Storage Element 37:Full :VolumeTag=JP6653
Storage Element 38:Full :VolumeTag=JP6658
However, tape drive Data Transfer Element 1 does not point to /dev/st1. It points to /dev/st0 instead. Data Transfer Element 1 corresponds to /dev/st0 which is super confusing.
[root@backup ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
[root@backup ~]# mt -f /dev/st1 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
DR_OPEN IM_REP_EN
Here's the rest of our OS + kernel + scsi device information.
[root@backup ~]# cat /etc/centos-release
CentOS release 6.1 (Final)
[root@backup ~]# uname -a
Linux backup 2.6.32-131.21.1.el6.x86_64 #1 SMP Tue Nov 22 19:48:09 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@backup ~]# lsscsi -g
[0:0:0:0] tape HP Ultrium 5-SCSI Z58Z /dev/st0 /dev/sg0
[0:0:1:0] tape HP Ultrium 5-SCSI Z58Z /dev/st1 /dev/sg1
[0:0:1:1] mediumx QUANTUM Scalar i40-i80 135G /dev/sch0 /dev/sg2
[1:0:0:0] cd/dvd HL-DT-ST DVD-ROM GDR-R10N 2.02 /dev/sr0 /dev/sg3
[3:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sda /dev/sg4
[4:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sdb /dev/sg5
Is there any way to force mtx to recognize my tape drives differently? I want the /dev/st* devices to correspond to the correct Data Transfer Element under mtx.
centos backup scsi tape
add a comment |Â
up vote
0
down vote
favorite
we have some confusion when we run mtx commands to load a tape from an autoloader slot to tape drive. we have two LTO-5 tape drives connected to our backup server. They are recognized by the operating system as /dev/st0 and /dev/st1. We're also using a Quantum Scalar-i40 as our tape auto library which points to /dev/sg2 via a symlink /dev/changer.
When I load a tape from slot 36 to tape drive 1 via mtx, the mtx status seem fine.
# load tape in slot 36 to tape drive 1
[root@backup ~]# mtx -f /dev/changer load 36 1
Loading media from Storage Element 36 into drive 1...done
[root@backup ~]# mtx -f /dev/changer status
Storage Changer /dev/changer:2 Drives, 38 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Storage Element 36 Loaded):VolumeTag = JP6650
Storage Element 1:Full :VolumeTag=JP6657
***
Storage Element 36:Empty:VolumeTag=
Storage Element 37:Full :VolumeTag=JP6653
Storage Element 38:Full :VolumeTag=JP6658
However, tape drive Data Transfer Element 1 does not point to /dev/st1. It points to /dev/st0 instead. Data Transfer Element 1 corresponds to /dev/st0 which is super confusing.
[root@backup ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
[root@backup ~]# mt -f /dev/st1 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
DR_OPEN IM_REP_EN
Here's the rest of our OS + kernel + scsi device information.
[root@backup ~]# cat /etc/centos-release
CentOS release 6.1 (Final)
[root@backup ~]# uname -a
Linux backup 2.6.32-131.21.1.el6.x86_64 #1 SMP Tue Nov 22 19:48:09 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@backup ~]# lsscsi -g
[0:0:0:0] tape HP Ultrium 5-SCSI Z58Z /dev/st0 /dev/sg0
[0:0:1:0] tape HP Ultrium 5-SCSI Z58Z /dev/st1 /dev/sg1
[0:0:1:1] mediumx QUANTUM Scalar i40-i80 135G /dev/sch0 /dev/sg2
[1:0:0:0] cd/dvd HL-DT-ST DVD-ROM GDR-R10N 2.02 /dev/sr0 /dev/sg3
[3:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sda /dev/sg4
[4:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sdb /dev/sg5
Is there any way to force mtx to recognize my tape drives differently? I want the /dev/st* devices to correspond to the correct Data Transfer Element under mtx.
centos backup scsi tape
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
we have some confusion when we run mtx commands to load a tape from an autoloader slot to tape drive. we have two LTO-5 tape drives connected to our backup server. They are recognized by the operating system as /dev/st0 and /dev/st1. We're also using a Quantum Scalar-i40 as our tape auto library which points to /dev/sg2 via a symlink /dev/changer.
When I load a tape from slot 36 to tape drive 1 via mtx, the mtx status seem fine.
# load tape in slot 36 to tape drive 1
[root@backup ~]# mtx -f /dev/changer load 36 1
Loading media from Storage Element 36 into drive 1...done
[root@backup ~]# mtx -f /dev/changer status
Storage Changer /dev/changer:2 Drives, 38 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Storage Element 36 Loaded):VolumeTag = JP6650
Storage Element 1:Full :VolumeTag=JP6657
***
Storage Element 36:Empty:VolumeTag=
Storage Element 37:Full :VolumeTag=JP6653
Storage Element 38:Full :VolumeTag=JP6658
However, tape drive Data Transfer Element 1 does not point to /dev/st1. It points to /dev/st0 instead. Data Transfer Element 1 corresponds to /dev/st0 which is super confusing.
[root@backup ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
[root@backup ~]# mt -f /dev/st1 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
DR_OPEN IM_REP_EN
Here's the rest of our OS + kernel + scsi device information.
[root@backup ~]# cat /etc/centos-release
CentOS release 6.1 (Final)
[root@backup ~]# uname -a
Linux backup 2.6.32-131.21.1.el6.x86_64 #1 SMP Tue Nov 22 19:48:09 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@backup ~]# lsscsi -g
[0:0:0:0] tape HP Ultrium 5-SCSI Z58Z /dev/st0 /dev/sg0
[0:0:1:0] tape HP Ultrium 5-SCSI Z58Z /dev/st1 /dev/sg1
[0:0:1:1] mediumx QUANTUM Scalar i40-i80 135G /dev/sch0 /dev/sg2
[1:0:0:0] cd/dvd HL-DT-ST DVD-ROM GDR-R10N 2.02 /dev/sr0 /dev/sg3
[3:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sda /dev/sg4
[4:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sdb /dev/sg5
Is there any way to force mtx to recognize my tape drives differently? I want the /dev/st* devices to correspond to the correct Data Transfer Element under mtx.
centos backup scsi tape
we have some confusion when we run mtx commands to load a tape from an autoloader slot to tape drive. we have two LTO-5 tape drives connected to our backup server. They are recognized by the operating system as /dev/st0 and /dev/st1. We're also using a Quantum Scalar-i40 as our tape auto library which points to /dev/sg2 via a symlink /dev/changer.
When I load a tape from slot 36 to tape drive 1 via mtx, the mtx status seem fine.
# load tape in slot 36 to tape drive 1
[root@backup ~]# mtx -f /dev/changer load 36 1
Loading media from Storage Element 36 into drive 1...done
[root@backup ~]# mtx -f /dev/changer status
Storage Changer /dev/changer:2 Drives, 38 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Storage Element 36 Loaded):VolumeTag = JP6650
Storage Element 1:Full :VolumeTag=JP6657
***
Storage Element 36:Empty:VolumeTag=
Storage Element 37:Full :VolumeTag=JP6653
Storage Element 38:Full :VolumeTag=JP6658
However, tape drive Data Transfer Element 1 does not point to /dev/st1. It points to /dev/st0 instead. Data Transfer Element 1 corresponds to /dev/st0 which is super confusing.
[root@backup ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
[root@backup ~]# mt -f /dev/st1 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
DR_OPEN IM_REP_EN
Here's the rest of our OS + kernel + scsi device information.
[root@backup ~]# cat /etc/centos-release
CentOS release 6.1 (Final)
[root@backup ~]# uname -a
Linux backup 2.6.32-131.21.1.el6.x86_64 #1 SMP Tue Nov 22 19:48:09 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@backup ~]# lsscsi -g
[0:0:0:0] tape HP Ultrium 5-SCSI Z58Z /dev/st0 /dev/sg0
[0:0:1:0] tape HP Ultrium 5-SCSI Z58Z /dev/st1 /dev/sg1
[0:0:1:1] mediumx QUANTUM Scalar i40-i80 135G /dev/sch0 /dev/sg2
[1:0:0:0] cd/dvd HL-DT-ST DVD-ROM GDR-R10N 2.02 /dev/sr0 /dev/sg3
[3:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sda /dev/sg4
[4:0:0:0] disk ATA Maxtor 6H500F0 HA43 /dev/sdb /dev/sg5
Is there any way to force mtx to recognize my tape drives differently? I want the /dev/st* devices to correspond to the correct Data Transfer Element under mtx.
centos backup scsi tape
asked Jan 12 at 19:55
PolkaRon
74113
74113
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
Device names like /dev/st0 are not persistent, as you have found out; they get named in discovery order. The best way to get names that will survive a reboot is to write a UDEV rule that creates the symbolic link you want. Mr Google has lots of information about how to write a UDEV rule, but in essence as a device is detected, the kernel offers the device attributes to the UDEV subsystem where rules are applied and if a rule's predicates all pass, then a rule action will create the symlink.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Device names like /dev/st0 are not persistent, as you have found out; they get named in discovery order. The best way to get names that will survive a reboot is to write a UDEV rule that creates the symbolic link you want. Mr Google has lots of information about how to write a UDEV rule, but in essence as a device is detected, the kernel offers the device attributes to the UDEV subsystem where rules are applied and if a rule's predicates all pass, then a rule action will create the symlink.
add a comment |Â
up vote
0
down vote
Device names like /dev/st0 are not persistent, as you have found out; they get named in discovery order. The best way to get names that will survive a reboot is to write a UDEV rule that creates the symbolic link you want. Mr Google has lots of information about how to write a UDEV rule, but in essence as a device is detected, the kernel offers the device attributes to the UDEV subsystem where rules are applied and if a rule's predicates all pass, then a rule action will create the symlink.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Device names like /dev/st0 are not persistent, as you have found out; they get named in discovery order. The best way to get names that will survive a reboot is to write a UDEV rule that creates the symbolic link you want. Mr Google has lots of information about how to write a UDEV rule, but in essence as a device is detected, the kernel offers the device attributes to the UDEV subsystem where rules are applied and if a rule's predicates all pass, then a rule action will create the symlink.
Device names like /dev/st0 are not persistent, as you have found out; they get named in discovery order. The best way to get names that will survive a reboot is to write a UDEV rule that creates the symbolic link you want. Mr Google has lots of information about how to write a UDEV rule, but in essence as a device is detected, the kernel offers the device attributes to the UDEV subsystem where rules are applied and if a rule's predicates all pass, then a rule action will create the symlink.
answered Jan 14 at 17:19
Oldest Software Guy
1672
1672
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f416664%2fmtx-reverses-the-numbers-given-to-tape-drives-by-centos-and-scsi-generic-sg-de%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password