[Zope] Tiny Tables Follow-Up

Wade Pearce ozwolf@iprimus.com.au
Sun, 13 Jan 2002 21:14:33 +1100


This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C19C77.4C16F9E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As a follow-up to my request, I'd like to thank those that replied.

After delving more deeply, we discovered that the Data.fs file had =
become corrupt.  After using fsrecover.py on the file (which cut the =
last 50KB of transactions), we attempted to resurrect our site.  We are =
somewhat confused as to what happened, but we're trying to find out =
what.  The main reason is that logically, what has happened shouldn't.  =
Here is what we did:

With our proper Data.fs file corrupt, we were using an emergency Data.fs =
which has basic necessities and information.  The corrupt Data.fs was =
named Data.fs.2312 (for when it crashed).  The emergency Data.fs was =
240MB in size and Data.fs.2312 was 660MB in size.

1) Copied Data.fs.2312 to Data.fs.recover and ran fsrecover.py on it
2) Stopped Zope
3) Moved Data.fs (the emergency copy) to a backup directory.
4) Renamed Data.fs.recover to Data.fs and restarted Zope.  The site =
remained down and inoperative.
5) Stopped Zope.  Renamed Data.fs to Data.fs.recover and move Data.fs =
back from the backup directory.  Restarted Zope.
6) Checked the site...and the proper site came up (which was supposed to =
be in Data.fs.recover).

The server has now been running since Friday afternoon with the full =
site operational.  I have tested it.  I can add items within the manage =
screens, the server owner can create export files and the site shows =
full operatability with the Postgres database behind it.

We're waiting for a quiet time to reboot the machine to see if it =
reverts.  We have a suspicion that the site we are viewing is in the =
cache memory, but as we've never experienced this before, we're kinda =
stabbing in the dark.

Does anybody have any suggestions as to what has happened here?  The =
Data.fs file Zope is supposed to be accessing is the 240MB file.  For =
the life of us, we're stumped.  Any ideas, suggestions or speculations =
welcome.

Thanks

Wade Pearce

Wedge Tail Eagles Australasian Net Gaming Association =
(http://wtecommand.com)
"Powered by Zope"

------=_NextPart_000_0008_01C19C77.4C16F9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As a follow-up to my request, I'd like =
to thank=20
those that replied.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>After delving more deeply, we =
discovered that the=20
Data.fs file had become corrupt.&nbsp; After using fsrecover.py on the =
file=20
(which cut the last 50KB of transactions), we attempted to resurrect our =

site.&nbsp; We are somewhat confused as to what happened, but we're =
trying to=20
find out what.&nbsp; The main reason is that logically, what has =
happened=20
shouldn't.&nbsp; Here is what we did:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>With our proper Data.fs file corrupt, =
we were using=20
an emergency Data.fs which has basic necessities and information.&nbsp; =
The=20
corrupt Data.fs was named Data.fs.2312 (for when it crashed).&nbsp; The=20
emergency Data.fs was 240MB in size and Data.fs.2312 was 660MB in=20
size.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) Copied Data.fs.2312 to =
Data.fs.recover and ran=20
fsrecover.py on it</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) Stopped Zope</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3) Moved Data.fs (the emergency copy) =
to a backup=20
directory.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>4) Renamed Data.fs.recover to Data.fs =
and restarted=20
Zope.&nbsp; The site remained down and inoperative.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>5) Stopped Zope.&nbsp; Renamed Data.fs =
to=20
Data.fs.recover and move Data.fs back from the backup directory.&nbsp; =
Restarted=20
Zope.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>6) Checked the site...and the proper =
site came up=20
(which was supposed to be in Data.fs.recover).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The server has now been running since =
Friday=20
afternoon with the full site operational.&nbsp; I have tested it.&nbsp; =
I can=20
add items within the manage screens, the server owner can create export =
files=20
and the site shows full operatability with the Postgres database behind=20
it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>We're waiting for a quiet time to =
reboot the=20
machine to see if it reverts.&nbsp; We have a suspicion that the site we =
are=20
viewing is in the cache memory, but as we've never experienced this =
before,=20
we're kinda stabbing in the dark.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does anybody have any suggestions as to =
what has=20
happened here?&nbsp; The Data.fs file Zope is supposed to be accessing =
is the=20
240MB file.&nbsp; For the life of us, we're stumped.&nbsp; Any ideas,=20
suggestions or speculations welcome.</FONT></DIV>
<DIV><BR><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><BR><FONT face=3DArial size=3D2>Wade Pearce</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Wedge Tail Eagles Australasian Net =
Gaming=20
Association (<A=20
href=3D"http://wtecommand.com">http://wtecommand.com</A>)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"Powered by =
Zope"</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C19C77.4C16F9E0--