_____________________________________________________________________ Robert P. McGraw, Jr. Manager, Computer System EMAIL: [EMAIL PROTECTED] Purdue University ROOM: MATH-807 Department of Mathematics PHONE: (765) 494-6055 150 N. University Street FAX: (419) 821-0540 West Lafayette, IN 47907-2067
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jon LaBadie > Sent: Wednesday, April 26, 2006 11:25 AM > To: [email protected] > Subject: Re: tape split question > > > On Wed, Apr 26, 2006 at 10:30:42AM -0400, McGraw, Robert P. wrote: > > I am running Amanda 2.5.0 on a Solaris 10 host. This is the first time I > > have tried the tape_splitsize to backup a large filesystem. > > > > My dump type looks a follows: > > define dumptype users-tar-span { > > global > > comment "backup of users using tar with spanning" > > program "GNUTAR" > > tape_splitsize 30 Gb > > maxdumps 10 > > exclude list "/pkgs/amanda/etc/amanda/exclude/user_exclude" > > } > > > > In /var/amanda/archive/amdump I have > > > > taper: r: end zorn./export/fssnap/users.20060425201728.0 part 6064, > > splitting chunk that started at 62085120kb after 10208kb (next chunk > will > > start at 62095328kb) > > taper: reader-side: got label archive:000068 filenum 6066 > > taper: r: end zorn./export/fssnap/users.20060425201728.0 part 6065, > > splitting chunk that started at 62095360kb after 10208kb (next chunk > will > > start at 62105568kb) > > taper: reader-side: got label archive:000068 filenum 6067 > > > > I killed the backup and the email output from the run showed the > following: > > > > taper: tape archive:000067 kb 172276416 fm 18 writing file: short > write > > taper: retrying zada:/export/data.0 on new tape due to: [writing file: > > short write] > > taper: mmap not available: using fallback split size of 10240kb to > buffer > > zorn:/export/fssnap/users.0 in-memory > > taper: tape archive:000068 kb 173468288 fm 7872 [OK] > > taper: Received signal 15 > > > > The filesystem that I am trying to backup with the tape split is 300GB. > > After 12 hours the 300GB file system had only written about 60GB. I > assume > > the problem is the "mmap not available" and the split size of 10GB > > > > Was that a configure error not able to detect your mmap function? > Or if you really don't have mmap, what system/OS is this? > fssnap sounds like Solaris which certainly has mmap. [McGraw, Robert P.] For now I have increased my holding disk size to be greater than the largest file system. I am not sure if mmap is in Solaris 10 but I would think so. I can do a man mmap and I get the man page. I just ran configure.sh and let if find what is needed. The doc says --with-mmap force use of mmap instead of shared memory suppory I guess I could run configure with --with-mmap and see what happens. > > > > QUESTIONS: > > > > 1) The above log seems to show that the tape_splitsize is 10G and not > the > > 30G that I indicated in the tape_splitsize. Is this correct? Other than > the > > tape_splitsize what other parameter do I need. > > If I read that correctly, the "fallback" splitsize was 10MB, M, not G. [McGraw, Robert P.] I saw that after I sent the email. > > > > > 2) My backup was running slow and and noticed that > zorn./export/fssnap/users > > was not in the HOLDING DISK so it must be reading the backup directly > from > > the disk. My holding disk is 200GB and the filesize that I am backing up > is > > 300GB. Do I need to have my HOLDING DISK size as large as the file > system > > that I am backing up when using the tape_splitsize? > > If the dumpsize is larger than available holding disk, > the dump goes directly to tape. > > Sounds like a number of things might be contributing to bad performance. [McGraw, Robert P.] Thanks for your reply. Reply > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road (609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax)
smime.p7s
Description: S/MIME cryptographic signature
