We experienced a nasty confluence of suprises:
 - CanOfRaid is imperfect, 
 - reiserfsck is imperfect,
 - our backups were imperfect
[We already knew we were imperfect.]

The result is that all we have left of about 6 weeks of several peoples
development effort is two Data.fs scraps recovered from a reiser fs by one
of the reiser developers.  We also have an intact 2 month old Data.fs
which we would like to update with whatever we can retrieve from these two

Fragment#1 is 187MB where the first 147MB is nothing but nulls and the
remainder is stuff that satisfies a tranalyzer rigged to not gag because
of the missing leading 'FS21'.  The offsets within Fragment#1 are all
correct.  That is, each transaction at the location in the file it thinks
it ought to be.  Fragment#2 is 600KB and has about 500K of nulls at the
beginning.  I am not yet sure if the offsets are 'proper' in it. I presume
that these nulls are artifacts of the restoration process from the

So my question is:  What is the best strategy for getting the Folders, 
DTML Methods, DTML Documents and ZSQL Methods contained in these Data.fs
fragments safely back into production?

Just to get the ball rolling....

I have a done a evening's worth of experimenting with tranalyzer to
evaluate the state of these fragments and explore strategies for getting
their contents back into service.

It seems that it will not work to simply append these zope transaction
records to the end of a Data.fs because these transaction records have
offset data built into them (the backpointer).  Some form of any of the
following could get the job done, but which one?  Is there some better
approach?  An existing tool?  Guru wisdom appreciated...

Plan 1
Simply massage the data so it has the right offset values and then
tack it on the end of the old Data.fs.

  What will happen with transactions which are edits of missing objects?
Plan 2
Have the data drive a program which interacts with a running ZODB and
replays the transactions.  Several ways to do this come to mind...
  a) write  an http client to perform the operations against a normal,
     running Zope
  b) write a tool which uses to read the frag and write to
     the clean Data.fs

Plan 3
Make a human readable form suitable for cut and pasting into zope via
the regular management screens.  

  - Final refuge of the damned because of the redundancy of the data in Data.fs, 
    each update being present...
  - Besides, it just isn't "lazy" enough.

  Shawn Murphy                            Research and Development
  mailto:[EMAIL PROTECTED]                 Emergence by Design

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to