Re: timestamp(?) problems with incremental dumps

Lasse Kliemann <[email protected]> wrote:

> > > 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.

OK, this verifies that the problem is caused by the implementation of filesystem 
in the kernel. I would even call it a bug if you may create a snapshot that
refers to unstable (unreliable) data.

On Solaris, creating a snapshot results in write-loking the FS, syncing, 
creating the snapshot and removing the write-lock. This gives you reliable
data in the snapshot.

I would encourage you to send a bug report to the relevent people.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]                (uni)  
       [email protected]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily