"John R. Jackson" wrote:
>
> >I want to check the level 1 sizes that AMANDA reports. ...
>
> First of all, let's be clear here. It's not Amanda. It's your dump
> program that is reporting sizes. Amanda just uses them.
>
as I wrote in a previous posting, I wanted to wait a little and observe
what is going on. I think I can tell you a little more about my problem
now: It seems that *all* estimates for *vfat* filesystems are wrong, not
just the ones for /dos/f, /dos/n and /dos/o. The vfat filesystems are
mounted at boot time according to the fstab file, which looks like this:
/dev/hda3 /dos/cvfat
defaults,uid=500,gid=101,umask=002 0 0
/dev/hda5 /dos/dvfat
defaults,uid=500,gid=101,umask=002 0 0
/dev/hda6 /dos/evfat
defaults,uid=500,gid=101,umask=002 0 0
etc.
The uid 500 is the user chris and the gid 101 is the group windows. The
AMANDA user, amanda, belongs to the group windows. When I do ls -l for
the /dos directory, I get
drwxrwxr-x 51 chriswindows 16384 &Igr;&agr;&ngr; 1 1970 c
drwxrwxr-x 8 chriswindows 16384 &Igr;&agr;&ngr; 1 1970 d
drwxrwxr-x 8 chriswindows 16384 &Igr;&agr;&ngr; 1 1970 e
etc.
(&Igr;&agr;&ngr; is Jan in greek). The files inside the directories c, d, e etc.
have their normal datestamps.
My suspicion is that GNU tar, which I use in the version 1.12, somehow
cannot compute incrementals right, for filesystems of vfat type that are
mounted the way I described above...(?)
> The first place I would look is /tmp/amanda/sendsize*debug on the client.
> That will show the command used to generate the estimate and everything
> else that went on.
>
> I assume you do not have "record no" floating around?
>
No "record no" in the relevant dumptypes. But also no
/tmp/amanda/sendsize*debug here. There is a /var/lib/amanda/debug
directory, though (correctly, since I specified it as the debug
directory in amanda.conf). I have attached the sendsize.debug file from
a somewhat older AMANDA run.
There is no /var/lib/amanda/gnutar-lists/bacchus_dos_f_1.new, but a
/var/lib/amanda/gnutar-lists/bacchus_dos_f_1. There are lines like
775 6935813 ./original/allied/floppy
775 6953074 ./original/allied/floppy/dosodi
775 6953075 ./original/allied/floppy/ibmlan.os2
775 6953076 ./original/allied/floppy/info
but I cannot see anything suspicious in them. The very first line
contains the epoch, 973836145, meaning Fri Nov 10 7:02:25 2000.
The only thing that catches my attention is the order in which the
estimates are printed. For example, it says
calculating for amname '/dos/f', dirname '/dos/f'
and immediately after:
sendsize: getting size via gnutar for /dos/e level 0
sendsize: running "/usr/lib/amanda/runtar --create --directory /dos/e
--listed-incremental /var/lib/amanda/gnutar-lists/bacchus_dos_e_0.new
--sparse --one-file-system --ignore-failed-read --totals --file
/dev/null ."
Total bytes written: 125317120
On that AMANDA run, in amdump.1, I saw:
got result for host bacchus disk /dos/f: 0 -> 213170K, 1 -> 191710K, -1
-> -1K
got result for host bacchus disk /dos/n: 0 -> 779500K, 1 -> 322920K, 2
-> 322840Kgot result for host bacchus disk /dos/o: 0 -> 170520K, 1 ->
114750K, -1 -> -1K
These 3 filesystems were backed up on level 0 one or two days before and
have not been touched since.
Now, today, in amdump.2, I see:
got result for host bacchus disk /dos/f: 0 -> 213530K, 1 -> 189890K, 2
-> 189540K
AMANDA wanted to bump on level 2, but even that was almost as large as
the level 1! (I see it also for /dos/n in the example above now...) It
_has_ to do something with vfat, GNU tar and mount, or not?
> Are you using dump or GNU tar? If dump, is /etc/dumpdates accessible to
> the Amanda user and being updated? If GNU tar, the same questions apply
> to the listed incremental file (and all the subdirectories down to it).
>
GNU tar. I suppose the listed incremental files are:
-rw-rw 1 amanda disk 5072 Nov 11 07:17 bacchus_dos_c_0
-rw-rw 1 amanda disk 5072 Nov 22 04:22 bacchus_dos_c_1
-rw-rw 1 amanda disk11291 Nov 14 12:03 bacchus_dos_d_0
-rw-rw 1 amanda disk11291 Nov 22 04:25 bacchus_dos_d_1
etc.
I see no problem here.
> Does amcheck have anything interesting to say?
>
No, everything seems to be OK.
I am very grateful for any hint.
--
Regards
Chris Karakas
DonĀ“t waste your cpu time - crack rc5: http://www.distributed.net
sendsize: debug 1 pid 18533 ruid 37 euid 37 start time Fri Nov 10 04:26:26 2000
/usr/lib/amanda/sendsize: version 2.4.1p1
calculating for amname '/', dirname '/'
sendsize: getting size via gnutar for / level 0
calculating for amname '/usr/doc', dirname '/usr/doc'
calculating for amname '/usr/local', dirname '/usr/local'
calculating for amname '/usr/man', dirname '/usr/man'
calculating for amname '/usr/src', dirname '/usr/src'
sendsize: getting size vi