Hello again,
I did not receive any answers to my posting, so I repost it below, just
in case something went wrong.
The main point is that AMANDA interprets the number of blocks from the
SAMBA du command as the wanted estimate, which is wrong and that this is
not the old "-d 3" (debug level in smb.conf must be at least 3) problem
discussed in the docs.
Since nobody else complains about this, I assume that I miss something -
but what?
----------- Original posting follows ---------------
Hello,
today AMANDA made me angry... She tried to write 748,4MB on a tape that
is declared as having a capacity of only 660000KB! The result was "end
of tape" and I had to use another medium to backup just 153,4MB.
I decided to find out why. I checked amdump.1. What happened? AMANDA
gets the wrong estimate for the SAMBA share //nymphe/e (also for the
other SAMBA shares):
got result for host bacchus disk //nymphe/e: 0 -> 38377K, 1 -> 38377K, 2
-> 38377K
But the e share on nymphe has 216MB!
Then:
pondering bacchus://nymphe/e... next_level0 2 last_level 1 (not due for
a full dump, picking an incr level)
pick: size 38377 level 1 days 5 (thresh 51200K, 2 days)
...and then AMANDA decides to promote //nymphe/e for a full backup. The
estimated size jumps only from 625017 to 651016, which is within the
limit of 660000:
promote: moving bacchus://nymphe/e up, total_lev0 375713, total_size
651016
This is fatal, because I get an "end of tape error", since the level 0
image of //nymphe/e is at least 100MB (taking into account that I use
maximum client compression).
Hmm...so I get the wrong estimate. I checked sendsize.debug:
----------- start snip --------------
sendsize: getting size via smbclient for //nymphe/e level 0
sendsize: running "/usr/bin/smbclient '\\nymphe\e' XXXXX -d 0 -U chris
-E -c 'archive 0;recurse;du'"
added interface ip=192.168.0.1 bcast=192.168.0.255 nmask=255.255.255.0
Total bytes written: 276480
.....
38377 blocks of size 8192. 10637 blocks available
Total number of bytes: 205021041.....
sendsize: getting size via smbclient for //nymphe/e level 1
sendsize: running "/usr/bin/smbclient '\\nymphe\e' XXXXX -d 0 -U chris
-E -c 'archive 1;recurse;du'"
added interface ip=192.168.0.1 bcast=192.168.0.255 nmask=255.255.255.0
38377 blocks of size 8192. 10637 blocks available
Total number of bytes: 183909873.....
sendsize: getting size via smbclient for //nymphe/e level 2
sendsize: running "/usr/bin/smbclient '\\nymphe\e' XXXXX -d 0 -U chris
-E -c 'archive 1;recurse;du'"
added interface ip=192.168.0.1 bcast=192.168.0.255 nmask=255.255.255.0
38377 blocks of size 8192. 10637 blocks available
Total number of bytes: 183909873.....
Total bytes written: 788316160
.....
sendsize: getting size via gnutar for /dos/l level 1
----------- end snip --------------
Clearly AMANDA interprets the number of blocks (38377) as the wanted
estimate, which is wrong. Clearly also, it is not the old "-d 3" (debug
level in smb.conf must be at least 3) problem, since AMANDA recognized
that I use SAMBA 2.x and used the "du" command.
I use: amanda 2.4.1p1, samba 2.0.6, tar 1.12, samba2-20000418.diff
patch, debug level = 2 in smb.conf.
Do I miss yap (yet another patch)? Don't tell me the answer is yup...
--
Regards
Chris Karakas
Don´t waste your cpu time - crack rc5: http://www.distributed.net
