timestamp(?) problems with incremental dumps

Recently, I executed some of my tests for filesystem snapshots and incremental 
dumps on a faster system than I usually do. Strangely, I observed some 
problems. The scheme is always like that: take a snapshot, make an incremental 
dump of it, then restore the dump on a different filesystem, and then compare 
the restored version with the snapshot. There should be no differences (except 
in ctime, atime and lmtime, and except for the 'star-symtable' and 
'star-tmpdir' files).

Up to now, this always was the case (except for the mtime bug with special 
files, which is now fixed). Now, as I did test on the faster machine 
(multi-core Xeon, Linux), things sometimes look differently:

- A file is touched as a timestamp, the snapshot is created, then the dump is 
  made with `dumpdate=' pointing to the timestamp file:

   Type of this level 3  dump: full
   Date of this level 3  dump: Thu Sep 13 18:44:40 2007
   Date of last level 2  dump: Thu Sep 13 18:27:17 2007
   star: 14266 blocks + 0 bytes (total of 146083840 bytes = 142660.00k).

- The dump is restored to a different filesystem:

   Dump record  level 3  dump: Thu Sep 13 18:44:40 2007 written
   Validating this dump against restored filesystem...
   Dump is valid, starting restore.
   Removing all in 'star-tmpdir'.
   star: 14266 blocks + 0 bytes (total of 146083840 bytes = 142660.00k).

- Restored version and snapshot are compared:

   diffopts=perm,type,nlink,uid,gid,uname,gname,size,data,rdev,hardlink,
   symlink,sympath,sparse,mtime,dir,acl,xattr,fflags

(...)
   var/log/debug: different size,data,mtime
      8568 -rw-r-----   1 root/adm Sep 13 18:27 2007 var/log/debug
      8160 -rw-r-----   1 root/adm Sep 13 18:11 2007 var/log/debug

The version of 18:27 is from the snapshot and the version of 18:11 is from the 
restored version. Note that the level 2 dump is from 18:27:17 (see above).  
Theory: during the level 3 dump, the file appeared to star as being older than 
18:27:17, which meant that it was already included in the level 2 dump (but it 
in fact was not). Hence it was not included in the level 3 dump and hence, on 
restore, the old version (from 18:11) was not updated.

This looks like typical behavior when the timestamp (later given to star with 
`dumpdate=') is made *after* the snapshot is created. But that's not how I do 
it. Maybe it has to do with accuracy? The times in /etc/tardumps seem to only 
have the accuracy of one second. Then, `sleep 1' between timestamp and snapshot 
should help. I am doing more tests; results are still to be expected.

However, maybe you already have an idea what goes wrong here and where to look 
for the cause.

Regards, Lasse

_______________________________________________
Star-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/star-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG8FLX1gObwed86AkRApSUAJ4un/DMa5haiHeM+A0PNiqyvFSa7ACfYa4L
X5D3shNyjlLAuZiwJaF1bd4=
=oSfG
-----END PGP SIGNATURE-----