Re: DLT1 Tape drive performance...
On Thu, Nov 04, 2004 at 05:38:13PM -0600, Dan Brown wrote: > > This may be a problem then as the IDE holding disk is NFS mounted from a > third machine. The server with the backup is a SCSI only system and > doesn't support IDE. It was worth neither the cost of an expensive SCSI > drive (+$700CDN / 80GB?!) nor even a $60IDE card for that matter. When > we get our next server I'll convince the people with the money to move > to SATA based servers. A tape library would be nice eventually too. > > Will adjusting the tapetype help at all to speed up or slow down the > drive or is that only a rated write speed like CDR/RW (the CDs, not the > burners) are rated to maximum speeds before data corruption starts to occur? No adjustment to tapetype I'm aware of would do anything for shoeshining. Specifically, the speed parameter (I suspect that is what you are thinking of changing) is not needed or used by amanda. It merely is printed by the tapetype program because it is an interesting bit of info for the SA and the numbers to calculate it are available after a tapetype run. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
digest?
I believe I have asked this question before but have not had a solution. There is a digest version for this list. It's available through yahoo-groups. However, to be able to post to the list, one needs to be subscribed to the original list, which means I get the full list plus the digest. I would like to post to the list but only received the digest. I can find no way to turn of email delivery from the list to me. Has anyone else had this problem and if so, how did you solve it? From: <[EMAIL PROTECTED]> AND not subject: Amanda-users-digest -> /dev/null? That would be a waste of email resources... thanks and regards -- [EMAIL PROTECTED]
Re: debugging chg-scsi
On Thursday 04 November 2004 17:17, Erik Anderson wrote: >On Thu, 4 Nov 2004 17:12:59 -0500, Gene Heskett > ><[EMAIL PROTECTED]> wrote: >> I probably shouldn't jump in here, but are you aware that some >> changers actually have the changer robot at the same scsi address, >> but at the next higher LUN? I ask, because the default kernels >> shipped with redhat, do not scan all LUNs on bootup to save time. >> In the event thats the case, you'll have to recompile the kernel >> after turning that option on. > >Yes - I'm fairly certain that's not the problem, as is evidenced by > in /proc/scsi/scsi: > >[EMAIL PROTECTED] LPD $ cat /proc/scsi/scsi >Attached devices: >Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 > Type: Direct-AccessANSI SCSI revision: 03 >Host: scsi1 Channel: 00 Id: 01 Lun: 00 > Vendor: ADIC Model: FastStor DLT Rev: D116 > Type: Medium Changer ANSI SCSI revision: 02 >Host: scsi1 Channel: 00 Id: 03 Lun: 00 > Vendor: QUANTUM Model: DLT7000 Rev: 2561 > Type: Sequential-AccessANSI SCSI revision: 02 > >The changer and DLT drive are on different SCSI id's. > >-Erik That looks ok to me Erik. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.28% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: DLT1 Tape drive performance...
Paul Bijnens wrote: Dan Brown wrote: During a backup, or a flush, the tape drive writes data for 4 seconds, then rewinds for 1 second, then writes for 4 seconds, then rewinds for 1 second, etc. This seems like a good way to wear out a drive. That's usually a symptom of a too fast tapedrive connected to a too slow server. But before you trow out the server, verify that your configuration does indeed use the holdingdisk! Not only does that lower the lifetime of the drive, it's also immensly slow. Amanda does quite a good job to keep the tape streaming, using two processes with a shared memory bufferpool (one that fills the bufferpool from the holdingdisk file, the other one that writes the bufferpool to tape). This may be a problem then as the IDE holding disk is NFS mounted from a third machine. The server with the backup is a SCSI only system and doesn't support IDE. It was worth neither the cost of an expensive SCSI drive (+$700CDN / 80GB?!) nor even a $60IDE card for that matter. When we get our next server I'll convince the people with the money to move to SATA based servers. A tape library would be nice eventually too. Will adjusting the tapetype help at all to speed up or slow down the drive or is that only a rated write speed like CDR/RW (the CDs, not the burners) are rated to maximum speeds before data corruption starts to occur? I adjusted the tapebufs setting from 20 to 128, and the DLT drive now writes for around 10 seconds before stopping and seeking. I've adjusted it to 256 to see what happens once I need to flush the holding disk again. I think because of the fact the holding disk is mounted via NFS I may increase this to 512 (16MB) or higher to see what sort of threshold it has. Other possibilities I may try include connecting the holding disk server and the tape server directly via ethernet (they both have a spare connection at the moment) to cut out any network lag issues at our switches (and odd hub). Dan [EMAIL PROTECTED]
Re: debugging chg-scsi
On Thursday 04 November 2004 16:40, Erik Anderson wrote: >On Thu, 04 Nov 2004 15:36:05 -0600, Frank Smith <[EMAIL PROTECTED]> wrote: >> Maybe, mabe not. Depends on the user/group of the devices and the >> user/group Amanda runs as. >> Also, while sg is the proper device to use to control the changer, >> it doesn't understand tape commands like rewind, so make sure your >> tape device is referencing an st device (of course, your kernel >> also needs scsi tape support compiled in or the module loaded or >> you won't have any st devices). > >Okay - well I'm getting conflicting messages here. I had previously >been using /dev/nst0 to access the tape drive. That wasn't working, >so someone here told me I should use the sg* nodes to access the >drive. So that's when I switched to /dev/sg2. I changed the dev >entry in chg-scsi.conf back to /dev/nst0 and this is what I'm still >getting: > >[EMAIL PROTECTED] LPD $ amcheck LPD >Amanda Tape Server Host Check >- >Holding disk /dumps/amanda: 36514756 KB disk space available, that's > plenty amcheck-server: could not get changer info: could not read > result from "/usr/libexec/chg-scsi" > >-Erik While its probably all fubar for your setup, here is a known working chg-scsi.conf from my old setup using a DDS2 drive in a Seagate 4586N changer (4 tape) -- number_configs 1 eject 0 # Tapedrives need an eject command sleep 60 # Seconds to wait until the tape gets ready cleanmax 100 # How many times could a cleaning tape get used scsitapedev /dev/sg0 # test entry per Jean-Louis request changerdev /dev/sg1 debuglevel 9:0 # # Next comes the data for drive 0 # config 0 drivenum 0 dev /dev/nst0 # the device that is used for the tapedrive 0 startuse 0 # The slots associated with the drive 0 enduse 3 # statfile /usr/local/etc/amanda/tape-slot # The file where the actual slot is stored #cleancart 3 # the slot where the cleaningcartridge for drive 0 is located #cleanfile /usr/local/etc/amanda/tape-clean # The file where the cleanings are recorded usagecount /usr/local/etc/amanda/totaltime # This is the end --- Maybe this will help define what might be wrong with yours? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.28% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: debugging chg-scsi
On Thu, 4 Nov 2004 17:12:59 -0500, Gene Heskett <[EMAIL PROTECTED]> wrote: > I probably shouldn't jump in here, but are you aware that some > changers actually have the changer robot at the same scsi address, > but at the next higher LUN? I ask, because the default kernels > shipped with redhat, do not scan all LUNs on bootup to save time. In > the event thats the case, you'll have to recompile the kernel after > turning that option on. Yes - I'm fairly certain that's not the problem, as is evidenced by in /proc/scsi/scsi: [EMAIL PROTECTED] LPD $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: ADIC Model: FastStor DLT Rev: D116 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2561 Type: Sequential-AccessANSI SCSI revision: 02 The changer and DLT drive are on different SCSI id's. -Erik
Re: debugging chg-scsi
On Thursday 04 November 2004 14:37, Christoph Scheeder wrote: >Hi again, >you need WRITE-permisions on the sg-device-nodes to issue commands > to the devices, but your listing only shows read and execute > permisions. mine look like > >crw-rw 1 root backup 21, 0 Aug 28 2000 /dev/sg0 >crw-rw 1 root backup 21, 1 Aug 28 2000 /dev/sg1 >crw-rw 1 root backup 21, 2 Aug 28 2000 /dev/sg2 I probably shouldn't jump in here, but are you aware that some changers actually have the changer robot at the same scsi address, but at the next higher LUN? I ask, because the default kernels shipped with redhat, do not scan all LUNs on bootup to save time. In the event thats the case, you'll have to recompile the kernel after turning that option on. If thats not related, ignore me :) >(it's a 2.4.27-kernel so these look a little different than yours > ;-) Christoph > >Erik Anderson schrieb: >> On Thu, 04 Nov 2004 12:28:11 -0600, Eric Schnoebelen <[EMAIL PROTECTED]> wrote: >>>One thing that chg-scsi seems to need, and I didn't see >>>in the configuration file, is a non-blocking control device for >>>the tape drive, in addition to the blocking device node used for >>>writes.. On linux, the sg* device corresponding to the tape >>>drive is a good one to try. On NetBSD, the `enrst?' device is >>>the one to use.. >> >> Hrm - interesting I'm on linux. I had been using /dev/sg1 as the >> changer device and /dev/nst0 as the DLT drive. See here: >> >> lpdlnx00 dev # ls -la sg* >> lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg0 -> >> scsi/host0/bus0/target0/lun0/generic >> lr-xr-xr-x 1 root disk 36 Oct 29 01:56 sg1 -> >> scsi/host1/bus0/target1/lun0/generic >> lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg2 -> >> scsi/host1/bus0/target3/lun0/generic >> >> and... >> >> lpdlnx00 dev # cat /proc/scsi/scsi >> Attached devices: >> Host: scsi0 Channel: 00 Id: 00 Lun: 00 >> Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 >> Type: Direct-AccessANSI SCSI revision: 03 >> Host: scsi1 Channel: 00 Id: 01 Lun: 00 >> Vendor: ADIC Model: FastStor DLT Rev: D116 >> Type: Medium Changer ANSI SCSI revision: 02 >> Host: scsi1 Channel: 00 Id: 03 Lun: 00 >> Vendor: QUANTUM Model: DLT7000 Rev: 2561 >> Type: Sequential-AccessANSI SCSI revision: 02 >> >> By cross-referencing those two, you would think tha the DLT drive >> could be accessed at /dev/sg2, correct? Well, at first, that >> didn't seem to be working: >> >> lpdlnx00 dev # mt -f /dev/sg2 status >> /dev/sg2: Operation not permitted >> >> However, I just tried putting /dev/sg2 into my chg-scsi.conf. I >> re-ran amcheck, and not it appears that it's actually doing >> something. We'll see how this turns out after it finishes. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.28% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: debugging chg-scsi
On Thu, 04 Nov 2004 15:36:05 -0600, Frank Smith <[EMAIL PROTECTED]> wrote: > Maybe, mabe not. Depends on the user/group of the devices and the > user/group Amanda runs as. > Also, while sg is the proper device to use to control the changer, > it doesn't understand tape commands like rewind, so make sure your > tape device is referencing an st device (of course, your kernel > also needs scsi tape support compiled in or the module loaded or you > won't have any st devices). Okay - well I'm getting conflicting messages here. I had previously been using /dev/nst0 to access the tape drive. That wasn't working, so someone here told me I should use the sg* nodes to access the drive. So that's when I switched to /dev/sg2. I changed the dev entry in chg-scsi.conf back to /dev/nst0 and this is what I'm still getting: [EMAIL PROTECTED] LPD $ amcheck LPD Amanda Tape Server Host Check - Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty amcheck-server: could not get changer info: could not read result from "/usr/libexec/chg-scsi" -Erik
Re: debugging chg-scsi
--On Thursday, November 04, 2004 14:51:54 -0600 Erik Anderson <[EMAIL PROTECTED]> wrote: > On Thu, 04 Nov 2004 20:37:13 +0100, Christoph Scheeder > <[EMAIL PROTECTED]> wrote: >> Hi again, >> you need WRITE-permisions on the sg-device-nodes to issue commands to >> the devices, but your listing only shows read and execute permisions. >> mine look like > > Okay - here's the deal. My /dev/sg* entries are symlins. They're > pointing as follows: > > /dev/sg0 -> scsi/host0/bus0/target0/lun0/generic > /dev/sg1 -> scsi/host1/bus0/target1/lun0/generic > /dev/sg2 -> scsi/host1/bus0/target3/lun0/generic > > The permissions on the symlinks are 555, but the permissions on the > targets are 660, which is correct. Maybe, mabe not. Depends on the user/group of the devices and the user/group Amanda runs as. Also, while sg is the proper device to use to control the changer, it doesn't understand tape commands like rewind, so make sure your tape device is referencing an st device (of course, your kernel also needs scsi tape support compiled in or the module loaded or you won't have any st devices). Frank -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: debugging chg-scsi
On Thu, 04 Nov 2004 20:37:13 +0100, Christoph Scheeder <[EMAIL PROTECTED]> wrote: > Hi again, > you need WRITE-permisions on the sg-device-nodes to issue commands to > the devices, but your listing only shows read and execute permisions. > mine look like Okay - here's the deal. My /dev/sg* entries are symlins. They're pointing as follows: /dev/sg0 -> scsi/host0/bus0/target0/lun0/generic /dev/sg1 -> scsi/host1/bus0/target1/lun0/generic /dev/sg2 -> scsi/host1/bus0/target3/lun0/generic The permissions on the symlinks are 555, but the permissions on the targets are 660, which is correct.
Re: debugging chg-scsi
On Thu, 04 Nov 2004 14:56:55 -0600, Frank Smith <[EMAIL PROTECTED]> wrote: > 'operation not permitted' could be either using the wrong device, > such as trying to rewind the changer device instead of the tape device, > or the permissions on the devices don't allow access to your backup user. > Do you have the proper tape device specified? Does Amanda have r/w > permissions on it? Yes it does. Well maybe. /dev/sg1 (my changer) and /dev/sg2 (my tape drive) are symlinks. The symlinks themselves don't have the correct permissions, but the targets of the symlinks do have the correct permissions.
Re: debugging chg-scsi
--On Thursday, November 04, 2004 13:03:43 -0600 Erik Anderson <[EMAIL PROTECTED]> wrote: > On Thu, 4 Nov 2004 12:54:12 -0600, Erik Anderson <[EMAIL PROTECTED]> wrote: >> However, I just tried putting /dev/sg2 into my chg-scsi.conf. I >> re-ran amcheck, and not it appears that it's actually doing something. >> We'll see how this turns out after it finishes. > > Okay - we're getting closer here. I can feel it ;-) > > Now when I run amcheck - it actually *does* something with the > changer, rather than just erroring out immeadiately. > > [EMAIL PROTECTED] LPD $ amcheck LPD > Amanda Tape Server Host Check > - > Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty > amcheck-server: slot 4: rewinding tape: Operation not permitted 'operation not permitted' could be either using the wrong device, such as trying to rewind the changer device instead of the tape device, or the permissions on the devices don't allow access to your backup user. Do you have the proper tape device specified? Does Amanda have r/w permissions on it? > amcheck-server: fatal slot 5: slot 5 move failed misconfigured/broken changer script or device permissions. If I remember a previous post correctly, you were able to successfully run the changer script directly. Were you testing it as root or your backup user? > ERROR: new tape not found in rack >(expecting a new tape) Possibly just a result of your changer script bombing out, but don't forget you need to label tapes before Amanda can use them. Frank > NOTE: skipping tape-writable test > Server check took 54.047 seconds > > Amanda Backup Client Hosts Check > > Client check: 0 hosts checked in 0.001 seconds, 0 problems found > > (brought to you by Amanda 2.4.4p2) > > I ran it a few times, and each time, the "slot" number advanced each > time. That's why it's currently complaining about slot 4. It did > the same for the other slots as well. > > Ideas? > > -Erik -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: debugging chg-scsi
On Thu, 4 Nov 2004 14:51:54 -0600, Erik Anderson <[EMAIL PROTECTED]> wrote: > Okay - here's the deal. My /dev/sg* entries are symlins. They're > pointing as follows: > > /dev/sg0 -> scsi/host0/bus0/target0/lun0/generic > /dev/sg1 -> scsi/host1/bus0/target1/lun0/generic > /dev/sg2 -> scsi/host1/bus0/target3/lun0/generic > > The permissions on the symlinks are 555, but the permissions on the > targets are 660, which is correct. Sorry - hit the send button prematurely there. If I put the full path to the device into chg-scsi.conf instead of the symline, I get this: [EMAIL PROTECTED] LPD $ amcheck LPD Amanda Tape Server Host Check - Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty amcheck-server: could not get changer info: open: /dev/scsi/host1/bus0/target1/lun0/generic: Success Amanda Backup Client Hosts Check Client check: 0 hosts checked in 0.001 seconds, 0 problems found (brought to you by Amanda 2.4.4p2) With the full path to the scsi devices in chg-scsi.conf, amcheck executes in about a quarter second, so that doesn't seem right.
Re: parse of reply message failed
On Thu, Nov 04, 2004 at 04:11:18AM -0500, foo wrote: > On Thu, Nov 04, 2004 at 09:48:23AM +0100, Paul Bijnens wrote: > > To avoid falling in the same trap, what kernel version was that? > > 2.6.9. I have a dozen other machines running 2.6.9 without this > problem, though. I'm not 100% sure, but it looks like having > CONFIG_PACKET_MMAP disabled causes the bug (disabling it was an accident > on my part, I don't know why you'd want it off). I was wrong, it turns out to be ip_conntrack_amanda from netfilter that's the culprit. I haven't tested yet, but others have confirmed it. I don't actually need it anyway, so I'll see how it goes without. -ryan
Re: dumpcycle / runspercycle / tapecycle best practices?
Eric Siegerman --> amanda-users (2004-11-04 14:02:13 -0500):
> On Wed, Nov 03, 2004 at 10:53:59PM +0100, Jukka Salmi wrote:
> > Hmm, when setting dumpcycle to zero, to what value should runspercycle
> > be set if amdump runs once a day? Zero ("same as dumpcycle") or one?
>
> Both settings are equivalent. From planner.c:
> if (runs_per_cycle <= 0) {
> runs_per_cycle = 1;
> }
>
> So pick the one that looks nicer :-)
Fine, thanks!
Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: debugging chg-scsi
Hi again, you need WRITE-permisions on the sg-device-nodes to issue commands to the devices, but your listing only shows read and execute permisions. mine look like crw-rw 1 root backup 21, 0 Aug 28 2000 /dev/sg0 crw-rw 1 root backup 21, 1 Aug 28 2000 /dev/sg1 crw-rw 1 root backup 21, 2 Aug 28 2000 /dev/sg2 (it's a 2.4.27-kernel so these look a little different than yours ;-) Christoph Erik Anderson schrieb: On Thu, 04 Nov 2004 12:28:11 -0600, Eric Schnoebelen <[EMAIL PROTECTED]> wrote: One thing that chg-scsi seems to need, and I didn't see in the configuration file, is a non-blocking control device for the tape drive, in addition to the blocking device node used for writes.. On linux, the sg* device corresponding to the tape drive is a good one to try. On NetBSD, the `enrst?' device is the one to use.. Hrm - interesting I'm on linux. I had been using /dev/sg1 as the changer device and /dev/nst0 as the DLT drive. See here: lpdlnx00 dev # ls -la sg* lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg0 -> scsi/host0/bus0/target0/lun0/generic lr-xr-xr-x 1 root disk 36 Oct 29 01:56 sg1 -> scsi/host1/bus0/target1/lun0/generic lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg2 -> scsi/host1/bus0/target3/lun0/generic and... lpdlnx00 dev # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: ADIC Model: FastStor DLT Rev: D116 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2561 Type: Sequential-AccessANSI SCSI revision: 02 By cross-referencing those two, you would think tha the DLT drive could be accessed at /dev/sg2, correct? Well, at first, that didn't seem to be working: lpdlnx00 dev # mt -f /dev/sg2 status /dev/sg2: Operation not permitted However, I just tried putting /dev/sg2 into my chg-scsi.conf. I re-ran amcheck, and not it appears that it's actually doing something. We'll see how this turns out after it finishes.
Re: dumpcycle / runspercycle / tapecycle best practices?
On Wed, Nov 03, 2004 at 10:53:59PM +0100, Jukka Salmi wrote:
> Hmm, when setting dumpcycle to zero, to what value should runspercycle
> be set if amdump runs once a day? Zero ("same as dumpcycle") or one?
Both settings are equivalent. From planner.c:
if (runs_per_cycle <= 0) {
runs_per_cycle = 1;
}
So pick the one that looks nicer :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The animal that coils in a circle is the serpent; that's why so
many cults and myths of the serpent exist, because it's hard to
represent the return of the sun by the coiling of a hippopotamus.
- Umberto Eco, "Foucault's Pendulum"
Re: debugging chg-scsi
On Thu, 4 Nov 2004 14:05:05 -0500, Jon LaBadie <[EMAIL PROTECTED]> wrote: > Tough to remember all details of a multi-post thread. No problem.
Re: debugging chg-scsi
On Thu, Nov 04, 2004 at 12:02:23PM -0600, Erik Anderson wrote: > On Thu, 4 Nov 2004 12:52:57 -0500, Jon LaBadie <[EMAIL PROTECTED]> wrote: > > Have you tried reading the debugfiles of amcheck and maybe > > (I've not used it) of chg-scsi? > > > > They are probably in the /tmp/amanda directory. > > No I haven't tried that. They're not in /tmp/amanda. Is that path > set at compile-time? Can be configured, defaults to /tmp/amanda. > > Have you tried running chg-scsi directly? > > Yes - quoting myself from my initial email: > > > If I run chg-scsi directly, this is what I get: > > [EMAIL PROTECTED] LPD $ /usr/libexec/chg-scsi -info > > No device found for tape eject > > No dice. Tough to remember all details of a multi-post thread. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: debugging chg-scsi
On Thu, 4 Nov 2004 12:54:12 -0600, Erik Anderson <[EMAIL PROTECTED]> wrote: > However, I just tried putting /dev/sg2 into my chg-scsi.conf. I > re-ran amcheck, and not it appears that it's actually doing something. > We'll see how this turns out after it finishes. Okay - we're getting closer here. I can feel it ;-) Now when I run amcheck - it actually *does* something with the changer, rather than just erroring out immeadiately. [EMAIL PROTECTED] LPD $ amcheck LPD Amanda Tape Server Host Check - Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty amcheck-server: slot 4: rewinding tape: Operation not permitted amcheck-server: fatal slot 5: slot 5 move failed ERROR: new tape not found in rack (expecting a new tape) NOTE: skipping tape-writable test Server check took 54.047 seconds Amanda Backup Client Hosts Check Client check: 0 hosts checked in 0.001 seconds, 0 problems found (brought to you by Amanda 2.4.4p2) I ran it a few times, and each time, the "slot" number advanced each time. That's why it's currently complaining about slot 4. It did the same for the other slots as well. Ideas? -Erik
Re: debugging chg-scsi
On Thu, 04 Nov 2004 12:28:11 -0600, Eric Schnoebelen <[EMAIL PROTECTED]> wrote: > One thing that chg-scsi seems to need, and I didn't see > in the configuration file, is a non-blocking control device for > the tape drive, in addition to the blocking device node used for > writes.. On linux, the sg* device corresponding to the tape > drive is a good one to try. On NetBSD, the `enrst?' device is > the one to use.. Hrm - interesting I'm on linux. I had been using /dev/sg1 as the changer device and /dev/nst0 as the DLT drive. See here: lpdlnx00 dev # ls -la sg* lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg0 -> scsi/host0/bus0/target0/lun0/generic lr-xr-xr-x 1 root disk 36 Oct 29 01:56 sg1 -> scsi/host1/bus0/target1/lun0/generic lr-xr-xr-x 1 root root 36 Oct 29 01:56 sg2 -> scsi/host1/bus0/target3/lun0/generic and... lpdlnx00 dev # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: ADIC Model: FastStor DLT Rev: D116 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2561 Type: Sequential-AccessANSI SCSI revision: 02 By cross-referencing those two, you would think tha the DLT drive could be accessed at /dev/sg2, correct? Well, at first, that didn't seem to be working: lpdlnx00 dev # mt -f /dev/sg2 status /dev/sg2: Operation not permitted However, I just tried putting /dev/sg2 into my chg-scsi.conf. I re-ran amcheck, and not it appears that it's actually doing something. We'll see how this turns out after it finishes.
Re: debugging chg-scsi
On Thu, 4 Nov 2004 12:52:57 -0500, Jon LaBadie <[EMAIL PROTECTED]> wrote: > Have you tried reading the debugfiles of amcheck and maybe > (I've not used it) of chg-scsi? > > They are probably in the /tmp/amanda directory. No I haven't tried that. They're not in /tmp/amanda. Is that path set at compile-time? > Have you tried running chg-scsi directly? Yes - quoting myself from my initial email: > If I run chg-scsi directly, this is what I get: > [EMAIL PROTECTED] LPD $ /usr/libexec/chg-scsi -info > No device found for tape eject No dice.
Re: debugging chg-scsi
On Thursday November 04 2004 9:52 am, Erik Anderson wrote: > On Thu, 4 Nov 2004 09:44:38 -0800, Stephen Carville <[EMAIL PROTECTED]> wrote: > > Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a > > Spectra 2000 Treefrog and finally gave up. I ended up writing my own > > changer control program. > > That's encouraging. ;-( Well, I don't want to discourage anyone from fixing it. Mostly all I did was port the shell script to Perl and worked from there. Even my Perl chokes once in a while but I suspect that is because the scsi tape driver in Redhat 7.2 is not as good as it could be. Eventually I want to upgrade the tape server to 9 or fedora. -- Stephen Carville http://www.heronforge.net/~stephen/gnupgkey.txt -- Fascism: When Socialism gets down to business.
Re: debugging chg-scsi
Gene Heskett writes: - On Thursday 04 November 2004 12:52, Erik Anderson wrote: - >On Thu, 4 Nov 2004 09:44:38 -0800, Stephen Carville - <[EMAIL PROTECTED]> wrote: - >> Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a - >> Spectra 2000 Treefrog and finally gave up. I ended up writing my - >> own changer control program. - > - >That's encouraging. ;-( - - I used chg-scsi when I had a tape drive, but it did have one gotcha, - it cannot handle a rewind correctly, nothing goes down the cable at - all. That's an issue with the host operating system.. chg-scsi just issues a MTREW to the tape device. If the operating system doesn't do anything with it, well, then there' not much it can do.. (I suppose it could issue a SCSI rewind command directly, but it doesn't currently.) One thing that chg-scsi seems to need, and I didn't see in the configuration file, is a non-blocking control device for the tape drive, in addition to the blocking device node used for writes.. On linux, the sg* device corresponding to the tape drive is a good one to try. On NetBSD, the `enrst?' device is the one to use.. -- eric, who's been using chg-scsi with Exabyte EXB120, EXB480 and HP/Compaq DLT robots. -- Eric Schnoebelen[EMAIL PROTECTED] http://www.cirr.com Remember when Windows were for washing; a mouse was for trapping and a UNIX guarded the harem?
Re: Amanda's dumper going amok
On Thu, Nov 04, 2004 at 09:57:52AM +0100, Paul Bijnens wrote: > Flynn wrote: > > >Amdump sometimes goes crazy apparently eating up all the machine resources > >and I can't get any access to anything when this happens, because I think > >it's lost managing memory swap pages or something. Yes, your symptoms do sound like severe page thrashing. I've never seen that with Amanda either, but there's always a first time :-/ > the loadavg sometimes goes to 12-15 (the 15-minute one!), but I > still can connect to it, run amstatus etc. That's CPU contention. Stuff slows down, but a lot more gracefully than when it's RAM that's the problem, as it seems to be in this case. > Try to gather some data while you use it (e.g. with crontab) about > load and memory use, long list of processes, etc. and hopefully > you see something just before the machines locks up. One easy way is to just run "vmstat 30" all night -- use the "script" command to capture the output. That'll show you whether it is indeed a paging problem. Note that vmstat doesn't print the time, so it can sometimes be useful to run a script like this: while [ 1 ]; do date sleep 300 done in the background in the *same* window as vmstat. The output will be a bit jumbled, but at least it'll be timestamped. Then (or at the same time, in another window) you can run a loop like the above but with a "ps -le" in it, again capturing the output with "script". (I prefer "script" to simple output redirection for stuff like this, because I can both watch the commands as they run and capture their output at the same time.) Of course, if your system has the "sar" stuff installed, you can use that, but there's a bit more learning and setup involved. What I described above is the quick and dirty approach. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, "Foucault's Pendulum"
Re: debugging chg-scsi
On Thursday 04 November 2004 12:52, Erik Anderson wrote: >On Thu, 4 Nov 2004 09:44:38 -0800, Stephen Carville <[EMAIL PROTECTED]> wrote: >> Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a >> Spectra 2000 Treefrog and finally gave up. I ended up writing my >> own changer control program. > >That's encouraging. ;-( I used chg-scsi when I had a tape drive, but it did have one gotcha, it cannot handle a rewind correctly, nothing goes down the cable at all. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.28% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: debugging chg-scsi
On Thu, Nov 04, 2004 at 11:52:16AM -0600, Erik Anderson wrote: > On Thu, 4 Nov 2004 09:44:38 -0800, Stephen Carville <[EMAIL PROTECTED]> wrote: > > Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a Spectra > > 2000 Treefrog and finally gave up. I ended up writing my own changer control > > program. > > That's encouraging. ;-( More encouraging is that many have succeeded, most with little difficulty. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: debugging chg-scsi
On Thu, Nov 04, 2004 at 10:55:48AM -0600, Erik Anderson wrote: > Hello all - is there a way to get more information out of chg-scsi? > I'm trying to debug a wierd issue: > > [EMAIL PROTECTED] LPD $ amcheck LPD Have you tried reading the debugfiles of amcheck and maybe (I've not used it) of chg-scsi? They are probably in the /tmp/amanda directory. Have you tried running chg-scsi directly? If that is what you are trying to debug, why invoke it from another program? You may have to run it from the config dir, not just any dir. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: debugging chg-scsi
On Thu, 4 Nov 2004 09:44:38 -0800, Stephen Carville <[EMAIL PROTECTED]> wrote: > Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a Spectra > 2000 Treefrog and finally gave up. I ended up writing my own changer control > program. That's encouraging. ;-(
Re: debugging chg-scsi
On Thursday November 04 2004 8:55 am, Erik Anderson wrote: > Hello all - is there a way to get more information out of chg-scsi? > I'm trying to debug a wierd issue: Good luck. I tried to get chg-scsi and chg-zg-mtx to works with a Spectra 2000 Treefrog and finally gave up. I ended up writing my own changer control program. > [EMAIL PROTECTED] LPD $ amcheck LPD > Amanda Tape Server Host Check > - > Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty > amcheck-server: could not get changer info: could not read result from > "/usr/libexec/chg-scsi > Amanda Backup Client Hosts Check > > Client check: 0 hosts checked in 0.001 seconds, 0 problems found > > I'm able to move tapes around, read them, etc using mt and mtx. Yes, > I know that I could use chg-zg-mtx, but I'd like to find out why this > is happening for curiosity's sake, if anything. > > If I run chg-scsi directly, this is what I get: > > [EMAIL PROTECTED] LPD $ /usr/libexec/chg-scsi -info > No device found for tape eject > > And here's my chg-scsi.conf: > > number_configs 1 > eject 1 # Tapedrives need an eject command > sleep 5 # Seconds to wait until the tape gets ready > cleanmax10 # How many times could a cleaning tape get used > changerdev /dev/sg1 > config 0 > drivenum0 > dev /dev/nst0 # the device that is used for the tapedrive > 0 startuse0 # The slots associated with the drive 0 > enduse 5 # > statfile/etc/amanda/tape-slot # The file where the actual > slot is stored > cleancart 5 # the slot where the cleaningcartridge for > drive 0 is located > cleanfile /etc/amanda/tape-clean # The file where the cleanings > are recorded > usagecount /etc/amanda/backup/totaltime > > Thanks! -- Stephen Carville http://www.heronforge.net/~stephen/gnupgkey.txt -- Fascism: When Socialism gets down to business.
debugging chg-scsi
Hello all - is there a way to get more information out of chg-scsi? I'm trying to debug a wierd issue: [EMAIL PROTECTED] LPD $ amcheck LPD Amanda Tape Server Host Check - Holding disk /dumps/amanda: 36514756 KB disk space available, that's plenty amcheck-server: could not get changer info: could not read result from "/usr/libexec/chg-scsi" Amanda Backup Client Hosts Check Client check: 0 hosts checked in 0.001 seconds, 0 problems found I'm able to move tapes around, read them, etc using mt and mtx. Yes, I know that I could use chg-zg-mtx, but I'd like to find out why this is happening for curiosity's sake, if anything. If I run chg-scsi directly, this is what I get: [EMAIL PROTECTED] LPD $ /usr/libexec/chg-scsi -info No device found for tape eject And here's my chg-scsi.conf: number_configs 1 eject 1 # Tapedrives need an eject command sleep 5 # Seconds to wait until the tape gets ready cleanmax10 # How many times could a cleaning tape get used changerdev /dev/sg1 config 0 drivenum0 dev /dev/nst0 # the device that is used for the tapedrive 0 startuse0 # The slots associated with the drive 0 enduse 5 # statfile/etc/amanda/tape-slot # The file where the actual slot is stored cleancart 5 # the slot where the cleaningcartridge for drive 0 is located cleanfile /etc/amanda/tape-clean # The file where the cleanings are recorded usagecount /etc/amanda/backup/totaltime Thanks!
Re: Question about backing up (multiple tapes per session on one device)
> Do you have a changer? If so, Amanda will automatically load the next tape > when needed (once you've configured it properly, of course). If not, you > can use chg-manual (a 'virtual' tape changer where you are the changer > and manually swap out tapes as needed). I believe if you have enough > holdingdisk space your backups will continue while its waiting for you > to swap tapes. I haven't used it, perhaps someone else can clarify how > it notifies you that a tape change is needed. I (meaning the client) don't have a changer. Eventually this will have to occur, but until then... I thought by default (I'm using tapedev, not tpchanger) so I think it's configured properly. I'm new to this backup application so I appreciate any input. Thanks, James > > Frank > > > > > Thanks everyone, > > > > James > > > > > -- James Marcinek Systems Engineer JEMConsult.biz, Inc 813.416.1324
Re: dumpcycle / runspercycle / tapecycle best practices?
On Thu, Nov 04, 2004 at 08:31:31AM -0600, Erik Anderson enlightened us: > On Thu, 04 Nov 2004 09:23:10 +0100, Christoph Scheeder > <[EMAIL PROTECTED]> wrote: > > Hi, > > as i'm using chg-scsi with some changers under linux let's check a few > > things : > > 1.) remove all comments from chg-scsi.conf, sometimes i had problems > > with chg-scsi which went away after removing them all. > > 2.) set lastslot to 4 or your cleaningtape will be loaded in every > > search cycle through the magazin. (probably not what you want) > > 3.) your changer and your tapedrive are recognized at bootup by the > > kernel, correct? > > ( do you see both when you do a "cat /proc/scsi/scsi" ?) > > Hello Christoph - I have removed all of the comments from my > chg-scsi.conf, and I have noticed no change in behavior. And yes, my > changer and tape drive are surely recognized by the kernel. I am able > to load/read/write/unload tapes using the mt and mtx commands. > Then why not use chg-zd-mtx? :-) -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 pgpYZq8e1K2Eg.pgp Description: PGP signature
Re: dumpcycle / runspercycle / tapecycle best practices?
On Thu, 04 Nov 2004 09:23:10 +0100, Christoph Scheeder <[EMAIL PROTECTED]> wrote: > Hi, > as i'm using chg-scsi with some changers under linux let's check a few > things : > 1.) remove all comments from chg-scsi.conf, sometimes i had problems > with chg-scsi which went away after removing them all. > 2.) set lastslot to 4 or your cleaningtape will be loaded in every > search cycle through the magazin. (probably not what you want) > 3.) your changer and your tapedrive are recognized at bootup by the > kernel, correct? > ( do you see both when you do a "cat /proc/scsi/scsi" ?) Hello Christoph - I have removed all of the comments from my chg-scsi.conf, and I have noticed no change in behavior. And yes, my changer and tape drive are surely recognized by the kernel. I am able to load/read/write/unload tapes using the mt and mtx commands. Thanks! -Erik
RE: Question about backing up (multiple tapes per session on one device)
Hi, Call amcheck with -m to mail the outputs from the checks. man amcheck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of James Marcinek Sent: 04 November 2004 00:19 To: [EMAIL PROTECTED] Subject: Question about backing up (multiple tapes per session on one device) On to the next hurdle hopefully one of the last. I have one tape device. I will be working with multiple systems so I know that some backups will require multiple tapes. Since the backups will be eventually done on cron, how does one know that a tape change is needed? Will amanda send out an email or something. I'm planning on using amcheck to make sure the correct tape is in prior to kicking the backup off... I just couldn't find anything on this matter. Thanks everyone, James __ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error please delete it immediately and notify the sender. Please also note that in accordance with Invsat's Information Technology policy, emails sent or received may be monitored. __
Re: parse of reply message failed
On Thursday 04 November 2004 04:11, [EMAIL PROTECTED] wrote: >On Thu, Nov 04, 2004 at 09:48:23AM +0100, Paul Bijnens wrote: >> [EMAIL PROTECTED] wrote: >> >On further inspection, it's a kernel problem - bad UDP checksums. >> > >> >I'll go bug them now. :) >> >> To avoid falling in the same trap, what kernel version was that? > >2.6.9. I have a dozen other machines running 2.6.9 without this >problem, though. I'm not 100% sure, but it looks like having >CONFIG_PACKET_MMAP disabled causes the bug (disabling it was an > accident on my part, I don't know why you'd want it off). > >-ryan Check the lkml archive, ISTR there was a discussion centered on this a while back. I've not encountered this problem myself, currently running 2.6.10-rc1-bk13, yesterdays snapshot. With that option turned on. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.28% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Amanda server on MacOSX
Hello Has anybody had experience of setting up Amanda on MacOS 10.3 server ? regards -- Dave Houghton [EMAIL PROTECTED] System Manager Faculty of HumanitiesWork Tel. No. 0116 207 8260 Clephan Building, Room 0.07a De Montfort University Leicester LE1 9BH
Re: parse of reply message failed
On Thu, Nov 04, 2004 at 09:48:23AM +0100, Paul Bijnens wrote: > [EMAIL PROTECTED] wrote: > > >On further inspection, it's a kernel problem - bad UDP checksums. > > > >I'll go bug them now. :) > > To avoid falling in the same trap, what kernel version was that? 2.6.9. I have a dozen other machines running 2.6.9 without this problem, though. I'm not 100% sure, but it looks like having CONFIG_PACKET_MMAP disabled causes the bug (disabling it was an accident on my part, I don't know why you'd want it off). -ryan
Re: parse of reply message failed
[EMAIL PROTECTED] wrote: On further inspection, it's a kernel problem - bad UDP checksums. I'll go bug them now. :) To avoid falling in the same trap, what kernel version was that? -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Chg-disk question
Hi, Gene, on Donnerstag, 04. November 2004 at 01:33 you wrote to amanda-users: >>You mean the "append meta-data"-scripts? >>Haven't found the time yet to improve them, sorry. >>Another curious cat, maybe ... GH> Hmm, I pretty sure it was you as I haven't sent them out exactly GH> willy-nilly. And I thought I heard you mumble something about GH> cleaning them for a more universal way of doing it. A month, maybe 2 GH> back up the log. Or it was wishfull thinking on my part maybe? Yes, you have sent it to me. What I meant was that maybe "another curious cat" could do some cleanup to your scripts now (as I am pretty busy right now with some projects ...) best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Amanda's dumper going amok
Flynn wrote: Amdump sometimes goes crazy apparently eating up all the machine resources and I can't get any access to anything when this happens, because I think it's lost managing memory swap pages or something. I think the responsible is one of the "dumper" process (I caught it and killed it once before it was too late). The disk activity is maximum, I can't get a prompt, I can't get acces through telnet or ssh but the machine still pings. I faced this situation on my first setup, I changed the complete machine (for another reason : I don't even have a tape drive anymore, I now use a 1.2TB raid5 disk with a simulated tape-changer on disk) but I still have this very same problem sometimes, say once a week. The only way to restore control is to reset & reboot - irkkk Did someone ever got into such a situation ? RH9, amanda-2.4.3-4 Never seen that. And my amanda server has only 128 Mbyte RAM, and the loadavg sometimes goes to 12-15 (the 15-minute one!), but I still can connect to it, run amstatus etc. Try to gather some data while you use it (e.g. with crontab) about load and memory use, long list of processes, etc. and hopefully you see something just before the machines locks up. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Problems backup up hde5 (/)
James Marcinek wrote:
OK I got you. Could I still add options, enclosing them with them within the
'{}' fields (eg exlcude "/var/holding" )
servername /var root-tar { exclude "/var/holding" }
Note that the braces syntax REQUIRES that "a line break must
follow the left curly bracket" (from the amanda manpage)
That means you never can put it on one line, as your example suggests.
Put the dumptype inside the brackets.
The filenames after exclude are relative to the toplevel
directory, and thus start with "./".
That results in this DLE:
servername /var {
root-tar
exclude "./holding"
}
--
Paul Bijnens, XplanationTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***
Re: DLT1 Tape drive performance...
Dan Brown wrote: During a backup, or a flush, the tape drive writes data for 4 seconds, then rewinds for 1 second, then writes for 4 seconds, then rewinds for 1 second, etc. This seems like a good way to wear out a drive. That's usually a symptom of a too fast tapedrive connected to a too slow server. But before you trow out the server, verify that your configuration does indeed use the holdingdisk! Not only does that lower the lifetime of the drive, it's also immensly slow. Amanda does quite a good job to keep the tape streaming, using two processes with a shared memory bufferpool (one that fills the bufferpool from the holdingdisk file, the other one that writes the bufferpool to tape). If you have a filesystem that is too large to be put on the holdingdisk, amanda falls write immediately to tape. But now the diskspeed + cputime-to-gzip + networkspeed all come into play and probably cannot follow the tapedrive. Your tapeserver does not have to be a monstrous expensive dragon to keep a tape streaming. My amanda tapeserver is a Linux-PC with a AHA2940 SCSI adapter connected to two AIT-1 tapedrives. The tape writing speed of my backups is 2900-3100 kbytes/sec, which is near the rated speed of the drives. The PC has only 128 Mbyte RAM, and a 300 MHz celeron cpu. But it has a large IDE disk with a 8Mbyte data buffer (one of the faster one in that time) of 80 Gbyte. Our Sunfire 280 with two CPU's is not fast enough to keep the tape streaming (gnutar speed with "compress fast" over network about 2200 kbytes/sec), but the 10 Gbyte holdingdisk file is taped at a rate of 3025 kbytes/sec last weekend). Any suggestions on optimizing settings? Here are my drive configs (minus stuff about logs, users, etc): Really really make sure the backups use the holdingdisk. When using gnutar, you can split up a large filesystem in smaller ones, so that one image does fit in the holdingdisk space. If needed. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Amanda's dumper going amok
Hello Everyone. I have a problem with my Amanda setup. Amdump sometimes goes crazy apparently eating up all the machine resources and I can't get any access to anything when this happens, because I think it's lost managing memory swap pages or something. I think the responsible is one of the "dumper" process (I caught it and killed it once before it was too late). The disk activity is maximum, I can't get a prompt, I can't get acces through telnet or ssh but the machine still pings. I faced this situation on my first setup, I changed the complete machine (for another reason : I don't even have a tape drive anymore, I now use a 1.2TB raid5 disk with a simulated tape-changer on disk) but I still have this very same problem sometimes, say once a week. The only way to restore control is to reset & reboot - irkkk Did someone ever got into such a situation ? RH9, amanda-2.4.3-4 Thanx for any help or feedback, Jean Flinois <[EMAIL PROTECTED]> V-Technologies, Savennières
Re: dumpcycle / runspercycle / tapecycle best practices?
Hi, as i'm using chg-scsi with some changers under linux let's check a few things : 1.) remove all comments from chg-scsi.conf, sometimes i had problems with chg-scsi which went away after removing them all. 2.) set lastslot to 4 or your cleaningtape will be loaded in every search cycle through the magazin. (probably not what you want) 3.) your changer and your tapedrive are recognized at bootup by the kernel, correct? ( do you see both when you do a "cat /proc/scsi/scsi" ?) Christoph Erik Anderson schrieb: On Wed, 3 Nov 2004 17:46:19 -0500, Jon LaBadie <[EMAIL PROTECTED]> wrote: I've not used the scsi chg script/program. Have you read and done what it says in the documentation and example files to set up config files for chg-scsi ... Yes, indeed I have. Here's my chg-scsi.conf: number_configs 1 eject 1 # Tapedrives need an eject command sleep 5 # Seconds to wait until the tape gets ready cleanmax10 # How many times could a cleaning tape get used changerdev /dev/sg1 # # Next comes the data for drive 0 # config 0 drivenum0 dev /dev/nst0 # the device that is used for the tapedrive 0 startuse0 # The slots associated with the drive 0 enduse 5 # statfile/etc/amanda/tape-slot # The file where the actual slot is stored cleancart 5 # the slot where the cleaningcartridge for drive 0 is located cleanfile /etc/amanda/tape-clean # The file where the cleanings are recorded usagecount /etc/amanda/backup/totaltime
