|
Home > Archive > Unix administration > January 2004 > gtar restore produces strange directories
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gtar restore produces strange directories
|
|
|
| I'm trying to migrate a AIT drive from an IBM AIX machine to a Solaris
2.X system. I have a bunch of backups that were created on the AIX
machine using gtar with a blocking factor of 20. I've been testing to
see if I can restore the tapes created on the IBM on a Solaris system.
I can read the tapes and get a listing and can even extract "stuff"
from the tape. But all of the files get dumped into directories like:
"7732114074 7672207472 /./user"
Does any one know why the restored files are in these funky
directories? When I do a listing, it shows the correct user name/date
and everything, but it has these strange directory names. Any one had
a similar experience? Thanks
Q
| |
|
| More info:
gtar version 1.11.2 on AIX
gtar version 1.13 on solaris
Used these switches for creating on AIX:
--multi-volume --one-file-system --block-size=20 --sparse
Q
quang777@email.com (q777) wrote in message news:<9f14310.0311041153.5d18dd92@posting.google.com>...quote:
> I'm trying to migrate a AIT drive from an IBM AIX machine to a Solaris
> 2.X system. I have a bunch of backups that were created on the AIX
> machine using gtar with a blocking factor of 20. I've been testing to
> see if I can restore the tapes created on the IBM on a Solaris system.
> I can read the tapes and get a listing and can even extract "stuff"
> from the tape. But all of the files get dumped into directories like:
> "7732114074 7672207472 /./user"
>
> Does any one know why the restored files are in these funky
> directories? When I do a listing, it shows the correct user name/date
> and everything, but it has these strange directory names. Any one had
> a similar experience? Thanks
>
> Q
| |
|
| I finally tracked down a couple of postings elsewhere that had a
similar problem. The solution seemed to be to use the latest version
of gtar, 1.13.25. I downloaded it and compiled it. I was able to make
a proper listing. So the weird directory names seem to be a gtar
bug/incompatibility.
Now I'm running another problem. If I try to extract/restore it
directly from the tape using tar -b20 -xvBf /dev/rmt/0, I eventually
get "Cannot read: I/O error" at about 20MB or 225 files into the
archive. However, if I use dd and create a tar file using dd
if=/dev/rmt/0 of=file.tar count=200000 (200MB file) it doesn't
complain and I can extract the contents using tar -xvf file.tar
without a problem. I've tried playing with the settings in st.conf and
different switches of gtar, but haven't been able to get it to restore
past the same place on the tape. Any ideas?
Q
quang777@email.com (q777) wrote in message news:<9f14310.0311041153.5d18dd92@posting.google.com>...quote:
> I'm trying to migrate a AIT drive from an IBM AIX machine to a Solaris
> 2.X system. I have a bunch of backups that were created on the AIX
> machine using gtar with a blocking factor of 20. I've been testing to
> see if I can restore the tapes created on the IBM on a Solaris system.
> I can read the tapes and get a listing and can even extract "stuff"
> from the tape. But all of the files get dumped into directories like:
> "7732114074 7672207472 /./user"
>
> Does any one know why the restored files are in these funky
> directories? When I do a listing, it shows the correct user name/date
> and everything, but it has these strange directory names. Any one had
> a similar experience? Thanks
>
> Q
| |
|
| Thanks for the response Doug. A co-worker suggested that also. I just
went into smit to look at how the tape drive was configured. In smit
under:
Devices -> Tape Drive -> Change/Show Characteristics
it has a field for BLOCK size (0=variable length)(num) = 512
Assuming that it was variable, is there any way to set up gtar or the
tape device settings to read the tape properly without using dd to
extract the whole tape to a file?
Since the configuration on the AIX was not variable, what else could
it be? Thanks
Q
dfreybur@yahoo.com (Doug Freyburger) wrote in message news:<7960d3ee.0311060711.7176c773@posting.google.com>...quote:
> q777 wrote:
>
> Tar expects fixed-block tapes. AIX is able to write variable-block
> tapes. dd does its own buffering when it encounters variable-blocked
> input. Looks like on your AIX system you didn't set the tape device
> to fixed-block.
| |
| Villy Kruse 2004-01-23, 4:53 pm |
| On 6 Nov 2003 10:40:05 -0800,
q777 <quang777@email.com> wrote:
quote:
>Thanks for the response Doug. A co-worker suggested that also. I just
>went into smit to look at how the tape drive was configured. In smit
>under:
>Devices -> Tape Drive -> Change/Show Characteristics
>
>it has a field for BLOCK size (0=variable length)(num) = 512
>
>Assuming that it was variable, is there any way to set up gtar or the
>tape device settings to read the tape properly without using dd to
>extract the whole tape to a file?
>
Basicaly this setting should be the same as the setting was when the
tape was written. When the device driver is set for block size 512
the tar program can then choose any blocksize it wants and the OS
will reblock the tape blocks to the block size requested by tar.
If you set the devcie driver block size to 0 then the blocks on
the tape is delivered as is to the tar program as is, so when you
specify -b20 to tar then the tape should contains 20*256 bytes
in each tape block.
With current tape units you would want tape blocks to be considerably
larger than 512 bytes or even 20*256 for performance reasons. 512
byte blocks was fine for 150Mb QIC tapes.
If you set the tape unit to variable block size and read one block
using this command:
dd if=/dev/tape bs=500k count=1 | wc -c
you will get the actual size of the first tape block. The remaining tape
blocks will all have the same size if written by a propper tar program.
If the block size is actualy 512 bytes or 1024 bytes then set the
block size of the device driver to that value. Otherwise leave it
at variable block size and set the -b option to tar accordingly.
You can also use dd to reblock the data:
dd if=/dev/tape ibs=500k obs=10240 | tar xvbf 20 -
That should only be required if the tape wasn't written by a proper tar
program.
Villy
| |
|
| Actually, as I mentioned originally in my post, we're trying to get
rid of our AIX system. So I have to be able to read the tapes
generated by the AIX system via the Solaris one. Also, the dd method
seems to work fine for single tape backups but doesn't work for
multivolume backups. I'm also trying to figure out if it's a problem
with the tape or with gtar. With another set of tapes (multivolume),
tar is able to extract it ok on the SUN box, but gtar dies on IO
errors instead. I have to figure which parts are the actual problem.
Will get back...
Q
dfreybur@yahoo.com (Doug Freyburger) wrote in message news:<7960d3ee.0311070719.1a24c1c@posting.google.com>...quote:
> q777 wrote:
>
> I suspect that most tapes written on AIX are read again on AIX, and
> most tapes written on your other systems are read again on those
> other systems. So I doubt it's worth switching AIX from its default
> settings for an occasional tape delivery.
>
> Many SAs complain about "unnecessary uses of cat" in command lines.
> Chuckle. I'm not afraid of doing the unnecessary when it's easy
> and convenient. When moving a tape from vendor to vendor, I usually
> use dd whether it's necessary or not. dd if=/dev/tape | gtar tvf -
> Let dd handle any blocking and reblocking and don't fuss about whether
> blocking's an issue or not. Yup, you'll get some SAs complain about
> "unnecessary use of dd". Part of the fun, I say.
|
|
|
|
|