Re: GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-12-05 Thread Chris Karakas

Alexandre Oliva wrote:
 
 On Dec  1, 2000, Chris Karakas [EMAIL PROTECTED] wrote:
 
  Do you mean that just by undefining GNUTAR_LISTED_INCREMENTAL_DIR,
  AMANDA is going to call tar using --incremental, instead of
  --listed-incremental?
 
 That's right.
...
 However, you'll still be missing the
 `--newer' flag, that is passed when GNUTAR_LISTED_INCREMENTAL_DIR is
 used.  You may have to work around this problem by reading/storing
 timestamps in the `filename' argument.

I am in the process of undefining GNUTAR_LISTED_INCREMENTAL_DIR and
recompiling. I have had a look at the sources and, as I understand it,
the --newer flag is passed *only* when I *don't* use
GNUTAR_LISTED_INCREMENTAL_DIR. From client-src/sendsize.c, around line
1220:

#ifdef GNUTAR_LISTED_INCREMENTAL_DIR
 " --listed-incremental ", incrname,
#else
 " --incremental",
 " --newer ", dumptimestr,
#endif

So, actually, the --newer flag *will* be passed if I undef
GNUTAR_LISTED_INCREMENTAL_DIR and I don't miss anything, do I?

-- 
Regards

Chris Karakas
Dont waste your cpu time - crack rc5: http://www.distributed.net



Re: GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-12-05 Thread John R. Jackson

I am in the process of undefining GNUTAR_LISTED_INCREMENTAL_DIR and
recompiling.  ...

I think (but am not 100% certain) you can do this when you ./configure
by adding --without-gnutar-listdir.  Make sure you do a "make
distclean" before re-running ./configure.  Check config/config.h for
GNUTAR_LISTED_INCREMENTAL_DIR after running ./configure to see if it's
defined or not for this (re)build.

Chris Karakas

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



Re: GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-12-05 Thread Alexandre Oliva

On Dec  5, 2000, Chris Karakas [EMAIL PROTECTED] wrote:

 Alexandre Oliva wrote:
 
 On Dec  1, 2000, Chris Karakas [EMAIL PROTECTED] wrote:
 
  Do you mean that just by undefining GNUTAR_LISTED_INCREMENTAL_DIR,
  AMANDA is going to call tar using --incremental, instead of
  --listed-incremental?
 
 That's right.
 ...

 However, you'll still be missing the `--newer' flag

[if you go for keeping GNUTAR_LISTED_INCREMENTAL_DIR defined and using
a wrapper script instead.

 , that is passed when GNUTAR_LISTED_INCREMENTAL_DIR is
^ not
 used.  You may have to work around this problem by reading/storing
 timestamps in the `filename' argument.

 So, actually, the --newer flag *will* be passed if I undef
 GNUTAR_LISTED_INCREMENTAL_DIR and I don't miss anything, do I?

Right.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-11-24 Thread David Lloyd


Chris!

 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...(?)

Eeck!

Even RedHat have a later version of GNU tar than 1.1.2 and (honestly)
they're not known to release the latest versions of programs. Upgrade
tar to at least (GNU tar) 1.13.17; the ones below this are likely to
cause all sorts of weird problems.

DL
-- 
Don't you find it rather touching to behold
The OS that came in from the cold
Seen for what it is: religion, plus finesse
Countries, creeds, mean nothing - only Linux...



GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-11-23 Thread Chris Karakas

"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   1  1970 c
drwxrwxr-x   8 chriswindows 16384   1  1970 d
drwxrwxr-x   8 chriswindows 16384   1  1970 e

etc.

( 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
Dont 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 via gnutar for /usr/man level 0
sendsize: getting size via gnutar for /usr/local level 0