SUMMARY: Tape Reading Problem

I got several responses, but nothing that I hadn't already
tried. Thanks anyway.

Once morning rolled around, I had remote hands to burn a Solaris 10
DVD on a PC and put it in the sparc.

I can read the ufsdump(1M) files on the tape just fine with
Solaris 10,

  # mt -f /dev/rmt/0cbn asf 3
  # ufsrestore ibf 512 /dev/rmt/0cbn
  ufsrestore > ls
  .:
   Acrobat3/      SUNWleo/       applmgr/       hpnpl/         rvplayer5.0/
   EMPsysedge/    SUNWrtvc/      audit/         iona/          sun/
   OV/            SUNWtcx/       crash/         local/         tmp/
   SUNWabe/       SUNWvmsa/      dcelocal/      lost+found/    vxva
   SUNWasevm/     SUNWvts/       ee21/          netscape/
   SUNWdxlib/     SUNWvxvm/      gabsp.org/     openv/
   SUNWexplo/     TT_DB/         gabsprd/       oracle/
   SUNWits/       WLtop/         hpnp/          oradata/
  ufsrestore > ?

Go figure. I'll restore the tapes using Solaris 10 booted off
DVD. I just want to avoid using newfs(1M) or other tools that
might introduce back-incompatibilities while Solaris 10 is up.

So it looks like there is a Solaris 2.5.1 issue reading big
blocks (512 x 512B = 256kB in this case) off of (some?) tapes or
tape drives.


On 2/28/2011 at  4:22 PM, "Crist Clark" <Crist.Clark@globalstar.com> wrote:
> I'm having trouble reading a ufsdump(1M) tape on a 2.5.1
> system. I think it's some kind of blocking factor problem.
>
> I know the ufsdump(1M) command to create the tape was,
>
>   ufsdump 0ubf 512 tapeserver:/dev/rmt/7cbn
>
> I have logs of the dump that verify this,
>
>   DUMP: Writing 256 Kilobyte records
>
> The machine running ufsdump(1M) is also 2.5.1. The machine
> with the tape drive is Solaris 9.
>
> When I try to ufsrestore(1M) on target, 2.5.1 machine, I get,
>
>   # ufsrestore rbf 512 /dev/rmt/0cbn
>   Read error while trying to set up volume
>   continue? [yn] y
>   Volume is not in dump format
>
> The first thought is that the tape is bad. However, the first
> file on the tape is a tar(1) and I can read that just fine.
> Also, there are multiple dump files on the tape, and I can find
> those each fine with "mt -f /dev/rmt/0cbn asf <n>", but get the
> same error for each. The final nail for that theory, to be safe
> we made two identical tapes and sent them to the site with the
> target machine and both show the same thing, the tar(1) is OK,
> but none of the ufsdump(1M)s work.
>
> It looked like a blocking issue, but following the exact methods
> outlined in Sun/Oracle document 1011082.1, I don't get anywhere
> using dd(1) or tcopy(1) to find the block size,
>
>   # mt -f /dev/rmt/0cbn asf 1
>   # truss -t read dd if=/dev/rmt/0cbn of=/tmp/tape.test bs=4096k count=1
>   read(3, 0x00024000, 4194304)                    Err#5 EIO
>   read: I/O error
>   0+0 records in
>   0+0 records out
>   # mt -f /dev/rmt/0cbn rewind
>   # truss -t read tcopy /dev/rmt/0cbn
>   read(3, " / e t c / m a i l /\0\0".., 65536)    = 10240
>   read(3, " m e o u t = 5 m\n\n #  ".., 65536)    = 10240
>   read(3, " s s e s\n R $ +   @   $".., 65536)    = 10240
>   read(3, " r a m e t e r s :\n # #".., 65536)    = 10240
>   ...[snip]...
>   read(3, " d e r   o k ?\n # # # #".., 65536)    = 10240
>   read(3, 0x00021174, 65536)                      = 0
>   file 1: records 1 to 52: size 10240
>   file 1: eof after 52 records: 532480 bytes
>   read(3, 0x00021174, 65536)                      Err#5 EIO
>   eot
>   total length: 532480 bytes
>
> I see the read(2) calls are throwing a EIO error.
>
> Is this some kind of 2.5.1 limitation on blocking factors?
> The fact the read(2) call is failing makes it look like it's
> not a limitation of the userland utilities, but something
> in the kernel and drivers. Also, since I can mt(1) to all
> of the various files, it doesn't look like a problem with
> the tape or the drive.
>
> My workaround is to download the last Solaris release with
> a bootable CDROM (10/08, Update 8, I believe). But this is
> all remote, so I need to wait until tomorrow for remote
> hands to help with that. And if this isn't a 2.5.1 issue,
> that might not even fix it.
>
> This look familiar to anyone?

--

Crist Clark
Network Security Specialist, Information Systems
Globalstar
408 933 4387
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers