On Wednesday 31 January 2007 01:27, Toomas Aas wrote: >Hello! > >First, the system details: >FreeBSD 6.2-RELEASE >Amanda 2.5.1p2 >GNU tar 1.16 >All DLEs use GNU tar for backup > >I noticed a strange problem today with this rather new Amanda setup. > Yesterday, a level 0 backup was done of one particular DLE. This DLE is > ca 50 GB in size, which compresses to ca 40 GB. Today's amdump run > started doing level 1 of this same DLE and wrote ca 35 GB, at which > point the HDD holding vtapes ran out of space. > >Level 1 backup of this particular DLE definitely shouldn't be so big. I > looked at sendsize.debug and noticed an interesting problem. The > estimates for level >0 backups for all DLEs are the same size as > estimates for level 0. > >On previous night's amdump run, this problem did not happen - estimates > for incremental backups were noticeably smaller than level 0. > >I noticed an interesting warning message about gnutar_calc_estimates in > sendsize.debug, but this was also present in sendsize.debug for these > amdump runs that didn't have the "incremental equal to full" problem. > So I'm not sure if this is the problem at all. > >Below is the snippet of sendsize.debug for one DLE, which shows level 1 > estimated as big as level 0. I'd appreciate any ideas regarding what > might be the reason for this. > >sendsize[11170]: time 0.636: calculating for amname /storage, dirname > /storage, spindle 1 sendsize[11170]: time 0.636: getting size via > gnutar for /storage level 0 sendsize[11170]: time 0.658: spawning > /usr/local/libexec/amanda/runtar in pipeline sendsize[11170]: argument > list: runtar BACKUP /usr/local/bin/gtar --create --file /dev/null > --directory /storage --one-file-system --listed-incremental > /var/amanda/gnutar-lists/server.domain.ee_storage_0.new --sparse > --ignore-failed-read --totals --exclude-from > /tmp/amanda/sendsize._storage.20070131052001.exclude . >sendsize[11170]: time 139.437: Total bytes written: 51728097280 (49GiB, > 357MiB/s) sendsize[11170]: time 139.440: ..... >sendsize[11170]: estimate time for /storage level 0: 138.782 >sendsize[11170]: estimate size for /storage level 0: 50515720 KB >sendsize[11170]: time 139.440: waiting for runtar "/storage" child >sendsize[11170]: time 139.440: after runtar /storage wait >gnutar_calc_estimates: warning - seek failed: Illegal seek >sendsize[11170]: time 139.441: getting size via gnutar for /storage > level 1 sendsize[11170]: time 139.905: spawning > /usr/local/libexec/amanda/runtar in pipeline sendsize[11170]: argument > list: runtar BACKUP /usr/local/bin/gtar --create --file /dev/null > --directory /storage --one-file-system --listed-incremental > /var/amanda/gnutar-lists/server.domain.ee_storage_1.new --sparse > --ignore-failed-read --totals --exclude-from > /tmp/amanda/sendsize._storage.20070131052220.exclude . >sendsize[11170]: time 206.462: Total bytes written: 51728097280 (49GiB, > 745MiB/s) sendsize[11170]: time 206.468: ..... >sendsize[11170]: estimate time for /storage level 1: 66.563 >sendsize[11170]: estimate size for /storage level 1: 50515720 KB >sendsize[11170]: time 206.468: waiting for runtar "/storage" child >sendsize[11170]: time 206.468: after runtar /storage wait >gnutar_calc_estimates: warning - seek failed: Illegal seek >sendsize[11170]: time 206.468: done with amname /storage dirname > /storage spindle 1
I wonder if that version of tar is biting us again. Can you back up to 1.15-1 and give that a try? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
