On Thu, Aug 19, 2010 at 2:27 PM, Jean-Francois Malouin <ma...@bic.mni.mcgill.ca> wrote: > I know that a little while ago I reported this problem but I still > can't get my head around it: ever since I upgraded to amanda-3.1.x the > avg tape stats in amreport are bogus. I know for a fact that the > holddisk io read stats (from munin) --as this is when the taper starts > pushing stuff out of the holddisk to the tape-- are consistently above > 100MBs for the run yet amreport says ~14MBs. This lead me to suspect > that the starting time for the taper to start to write the first DLE > is wrongly set or parsed or something along this.
Aside from some estimates based on iostat, do you have evidence that something is incorrect? Are there times that are incorrect (perhaps looking at the timestamped debug logs can help determine this)? Or sizes that are incorrect? Or are the size/time calculations made incorrectly? Barring that, I think I know what you're seeing. If you look in the rightmost column of the table you sent, you'll see write rates around 100MB/s. These are calculated by taking the time and size from first byte to last of each part and summing. Obviously the much shorter parts do not achieve this rate, probably because it includes time to spin the drive up at the beginning and flush buffers at the end. The Avg Tape Write Rate, on the other hand, counts a lot of other stuff in its total. It basically looks at the time between the beginning and end of the dump, which can include headers, filemarks, and even tape changes. >From the perspective of the trace logs, the per-dump rates are based on the sec and kb entries in the PART lines; the Avg Tp Write Rate is based on the sec and kb entries in the DONE and PARTIAL lines. This has been the historical precedent for the content of these log lines. When we discovered this while rewriting the taper and reporting code, the immediate temptation was to "fix" it, but then we'd have a lot of people surprised that the times changed so much in 3.1.1, and I'd be explaining why we changed it.. you just can't win! Dustin P.S. I'll fix the cosmetic bug that amreport claims the tape write is in k/s when it's really in $displayunit/s. -- Open Source Storage Engineer http://www.zmanda.com
