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.


> 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.

> 
> 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.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)