On Sat, Oct 9, 2010 at 12:22 PM, Gunnarsson, Gunnar <gunnar.gunnars...@svk.se> wrote: > ok then I must overide the tapetype def with -o option in the amvault command.
I'm not sure about that. Your amvault run demonstrated that your tapes can actually hold almost 6 times the data you've suggested in your default tapetype. That is, amvault stuffed 550% of the configured tapetype 'length' parameter onto a single tape. So I think the length should be changed for *all* runs, not just amvault. But there are cases where you want to use a different length for vaulting runs, and you're right - in those cases you will want to define a new tapetype and use amvault ... -otapetype=MYNEWTAPETYPE As for the waiting-to-flush: from the amdump.1 you sent, I see that the dumper gets a schedule from the planner after 2364 seconds, and first starts writing to tape at 2365 seconds (svksdev3:/extra1, a 1kb DLE). It takes a while for the taper to find its new tape (EMS1-13), which it does at 2372 seconds, and it finishes writing the part about 0.055 seconds later. Sure enough, after that point, the taper remains idle - the driver does not assign it any additional work. This looks like it's related to the multi-taper implementation, so perhaps Jean-Louis can jump in here? Dustin -- Open Source Storage Engineer http://www.zmanda.com
