On Friday 21 January 2005 11:37, Brian Cuttler wrote:
>Stefan,
>
>On Wed, Jan 19, 2005 at 10:48:54PM +0100, Stefan G. Weichinger wrote:
>> BC> Major imporvement though still below the acceptable threshold.
>>
>> BC> Definitely looking like it was never an amanda issue, this
>> looks to BC> be an un
Stefan,
On Wed, Jan 19, 2005 at 10:48:54PM +0100, Stefan G. Weichinger wrote:
> BC> Major imporvement though still below the acceptable threshold.
>
> BC> Definitely looking like it was never an amanda issue, this looks to
> BC> be an underlying architecture problem.
>
> I hope that you spot the
Hi, Brian,
on Mittwoch, 19. Jänner 2005 at 22:02 you wrote to amanda-users:
BC> Major imporvement though still below the acceptable threshold.
BC> Definitely looking like it was never an amanda issue, this looks to
BC> be an underlying architecture problem.
I hope that you spot the issue soon,
Info update only.
Ok we've shutdown the Origin 300 and swapped the scsi daisy-chain
around a little.
At this point the SDLT in the shoebox was able to restore a large
tar file without causing a SCSI reset and hanging the system.
I then set the blocksize on the SDLT in the jukebox and relable
On Wednesday 12 January 2005 14:55, Gene Heskett wrote:
>On Wednesday 12 January 2005 12:04, Jon LaBadie wrote:
>>On Wed, Jan 12, 2005 at 11:18:00AM -0500, Eric Siegerman wrote:
>>> On Tuesday 11 January 2005 16:40, Jon LaBadie wrote:
>>> >Also, I think that if both types of devices exist on the sa
On Wednesday 12 January 2005 12:04, Jon LaBadie wrote:
>On Wed, Jan 12, 2005 at 11:18:00AM -0500, Eric Siegerman wrote:
>> On Tuesday 11 January 2005 16:40, Jon LaBadie wrote:
>> >Also, I think that if both types of devices exist on the same
>> > bus, the lower performance one determines the perfor
Google says: voltage standing wave ratio
> > > To many folks forget that a a scsi bus is indeed
> > > an rf transmission line, subject to the usual rules about vswr.
> >
> > >From the context it's pretty clear what "vswr" means, but what
> > does it stand for?
> >
> >
> Wondered too, as I'm po
On Wed, Jan 12, 2005 at 11:18:00AM -0500, Eric Siegerman wrote:
> On Tuesday 11 January 2005 16:40, Jon LaBadie wrote:
> >Also, I think that if both types of devices exist on the same bus,
> >the lower performance one determines the performance of the entire
> >bus.
>
> In theory, this is *not* th
On Tuesday 11 January 2005 16:40, Jon LaBadie wrote:
>Also, I think that if both types of devices exist on the same bus,
>the lower performance one determines the performance of the entire
>bus.
In theory, this is *not* the case. One of the (many) selling
points of SCSI over IDE is supposed to be
On Tuesday 11 January 2005 16:40, Jon LaBadie wrote:
>On Tue, Jan 11, 2005 at 03:40:47PM -0500, Brian Cuttler wrote:
>> Amanda user list,
>>
>> I've spoken to Harry at Condre systems and he confirmed what we
>> where seeing. The jukebox robot is a narrow bus so that are two
>> changes we need to ma
Jon,
Recommended buying an additional scsi card more than once to the
system's owners, haven't made the case yet (maybe now). I would
really have liked the raid array on a separate bus from the tape
drives.
I have to trust that the proper cabeling to terminate the additional
lines is present in
On Tue, Jan 11, 2005 at 03:40:47PM -0500, Brian Cuttler wrote:
>
> Amanda user list,
>
> I've spoken to Harry at Condre systems and he confirmed what we
> where seeing. The jukebox robot is a narrow bus so that are two
> changes we need to make.
>
> 1) We want to move the jukebox/SDLT to be the
Amanda user list,
I've spoken to Harry at Condre systems and he confirmed what we
where seeing. The jukebox robot is a narrow bus so that are two
changes we need to make.
1) We want to move the jukebox/SDLT to be the last device on
the daisy chain.
2) We want to terminate the jukebox-robot,
On Tue, Jan 11, 2005 at 09:11:31AM +0100, Stefan G. Weichinger wrote:
> The minimum blocksize value
> is 32 KBytes. The maximum blocksize value is 32
> KBytes.
The man pages have configure variables, which are expanded
during "make". Presumably the
Hi, Jon,
on Montag, 10. Jänner 2005 at 22:19 you wrote to amanda-users:
JL> In recent versions, amanda can work with blocksizes other than 32k.
JL> I forget if it is a configure option needed during the build or
JL> a parameter that can be set in amanda.conf. I've never used it.
The parameter b
Jon,
On Mon, Jan 10, 2005 at 04:19:45PM -0500, Jon LaBadie wrote:
> > Something that didn't error during the write but did
> > during the read ?
> >
>
> This is not too surprising to me.
>
> A tape with a blocksize of 132k will accept a write of 32k and
> simply pad it to the required size. N
On Mon, Jan 10, 2005 at 11:48:42AM -0500, Brian Cuttler wrote:
>
> The following (just scripted, with commentary added) is a little long
> and rather un-good.
>
...
>
> Probing the drive I find a block size of 32768 again.
>
> samar 25# mt -f /dev/sdlt2 setblksz 131072
>
> samar 26# /usr/local
The following (just scripted, with commentary added) is a little long
and rather un-good.
samar 9# script
Script started, file is typescript
Position us at the start of the next volume. This volume has been
relabeled after setting the block size on the tape (last week).
samar 1# /usr/local/sb
Jon,
On Fri, Jan 07, 2005 at 05:45:16PM -0500, Jon LaBadie wrote:
> On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote:
> >
> > samar 24# mt -f /dev/sdlt2 blksize
> >
> > Recommended tape I/O size: 131072 bytes (256 512-byte blocks)
> > Minimum block size: 4 byte(s)
> > Maximum blo
Apologies for following up my own post.
On Sat, Jan 08, 2005 at 06:20:59PM -0500, Eric Siegerman wrote:
> [...] in neither case does [dd] need to copy the data
> from one buffer to another. It can just have a single buffer
> that's max(ibs,obs) long [...]
Oops; I'm wrong about this. It's only t
On Fri, Jan 07, 2005 at 03:11:41PM -0500, Jon LaBadie wrote:
> That ENOMEM, reported as "insufficient memory" sometimes used to
> throw me for a loop. Here is the situation as I understand it.
>
> To enhance performance dd tries to do unbuffered I/O, meaning the
> data goes directly to memory in
On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote:
> samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2
> amrestore: 0: skipping start of tape: date 20050107 label SAMAR05
> amrestore: 1: restoring samar._usr5_amanda.20050107.1
> amrestore: read error: I/O error
> [likewise with "dd b
On Friday 07 January 2005 15:40, Brian Cuttler wrote:
>samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2
>amrestore: 0: skipping start of tape: date 20050107 label SAMAR05
>amrestore: 1: restoring samar._usr5_amanda.20050107.1
>amrestore: read error: I/O error
>
>samar 6# mt -f /dev/sdlt2 rewind
On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote:
>
> samar 24# mt -f /dev/sdlt2 blksize
>
> Recommended tape I/O size: 131072 bytes (256 512-byte blocks)
> Minimum block size: 4 byte(s)
> Maximum block size: 16777212 bytes
> Current block size: Variable
>
> I am using /dev/sdlt
samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2
amrestore: 0: skipping start of tape: date 20050107 label SAMAR05
amrestore: 1: restoring samar._usr5_amanda.20050107.1
amrestore: read error: I/O error
samar 6# mt -f /dev/sdlt2 rewind
samar 7# mt -f /dev/sdlt2 fsf 1
samar 8# dd if=/dev/sdlt2
On Fri, Jan 07, 2005 at 01:20:42PM -0500, Brian Cuttler wrote:
> samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch
> 64+0 records in
> 1+0 records out
>
> "bs" block size, "obs" outpub BS, (there is an IBS also, which I
> am afraid of developing should this not resolve soon)
Yup, this makes sense
On Fri, Jan 07, 2005 at 02:01:26PM -0500, Eric Siegerman wrote:
> On Fri, Jan 07, 2005 at 11:17:21AM -0500, Brian Cuttler wrote:
>
>samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch
>64+0 records in
>1+0 records out
>
>"bs" block size, "obs" outpub BS, (there is an IBS also, which I
>am afraid of de
On Fri, Jan 07, 2005 at 11:59:54AM -0500, Brian Cuttler wrote:
> samar 126# which xfsrestore
> /sbin/xfsrestore
> samar 127# which xfsdump
> /usr/sbin/xfsdump
I suppose the theory must be that anyone can do a restore, but
only root can use [xfs]dump.
--
| | /\
|-_|/ > Eric Siegerman, Toronto
On Fri, Jan 07, 2005 at 11:17:21AM -0500, Brian Cuttler wrote:
> 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 length tape
> device, used amlabel to relabel
On Friday 07 January 2005 13:20, Brian Cuttler wrote:
>Gene,
>
>> 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.
>
>Remembering that I'd set the blocksize on th
Stefan,
> 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 well ??
I'll have to try to pull it again, I seem to have subsequently
overwritten it with a z
Hey Brian,
just now (on 01/07/2005 at 19:20) you wrote:
>> 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.
BC> Remembering that I'd set the blocksize on the
Gene,
> 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.
Remembering that I'd set the blocksize on the device and relabeled
yesterday I tried this.
samar 160#
On Friday 07 January 2005 11:59, Brian Cuttler wrote:
>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 save the
>amanda header, reset the bloc
On Friday 07 January 2005 11:50, Stefan G. Weichinger wrote:
>Hello, Brian,
>
>I thought of your problems this morning ;-)
>
>Just now (on 01/07/2005 at 17:17) you wrote:
>
>BC> Oddly trying to dd if=/dev/rmt/tps... read no data
>
>BC> samar 85# mt -f /dev/rmt/tps1d4nrns rewind
>BC> samar 86# dd if
Hi, Brian,
on Freitag, 07. Jänner 2005 at 17:59 you wrote to amanda-users:
BC> The instruction I was following from Gene where pretty explicite
BC> (not that I follow all that well)
;-)
BC> and where intended to save the
BC> amanda header, reset the block count, restore the header and flush
BC>
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 save the
amanda header, reset the block count, restore the header and flush
the buffers. Unfortuna
Hello, Brian,
I thought of your problems this morning ;-)
Just now (on 01/07/2005 at 17:17) you wrote:
BC> Oddly trying to dd if=/dev/rmt/tps... read no data
BC> samar 85# mt -f /dev/rmt/tps1d4nrns rewind
BC> samar 86# dd if=/dev/rmt/tps1d4nrns of=scratch
BC> Read error: Invalid argument
"Inv
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 length tape
device, used amlabel to relabel the tape (not what Gene indicated).
Oddly trying to dd
Brian Cuttler wrote:
> samar 31# /usr/local/sbin/amrestore -p /dev/sdlt2 samar /usr5/bimal
> | /usr/local/sbin/gnutar -tf -
> amrestore: 0: skipping start of tape: date 20041229 label SAMAR24
> amrestore: 1: skipping samar._usr5_lalor.20041229.0
> amrestore: 2: skipping samar._usr5_tapu.20041
On Friday 31 December 2004 10:49, Brian Cuttler wrote:
>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 problem perhaps it should be incorporat
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 problem perhaps it should be incorporated into amlabel.
Alexander,
Hadn't realized that the 1st ch
On Thursday 30 December 2004 14:55, Brian Cuttler wrote:
>Gene,
>Stefan,
>
>* I'm gonna remove a lot of text from the middle of this.
>
>On Wednesday 29 December 2004 16:29, Brian Cuttler wrote:
>## Amanda2.4.4p1-20030716
>## SGI/IRIX 6.5.19m
>## mtx 1.3.8
>## 8 Slot jukebox with SDLT 32
Gene,
Stefan,
* I'm gonna remove a lot of text from the middle of this.
On Wednesday 29 December 2004 16:29, Brian Cuttler wrote:
## Amanda2.4.4p1-20030716
## SGI/IRIX 6.5.19m
## mtx 1.3.8
## 8 Slot jukebox with SDLT 320 (Quantum)
## gnutar1.13.25
##
## I'm planning to dump 2-3 t
Hi,
on Wednesday 29 December 2004 16:29, Brian Cuttler wrote:
>>Amanda2.4.4p1-20030716
>>SGI/IRIX 6.5.19m
>>mtx 1.3.8
>>8 Slot jukebox with SDLT 320 (Quantum)
>>gnutar1.13.25
>>
>>I suppose this configuration looks familiar to some of you.
>>
>>I was in the process of writing an ema
On Wednesday 29 December 2004 16:29, Brian Cuttler wrote:
>Amanda2.4.4p1-20030716
>SGI/IRIX 6.5.19m
>mtx 1.3.8
>8 Slot jukebox with SDLT 320 (Quantum)
>gnutar1.13.25
>
>I suppose this configuration looks familiar to some of you.
>
>I was in the process of writing an email to thank St
Amanda2.4.4p1-20030716
SGI/IRIX 6.5.19m
mtx 1.3.8
8 Slot jukebox with SDLT 320 (Quantum)
gnutar1.13.25
I suppose this configuration looks familiar to some of you.
I was in the process of writing an email to thank Stefan Weichinger,
Gene Heskett and Eric Siegerman for the terrific
47 matches
Mail list logo
