Professional Web Applications Themes

Cloning non-Irix disk drive on Irix - Linux / Unix Administration

I have a SunOS disk drive that runs on an Axil-220 workstation that I need to clone. Due to hardware limitations, I can't connect another drive to the Axil. I also have a SGI Challenge L server with plenty of available drive slots. I was thinking of using the Challenge to dump the SunOS disk to an 8mm tape, and then later dump the tape to a blank drive. If I was doing it in Linux I would do: dd if=/dev/sda of=/dev/st0 dd if=/dev/st0 of=/dev/sda and it wouldn't care about the disklabel/partition scheme, etc, It would just copy blocks from ...

  1. #1

    Default Cloning non-Irix disk drive on Irix

    I have a SunOS disk drive that runs on an Axil-220 workstation that I need
    to clone. Due to hardware limitations, I can't connect another drive to the
    Axil. I also have a SGI Challenge L server with plenty of available drive
    slots. I was thinking of using the Challenge to dump the SunOS disk to an
    8mm tape, and then later dump the tape to a blank drive. If I was doing it
    in Linux I would do:
    dd if=/dev/sda of=/dev/st0
    dd if=/dev/st0 of=/dev/sda
    and it wouldn't care about the disklabel/partition scheme, etc, It would
    just copy blocks from the drive to the tape and from tape to drive. I've
    used this method and confirmed it to work.

    Apparently, Irix does care. In Irix, with the drive jumpered as scsi id 3, I
    tried:
    dd if=/hw/rdisk/dks0d3vol of=/dev/tape bs=1024
    It doesn't give an error, it just says "0+0 records in, 0+0 records out".

    My question to any Irix gurus would be what device would I use to refer to a
    disk drive without an Irix partition scheme on it? Can Irix even deal with
    a non-Irix disk?

    Thanks in advance for any help.
    Rod Guest

  2. #2

    Default Re: Cloning non-Irix disk drive on Irix

    On Mon, 26 Sep 2005 10:19:48 GMT, Rod Wright
    <net> wrote: 

    Have you tried of=/dev/null (to see if the problem is reading the disk
    or writing the tape?) Are you sure the block size is 1024? Try
    conv=noerror,sync

    I don't suppose you could connect the disk drive to a Linux box, or boot
    some version of Linux on the Irix box.. :)

    --
    Thyme's Law:
    Everything goes wrong at once.
    Bill Guest

  3. #3

    Default Re: Cloning non-Irix disk drive on Irix

    Rod Wright wrote: 

    In more ways than one. You might end up needing to use the
    byte-swapping device if it fails the first time.
     

    The problem is the partitioning scheme is different so
    trying the *vol device won't work. None of the regular
    dks* devices will work because they all assume the drive
    has a valid label for IRIX and it doesn't.

    If you have the "SCSI Generic" driver loaded there may be
    "sg" devices under the /dev tree. If so, that can be
    used. It's not commonly on IRIX boxes unless you have
    something like a magneto-optical jukebox in use for
    backups, so this is a low percentage shot.

    In general the different labelling schemes makes doing
    this across platform not work. The SG driver is a hack
    to get around it but it's not in common use because there
    is little call for it.

    Is the SCSI chain on the target Sun really full on all
    addresses 0-6? And with SCSI wide 8-15 as well? The
    7 is a wild-card address in most cases.

    Doug Guest

  4. #4

    Default Re: Cloning non-Irix disk drive on Irix

    Begin <googlegroups.com>
    On 2005-09-26, Doug Freyburger <com> wrote: 

    Wild card? I thot it was the controller its own address?


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    jpd Guest

  5. #5

    Default Re: Cloning non-Irix disk drive on Irix

    jpd wrote: 
    >
    > Wild card? I thot it was the controller its own address?[/ref]

    Possibly two ways of stating the same thing.

    If you probe target 7 all of the targets respond.
    Whether this should be called wildcard because that's
    what it effectively acheives or "initiator collision"
    is a matter of perspective.

    Doug Guest

  6. #6

    Default Re: Cloning non-Irix disk drive on Irix

    > Have you tried of=/dev/null (to see if the problem is reading the disk 

    I've tried if=/dev/zero of=/dev/tape and it will dump zeros to the tape all
    day long. I know the block size of the tape is 1024, because that's what mt
    reports. I'm not getting any read errors, so I don't think noerror would
    help. I don't want any padding of input blocks with sync because I want the
    bits on the tape to be exactly what was on the disk.
     


    I can (and have) connected the drive to a Linux box with success. I'm
    developing a procedure for our other sites to be able to do this without
    having to obtain any additional hardware or software. They're probably not
    going to have a Linux box to use. The challenge (so to speak) is to do it
    with what I know will be available at all sites.
     

    Linux on a 12 CPU Challenge L? Woo-hooo!!
    Rod Guest

  7. #7

    Default Re: Cloning non-Irix disk drive on Irix

    Doug Freyburger wrote:
     

    No such luck. And all the machines are subject to configuration management
    so installing new software is not an option.
     

    The problem is not that the Axil is full, it's that I'm limited to using
    only the hardware that I know will be at hand at our other sites. So buying
    extra cables, drive chassis, etc. is not possible.

    Come to think of it, I haven't checked to see if the Axil can have
    internally connected drives.... that may be the way to go.

    Thanks to all for the help and suggestions. Sometimes "it can't be done" is
    just as helpful as "this is how you do it".

    Rod Guest

  8. #8

    Default Re: Cloning non-Irix disk drive on Irix

    Rod Wright wrote: 
    >
    > I've tried if=/dev/zero of=/dev/tape and it will dump zeros to the tape all
    > day long. I know the block size of the tape is 1024, because that's what mt
    > reports.[/ref]

    The reason for chosing 1024 is that is the native sector size
    of the disk, not because it is the native sector size of the
    tape. No way did "mt" tell you the native sector size of the
    disk. You needed to use some other tool for that, most likely
    a utility on Solaris.

    Doug Guest

  9. #9

    Default Re: Cloning non-Irix disk drive on Irix

    Rod Wright wrote: 
    >
    > Thanks to all for the help and suggestions. Sometimes "it can't be done" is
    > just as helpful as "this is how you do it".[/ref]

    With "it can't be done" it is also important why it can't.
    In this case it's because the low numbered sectors on the
    disk have different formats. The drive starts with negative
    numbered blocks with manufacturers data, same format across
    UNIX versions. Then are the boot sectors, different format
    as well as different size across UNIX version. Then are the
    partition tables, same issue. Once you get into the partitions
    the data can be accessed just fine but there's no good way
    to access partitions across vendors.

    Doug Guest

  10. #10

    Default Re: Cloning non-Irix disk drive on Irix

    Doug Freyburger wrote:
     

    I arrived at 1024 because
    dd if=/dev/zero of=/dev/tape
    results in "Write error: invalid argument" since dd defaults to 512 byte
    blocks and the tape was expecting something else. I did
    mt -f /dev/tape blksize
    and saw that the tape was currently using 1024 byte blocks. I didn't know
    that the size of blocks being read from the disk mattered, and I figured
    using the tape's default block size would make the procedure easier for
    others to run. I guess I need to learn more about disk geometry.

    Did I just get lucky in Linux that dd's default of 512 byte blocks was
    correct for the disk drive? When I dumped the disk to a tape, and the tape
    to a new disk under Linux, I didn't specify a block size at all.
    Rod Guest

  11. #11

    Default Re: Cloning non-Irix disk drive on Irix

    Doug Freyburger wrote: 
    >>
    >> Thanks to all for the help and suggestions. Sometimes "it can't be done" is
    >> just as helpful as "this is how you do it".[/ref]
    >
    > With "it can't be done" it is also important why it can't.
    > In this case it's because the low numbered sectors on the
    > disk have different formats. The drive starts with negative
    > numbered blocks with manufacturers data, same format across
    > UNIX versions.[/ref]
     

    Actually, _sector_ sizes aren't usually all that variable across UNIX
    versions - at least the way they're usually used in the "SCSI generic"
    context. Just about all hard disks used directly have 512 bytes/sector.
    They have wildly variable numbers of sectors/cylinder though, and that's
    occasionally a problem.

    Partition tables of course do differ, but from the "SCSI generic"
    viewpoint they shouldn't matter. You don't boot or mount filesystems
    through that interface anyway, and userland-only access to foreign partition
    table types is possible - if only rarely done. You'd need the
    application to know about whatever layout is on the disk surface.
    Or, as it happens, just preserve/copy the layout as-is... as dd does by
    default and Norton Ghost can be told to do.

    There was a time when I took a disk to a local PC shop and told them to
    do a raw copy to another disk with Ghost. It works if you can persuade
    them to actually force Ghost to do a raw copy, and the disks are similar
    enough in ways that happen to be relevant in your particular case (if
    the only relevant thing is sector numbers counted from 0 on, it's easy).

    (Then there was the "dd if=$disk |rsh $otherhost dd of=$disk" that
    worked too. And the disk was mounted bootable root at the local end,
    and the remote end booted from the copy just fine afterwards. But the
    systems were identical down to disk model number in that case.)

    Now, this doesn't apply if you have a hardware RAID of some kind - in
    that case you'll need to move the whole frame. The frame usually
    provides 512 bytes/sector to the outside too, even if it uses 520 or 524
    or some such internally. (Do a low-level format to change the sector
    size if using such disks as spares...)

    And even if you get the partition layer sorted out, the in-kernel
    filesystem implementations aren't all that often compatible. Tried it a
    couple of times, either failed to mount or got a kernel panic most of
    the time.


    --
    Mikko Nahkola <ntc.nokia.com>
    #include <disclaimer.h>
    #Not speaking for my employer. No warranty. YMMV.
    Mikko Guest

  12. #12

    Default Re: Cloning non-Irix disk drive on Irix

    Rod Wright wrote: 
    >
    > I arrived at 1024 because
    > dd if=/dev/zero of=/dev/tape
    > results in "Write error: invalid argument" since dd defaults to 512 byte
    > blocks and the tape was expecting something else. I did
    > mt -f /dev/tape blksize
    > and saw that the tape was currently using 1024 byte blocks. I didn't know
    > that the size of blocks being read from the disk mattered[/ref]

    I've use dd like that on Solaris a few times and blocksize
    did matter. I'm not certain blocksize matters on other
    systems but once burnt twice cautious.
     

    dd "should" reblock correctly going onto tape and reblock
    correctly coming off tape. I have seen that "should" fail
    on Solaris 2.mumble.
     

    You probably want a multiple anyways. At one point I
    bnechmarked blocksizes and 1024 was 50ish% the time for the
    same data at 512. The curve rolled over in the 64K range.
    At small blocksize the interblock gaps dominate the speed;
    at large blocksize the data transfer dominates the speed.
    My benchmark arriving at 64K is over 10 years old at this
    point, but going much larger than a meg wouldn't likely go
    faster.

    Linux is more adaptible than IRIX. You could well get the
    clone to work on it. Using dd to clone systems to identical
    geometry drives rules. Been there, done that, remember the
    hundreds of workstations running CAD software ....

    Doug Guest

  13. #13

    Default Re: Cloning non-Irix disk drive on Irix

    Begin <googlegroups.com>
    On 2005-09-26, Doug Freyburger <com> wrote: 
    >
    > Possibly two ways of stating the same thing.
    >
    > If you probe target 7 all of the targets respond.
    > Whether this should be called wildcard because that's
    > what it effectively acheives or "initiator collision"
    > is a matter of perspective.[/ref]

    Ok, I didn't know that. OTOH, while 7 is *usually* the only controller
    on the bus, it doesn't have to be. I don't think there are many
    chains with a controller on say 6 and no controller on 7, but multi-
    controller setups can exist. At least from a SCSI perspective, that is,
    ``mainstream'' software probably doesn't support it very often.

    Now I wonder what happens if you probe 7 (or 6) on such a multi-
    controller bus. But I digress.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    jpd Guest

  14. #14

    Default Re: Cloning non-Irix disk drive on Irix

    Doug Freyburger wrote:
     

    I guess the proprietary unixes never had to think about interoperability on
    a hardware level, just on a networking level. Linux, being a latecomer, and
    designed by people who weren't tied to one particular architecture, tried
    to be interoperable with as much as possible. I could take the drives from
    both the Challenge and the Axil, hang them both on the Linux box SCSI bus,
    and have the ufs and xfs filesystems mounted at the same time.

    I got a chance to poke around in the Axil and found that there is no drive
    connected internally, so I think I'm going to play around with that.

    Thanks for all the help and info. :-)
    Rod Guest

  15. #15

    Default Re: Cloning non-Irix disk drive on Irix

    Rod Wright wrote: 
    >
    > I guess the proprietary unixes never had to think about interoperability on
    > a hardware level, just on a networking level. Linux, being a latecomer, and
    > designed by people who weren't tied to one particular architecture, tried
    > to be interoperable with as much as possible. I could take the drives from
    > both the Challenge and the Axil, hang them both on the Linux box SCSI bus,
    > and have the ufs and xfs filesystems mounted at the same time.[/ref]

    Economic incentive. Commercial vendors have negative
    economic incentive to accept hardware from competitors.
    Linux hobbiests have positive economic incentive to
    accept cheap running hardware harvested from other
    boxen.
     

    Most excellent. An entire SCSI chain as your playground.

    Doug Guest

  16. #16

    Default Re: Cloning non-Irix disk drive on Irix

    In article <net>, jpd wrote: [/ref]
     
    >
    > Ok, I didn't know that. OTOH, while 7 is *usually* the only controller
    > on the bus, it doesn't have to be. I don't think there are many
    > chains with a controller on say 6 and no controller on 7, but multi-
    > controller setups can exist. At least from a SCSI perspective, that is,
    > ``mainstream'' software probably doesn't support it very often.[/ref]

    Some UNIX versions do it fairly often, though. For example, anything with
    HP-UX and MC/ServiceGuard on shared disks is likely to have such unless
    it's using FC.

    Whee, HVD Fast-20 Wide with inline-terminated cables, and controllers at
    both ends of the chain, not all that many years ago...


    --
    Mikko Nahkola <ntc.nokia.com>
    #include <disclaimer.h>
    #Not speaking for my employer. No warranty. YMMV.
    Mikko Guest

Similar Threads

  1. problems upgrading from IRIX 6.5.19m
    By Kirt Dankmyer in forum Linux / Unix Administration
    Replies: 0
    Last Post: July 21st, 04:34 PM
  2. Ruby 1.8.0 on IRIX?
    By Ketil Kristiansen in forum Ruby
    Replies: 1
    Last Post: October 12th, 02:02 AM
  3. irix 6.5 nis problem
    By Alexander Haas in forum Linux / Unix Administration
    Replies: 7
    Last Post: October 1st, 09:36 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139