On Sun, Feb 28, 2010 at 10:59:23AM -0600, Dustin J. Mitchell wrote: ... > > Yes, I just added this warning. Some refinement may be in order, so > let me know what you think. > > The problem is that Amanda's fallback_splitsize defaults to 10M, and > I've seen a number of users recently who are using this splitsize for > multi-terabyte dumps, without knowing it. This generates *terrible* > performance on backup, since the tape drive has to write tens or > hundreds of thousands of filemarks, and also on recovery, since the > recovery app must seek to and read from each of those many thousands > of files. > > This is usually due not to a "fallback" in an error condition, but to > misconfiguration. The splitsize parameters are *very* confusing! > > So the new warning is intended to alert folks such as yourself to the > potential misconfiguration. It's just a warning, so Amanda will > continue to run as before, but you really should fix it. To fix it, > do one of: > * set split_diskbuffer properly > * raise your fallback_splitsize to something larger than 0.001 * tape-length > * set fallback_splitsize to 0 > ... > Amanda always uses the tape_splitsize for FILE-WRITE dumps. It does > the same for PORT-WRITE, but if split_diskbuffer is not set, which is > the case on your system, then it uses fallback_splitsize instead (with > its default of 10M), with no notice of the "fallback". > > So what if I changed the warning to read > > WARNING: shop /home: fallback_splitsize of 10240k < 0.1% of tape > length and may create >1000 parts; set split_diskbuffer or increase > fallback_splitsize >
Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is < 0.1% of tape length. This may create > 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See <appropriate_URL> for more information. jl -- Jon H. LaBadie [email protected] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
