mtx reverses the numbers given to tape drives by CentOS and scsi generic (sg) devices

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question
























    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.







    share|improve this question






















      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.







      share|improve this question












      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.









      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 12 at 19:55









      PolkaRon

      74113




      74113




















          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.






          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );








             

            draft saved


            draft discarded


















            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






























            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.






            share|improve this answer
























              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.






              share|improve this answer






















                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.






                share|improve this answer












                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 14 at 17:19









                Oldest Software Guy

                1672




                1672






















                     

                    draft saved


                    draft discarded


























                     


                    draft saved


                    draft discarded














                    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













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?