Mailing List Archive: Zope: Users

Turning back system clock

Index | Next | Previous | View Threaded

D.Sinang at spi-bpo

May 5, 2008, 7:28 PM

Post #1 of 5 (104 views)
Permalink

Turning back system clock

Dear All,

The system clock of our Zope 2.7 machine accidentally got set to 2009.
We noticed this mistake 6 hours later and we decided to set back the
clock to 2008.

How does this affect the integrity of Data.fs ?

>From our observation :

1. Session write errors suddenly began to appear

2. Data.fs.index won't grow anymore and its timestamp remained at the
time we set back the clock

3. Packing the database (which was 8 GB at the time) took too long
without any signs of any Data.fs.pack file in the var folder. We decided
to restart Zope after a few minutes.

4. There seem to be some catalog indexing problems as our catalog
searches on a certain field doesn't work as reliably as it did before.
We tried reindexing the field and even the catalog, but it timed out on
us (lots of objects in the database).

Has anyone here had any similar experiences ? How do I go about fixing
this ?

Using repozo.py last night, I made a full backup of Data.fs, copied it
to a new instance, was able to create a new Data.fs.index, and
eventually succeeded in packing the 8 GB database to just 2.4 GB. But it
took quite a while - like 10 or 15 minutes before any Data.fs.pack
appeared.

I haven't checked yet if the catalog indexing problem has gone away.

Regards,
Danny

lists at zopyx

May 5, 2008, 9:31 PM

Post #2 of 5 (102 views)
Permalink

Re: Turning back system clock [In reply to]

--On 6. Mai 2008 10:28:29 +0800 "Sinang, Danny" <D.Sinang[at]spi-bpo.com>
wrote:

> Dear All,
>
> The system clock of our Zope 2.7 machine accidentally got set to 2009.
> We noticed this mistake 6 hours later and we decided to set back the
> clock to 2008.
>
> How does this affect the integrity of Data.fs ?
>
>> From our observation :
>
> 1. Session write errors suddenly began to appear
>
> 2. Data.fs.index won't grow anymore and its timestamp remained at the
> time we set back the clock
>
> 3. Packing the database (which was 8 GB at the time) took too long
> without any signs of any Data.fs.pack file in the var folder. We decided
> to restart Zope after a few minutes.
>
> 4. There seem to be some catalog indexing problems as our catalog
> searches on a certain field doesn't work as reliably as it did before.
> We tried reindexing the field and even the catalog, but it timed out on
> us (lots of objects in the database).
>
> Has anyone here had any similar experiences ? How do I go about fixing
> this ?

Turning the clock back is known to result in data inconsistencies.
It is is best-practice having NTP installed on all Zope machines.

-aj

D.Sinang at spi-bpo

May 5, 2008, 9:37 PM

Post #3 of 5 (103 views)
Permalink

RE: Turning back system clock [In reply to]

Thanks.

Is there a way to spot these data inconsistencies in Data.fs and remove
or fix them ?

Regards,
Danny

-----Original Message-----
From: Andreas Jung [mailto:lists[at]zopyx.com]
Sent: Tuesday, May 06, 2008 12:31 PM
To: Sinang, Danny; zope[at]zope.org
Subject: Re: [Zope] Turning back system clock

--On 6. Mai 2008 10:28:29 +0800 "Sinang, Danny" <D.Sinang[at]spi-bpo.com>
wrote:

> Dear All,
>
> The system clock of our Zope 2.7 machine accidentally got set to 2009.
> We noticed this mistake 6 hours later and we decided to set back the
> clock to 2008.
>
> How does this affect the integrity of Data.fs ?
>
>> From our observation :
>
> 1. Session write errors suddenly began to appear
>
> 2. Data.fs.index won't grow anymore and its timestamp remained at the
> time we set back the clock
>
> 3. Packing the database (which was 8 GB at the time) took too long
> without any signs of any Data.fs.pack file in the var folder. We
> decided to restart Zope after a few minutes.
>
> 4. There seem to be some catalog indexing problems as our catalog
> searches on a certain field doesn't work as reliably as it did before.
> We tried reindexing the field and even the catalog, but it timed out
> on us (lots of objects in the database).
>
> Has anyone here had any similar experiences ? How do I go about fixing

> this ?

Turning the clock back is known to result in data inconsistencies.
It is is best-practice having NTP installed on all Zope machines.

-aj
_______________________________________________
Zope maillist - Zope[at]zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

lists at zopyx

May 5, 2008, 9:57 PM

Post #4 of 5 (103 views)
Permalink

RE: Turning back system clock [In reply to]

--On 6. Mai 2008 12:37:50 +0800 "Sinang, Danny" <D.Sinang[at]spi-bpo.com>
wrote:

> Thanks.
>
> Is there a way to spot these data inconsistencies in Data.fs and remove
> or fix them ?
>

You might ask Google. This topic came up several times in the past.

-aj

dieter at handshake

May 10, 2008, 12:54 PM

Post #5 of 5 (63 views)
Permalink

Re: Turning back system clock [In reply to]

Sinang, Danny wrote at 2008-5-6 10:28 +0800:
>The system clock of our Zope 2.7 machine accidentally got set to 2009.
>We noticed this mistake 6 hours later and we decided to set back the
>clock to 2008.
>
>How does this affect the integrity of Data.fs ?

Formerly, it was deadly.

Nowadays, most operations will succeed but packing will no longer
be possible (until 2009).

Here some explications.

A "FileStorage" file is a list of transaction records, identified
by a transaction id, which usually is also a timestamp.
"FileStorage" requires that the transaction ids are strictly increasing.

If transactions records were written (i.e. the corresponding transactions
committed) while you have had the wrong time, then your
storage contains some transaction records with ids corresponding to
a date in 2009.
To ensure that transaction ids are increasing, all new transaction ids
are forced to be larger than all existing ones. This means, they seem
to have happened in 2009 immediately after the latest one -- all
of them within an incredibly short time span.

As packing is usually important, you need to fix your
storage before it can be used again in a normal way.
You would use the "transaction iterators" in the
"FileStorage" package to read all transactions, fix the transaction
id (if necessary) and then write it to a new storage file.

--
Dieter
_______________________________________________
Zope maillist - Zope[at]zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com