Re: timestamp(?) problems with incremental dumps

* Message by -Lasse Kliemann- from Wed 2007-09-19:
> * Joerg Schilling writes:
> > Lasse Kliemann <[email protected]> wrote:
> 
> > >    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).
> 
> > > (...)
> > >    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.
> > 
> > How does the file look on the snapshot?
> > 
> > The problem may be that the filesystem does not sync meta data fast enough.
>  
> To determine this, I must take a look at the file in question on the snapshot 
> which was used for the level 2 dump. I will do so in the next tests.
 
It's technically slightly more complicated than I thought, because I will 
have to keep the older snapshots around for this during the test. That's why 
I haven't looked into this yet.

However, I discovered further details:

> If this is the case, should a `sync' between touching the timestamp and 
> creating the snapshot help? (Well, it depends on the sync implementation and 
> the filesystem, I guess.)

A single `sync' is not enough.

It seems that `sleep x' with a high enough value of x between the timestamp 
and the snapshot remedies the problem. The interesting point is the choice 
of x. I was able to show that the problem occurs for x=0.299, but although I 
tried very hard, I could *not* provoke the problem with x=0.3. So, 300 
milliseconds seem to be the magic threshold.

Does this number ring a bell for anyone?

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

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

iD8DBQFHE3vx1gObwed86AkRArbIAKDqAwum+htdqHrTGHSfvgNXR9S5iACg1QOk
lkIUjLM2zS0vaS307q4V/q8=
=VaCB
-----END PGP SIGNATURE-----