email reports in tape order?
Is it possible to have the email reports list the file systems in the order they were written to tape? this would make it much easier to locate a file on the tape, especially if you have a lot of file systems. g.
RE: amreport broken between 2.4.1p1 and 2.4.2
Thanks for the tip. For those interested, I am now using: columnspec "HostName=0:10,Disk=1:18,OrigKB=1:8,OutKB=1:8,DumpRate=0:7,TapeRate=0:7" which works quite well on some of our longer hostnames and bigger disk sizes. g. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of John R. Jackson > Sent: Monday, 29 January 2001 11:56 AM > To: Grant Beattie > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: amreport broken between 2.4.1p1 and 2.4.2 > > > >The email output of amreport seems to have been broken somewhere between > >2.4.1p1 and 2.4.2. > > What you call "broken", others call a new "feature" :-). > > Look for "columnspec" in "man amanda". FYI, here's what I use: > > columnspec "OrigKB=1:8,OutKB=1:8,DumpRate=0:7,TapeRate=0:7"
RE: why | ufsrestore?
How does one configure the blocksize? What about the blocksize used on the tape? perhaps that can be tuned, too... g. > -Original Message- > From: Marc W. Mengel [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 30 January 2001 3:12 AM > To: [EMAIL PROTECTED] > Cc: Grant Beattie; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: why | ufsrestore? > > > > > On Sun, 28 Jan 2001, John R. Jackson wrote: > > > > But you're comparing apples and oranges. As you've noted, going from > > disk to tape on the same machine gets 3 MBytes/s whether you are using > > ufsdump or Amanda is using taper to copy a holding disk image. > > > > But that's not what happens when Amanda is dumping a client direct to > > tape. The data has to go across the network (even if it's all on the > > local machine it still goes through the kernel network stack). And, > > probably even more important, Amanda does compression when dumping, > > not when writing to tape. > > > > So a dump to holding disk would be "slow" but the corresponding holding > > disk to tape operation would be "fast". But a direct to tape backup > > would pay the penalty and show the speed loss due to compression even > > though the tape I/O portion is going as fast as it is given data. > > > > You didn't mention what kind of dump rates Amanda reports. Those should > > more or less match your direct to tape numbers for large enough images > > to get a good sample and with similar clients. > > > > Note that I'm not saying something isn't wrong in Amanda. Just that > > we need to narrow down the list of culprits. > > We've gotten excellent results here with cranking up the blocksize > of writes to the network in our old backup scripts (which always go > direct to tape). Everywhere except OSF1, which seems to get confused... > > Marc > > >
RE: why | ufsrestore?
> >I have always wondered .. why does amanda pipe ufsdump output to > ufsrestore > >before sending it to the tape device? > > It's collecting the index data. John, thanks for clarifying... > >If amanda is dumping direct to tape (file systems that are > bigger than the > >holding disk), I'm lucky if i get 1mb/second. > > > >If it's going from the holding disk to tape, I get 3mb/second, > as expected. > > But you're comparing apples and oranges. As you've noted, going from > disk to tape on the same machine gets 3 MBytes/s whether you are using > ufsdump or Amanda is using taper to copy a holding disk image. > > But that's not what happens when Amanda is dumping a client direct to > tape. The data has to go across the network (even if it's all on the > local machine it still goes through the kernel network stack). And, > probably even more important, Amanda does compression when dumping, > not when writing to tape. > > So a dump to holding disk would be "slow" but the corresponding holding > disk to tape operation would be "fast". But a direct to tape backup > would pay the penalty and show the speed loss due to compression even > though the tape I/O portion is going as fast as it is given data. I should have mentioned, we have several ~10Gb file systems (on the same system as the tape drive, Amanda server), and none of these are dumped with compression (for speed reasons). > You didn't mention what kind of dump rates Amanda reports. Those should > more or less match your direct to tape numbers for large enough images > to get a good sample and with similar clients. The dump rates reported by Amanda are around 1.0-1.5mb/second (without compression). A direct ufsdump to tape without Amanda on the same file systems run at 3mb/second (which is the fastest that the tape drive can accept the data). Given the complexity of the Amanda sendbackup process this doesn't exactly surprise me, but I wondered if I could do anything to speed things up. The system is a little underpowered and perhaps when we get our much needed upgrade (a nice new dual cpu E220R), things will improve... g.
why | ufsrestore?
I have always wondered .. why does amanda pipe ufsdump output to ufsrestore before sending it to the tape device? If I ufsdump direct to tape, eg. ufsdump 0f /dev/rmt/0n / I consistently achieve 3mb/second (Exabyte mammoth). If amanda is dumping direct to tape (file systems that are bigger than the holding disk), I'm lucky if i get 1mb/second. If it's going from the holding disk to tape, I get 3mb/second, as expected. g.
amreport broken between 2.4.1p1 and 2.4.2
The email output of amreport seems to have been broken somewhere between 2.4.1p1 and 2.4.2. The column widths are incorrectly determined and the output is particularly messy with large file systems (and/or large lengths of time, etc). It would also make more sense (to me, at least) for the output figures to be represented in Mb and Mb/sec rather than Kb and Kb/sec. This would probably help the email readability. Comments, thoughts? g.
RE: barcodes
Is this known to work with the Exabyte EXB-210/220? g. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Hepper Sent: Sunday, 28 May 2000 5:10 PM To: Yura Pismerov Cc: [EMAIL PROTECTED] Subject: Re: barcodes Hi, On Wed, May 10, 2000 at 12:30:01PM -0400, Yura Pismerov wrote: > > > Hello everybody, > > I'm trying to play with barcode feature in Amanda-2.4.2 and it seems > not working for me. Might be OK :-), the barcode feature works only with some libraries. > Documentation says that Amanda should update labelfile after "amtape > config show" but it does not appear. Also there is nothing helpful in > the chg-scsi.debug file. Can you send me please the debug file from chg-scsi, and can you check if you can get an pointer to the SCSI Command reference of you library. With the docs it should be possible to support it. Thomas -- --- | Thomas Hepper[EMAIL PROTECTED] | | ( If the above address fail try ) | | ( [EMAIL PROTECTED]) | ---
