PDA

View Full Version : Negative numbers in amstatus taper summary section.



Andrew Rakowski
February 20th, 2007, 07:40 AM
I added a bunch of systems to backups yesterday, and I'm waiting for the last (very slow, overloaded system) to finish backups. Meanwhile, when I do an amstatus, I see a few negative numbers in the "taper" area of the SUMMARY section. It looks like this:



SUMMARY part real estimated
size size
partition : 350
estimated : 319 597252m
flush : 0 0m
failed : 34 4286m ( 0.72%)
wait for dumping: 1 4902m ( 0.82%)
dumping to tape : 0 0m ( 0.00%)
dumping : 1 15929m 51526m ( 30.91%) ( 2.67%)
dumped : 314 241458m 536536m ( 45.00%) ( 40.43%)
wait for writing: 0 0m 0m ( 0.00%) ( 0.00%)
wait to flush : 0 0m 0m (100.00%) ( 0.00%)
writing to tape : 0 0m 0m ( 0.00%) ( 0.00%)
failed to tape : 0 0m 0m ( 0.00%) ( 0.00%)
taped : 314 241458m 536525m ( 45.00%) ( 40.43%)
tape 1 : 289 5283799m 5334190m (10319.72%) XXXXset1-68 (5 chunks)
tape 2 : 7 -5187309m -5092325m (-10131.27%) XXXXset1-69 (9 chunks)
tape 3 : 10 46761m 122157m ( 91.33%) XXXXset1-70 (7 chunks)
tape 4 : 4 10525743m 10558362m (20557.69%) XXXXset1-71 (10 chunks)
tape 5 : 4 -10427535m -10385859m (-20365.88%) XXXXset1-72 (11 chunks)
14 dumpers idle : client-constrained
taper writing, tapeq: 0
network free kps: 2251776
holding space : 276314m ( 89.95%)


Those negative numbers might indicate a bit of a problem somewhere in the amcheck code (they don't *seem* to be affecting the dump, so I'll just keep my fingers crossed and wait...) The "tape 2" and "tape 5" entries don't look good, and "tape 4" sure has a larger number then I'm expecting...

Anyhow, I'll keep and eye on it and see how things turn out. The straggler is a cluster front-end system that someone is seriously abusing via NFS from all the calculation nodes, so it's dog-slow trying to back up the filesystem. Ah well, if the scientists didn't use these computers, they wouldn't need me to watch them, so I should be happy! :)

-Andrew

Andrew Rakowski
February 20th, 2007, 02:59 PM
I added a bunch of systems to backups yesterday, and I'm waiting for the last (very slow, overloaded system) to finish backups. Meanwhile, when I do an amstatus, I see a few negative numbers in the "taper" area of the SUMMARY section. -Andrew

I forgot to mention, I saw this on a Redhat Enterprise Linux WS release 4 system, running the amanda-backup_server-2.5.1p3-1.rhel4 RPM I downloaded from the Zmanda.com site. The backup completed fine after the last straggler finished. Sorry about the lack of details (the power company was about to start trenching in front of my house and I needed to abandon my laptop before I got stuck there for the day!)

Cheers,

-Andrew

martineau
February 21st, 2007, 05:17 AM
Could you post the complete amdump.? file use by amstatus.

martineau
February 21st, 2007, 12:21 PM
This bug is already fixed in CVS with the attached patch

Andrew Rakowski
February 21st, 2007, 12:23 PM
Could you post the complete amdump.? file use by amstatus.

I sent you the gzip'd file via direct e-mail. The amdump.2 file compressed down to about 1.3MB in size. If that ends up being too large to e-mail as an attachment, we can work out some other way of getting it to you.

I just checked today's "amstatus XXXXset1" output and see similar negative numbers in the "SUMMARY" section. My small test backup set (33 partitions) did NOT show it for today (all level 1 backups), but it DID show these problems with yesterday's amdump.2 file.

Yesterday's test set backup was all level 0 backups - I just changed all those fully qualified hostnames to shortnames to ease management of our systems - and it wrote about 215GB of backups to virtual tape. I guess I should have asked for a proper method of "renaming" hosts without losing the backups.

-Andrew

Andrew Rakowski
February 21st, 2007, 12:26 PM
This bug is already fixed in CVS with the attached patch

Am I right in assuming that this is an amstatus reporting problem only (so, no data integrity issues)?

-Andrew

martineau
February 21st, 2007, 12:59 PM
yes, it's an amstatus bug