Author: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 31 Dec 2004 10:49:38 -0500
Gene, Thanks for the tape label sequence, will re-label the next couple of tapes and see if I don't get different results from the next amdump run. (commands reproduced below). If this solves the pro
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 31 Dec 2004 12:42:17 -0500
But, otoh, its strengthening the argument to use gnutar only. And I'd make the suggestion that somewhere in this setup, there is insufficient iron to do the job. I don't know anything about an SDLT,
Author: Eric Siegerman <erics AT telepres DOT com>
Date: Wed, 5 Jan 2005 18:30:37 -0500
That one's a GTAR DLE, isn't it? Looks as though you're only partially out of the woods for those... Try manually dd'ing data from the tape (basically, doing by hand what "amrestore -r" does). This w
Author: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 7 Jan 2005 11:17:21 -0500
Gene, Eric, Following Gene's model, I set the default block size on the tape devices (sgi command # mt -f /dev/rmt/tps1d4nrns devblksz 32768) and also switched from the varable length to the fixed le
Author: "Stefan G. Weichinger" <monitor AT oops.co DOT at>
Date: Fri, 7 Jan 2005 17:50:58 +0100
Hello, Brian, I thought of your problems this morning ;-) "Invalid argument" ! Notice the option "count", dd has to be told how much to read/write ... Do your AMANDA-binaries point to the proper xfs-
Author: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 7 Jan 2005 11:59:54 -0500
Stefan, Yes, will strip more stuff out (didn't realize it had grown so much. The instruction I was following from Gene where pretty explicite (not that I follow all that well) and where intended to s
Author: "Stefan G. Weichinger" <monitor AT oops.co DOT at>
Date: Fri, 7 Jan 2005 18:49:51 +0100
Hi, Brian, on Freitag, 07. Jänner 2005 at 17:59 you wrote to amanda-users: ;-) Let's see. And these two binaries are found and used by the configure-script? I would do a copy to a second config and s
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 7 Jan 2005 13:11:03 -0500
Normally this isn't required. dd will read to the end of the record by default I think. This does sound like a good suggestion until this has been figured out. -- Cheers, Gene "There are four boxes t
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 7 Jan 2005 13:14:54 -0500
Humm, are you saying that amlabel works and can read the label written, but that dd doesn't/cannot? Back to 'man dd' as it exists on that Irix system would be my next suggestion. -- Cheers, Gene "The
Author: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 7 Jan 2005 13:20:42 -0500
Gene, Remembering that I'd set the blocksize on the device and relabeled yesterday I tried this. samar 160# mt -f /dev/sdlt2 rewind samar 161# dd of=/dev/sdlt2 bs=32k if=./scratch 1+0 records in 1+0
Author: "Stefan G. Weichinger" <monitor AT oops.co DOT at>
Date: Fri, 7 Jan 2005 19:31:10 +0100
Hey Brian, Good to hear. What size did scratch have? Much nicer device-name now, BTW, maybe this was the problem ... Do you use this one (the corresponding non-rewinding device) in amanda.conf as wel
Author: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 7 Jan 2005 13:36:41 -0500
Stefan, I'll have to try to pull it again, I seem to have subsequently overwritten it with a zero length file. I had intended (and forgot) to write, that I checked the amdump log file and that the pa
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 7 Jan 2005 13:54:55 -0500
And got you how big a scratch file? And were you then able to reread it ok? To me, theres something a bit odd about dd telling you it wrote 64 input records to one output record. OTOH, I haven't fool
Author: Eric Siegerman <erics AT telepres DOT com>
Date: Fri, 7 Jan 2005 14:01:26 -0500
These two things might well be related. That dd command, without a "bs=" argument, is trying to read 512-byte blocks. But the physical blocks on the tape are 32 KB -- your adjustments have seen to th
Author: Eric Siegerman <erics AT telepres DOT com>
Date: Fri, 7 Jan 2005 14:05:39 -0500
I suppose the theory must be that anyone can do a restore, but only root can use [xfs]dump. -- The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exis
"bs" is just a short cut to saying "obs" and "ibs". So the following are the same: obs=32k ibs=32k bs=32k It is only necessary to use obs and ibs if they are different (including an unspecified one o
Author: Eric Siegerman <erics AT telepres DOT com>
Date: Fri, 7 Jan 2005 15:39:46 -0500
Yup, this makes sense. Since you specified "obs", the input block size remained at the default of 512 bytes. "dd" read enough of those (64) to make a 32-KB output block and then wrote the latter. If
Brian, as you were using the 'v', might the data on the tapes have been written with some > 32K block size? All of your dd's seem to fail after the header. How about trying a couple of mt fsf # to so
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 7 Jan 2005 18:54:10 -0500
This is querying the tape only, and I guess the bigger tapes like bigger blocksizes by default. This I think, is not good. Ok, what happens if you don't spec the blocksize, but just a count of 1 on a