Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[INN] Spool compatibility ?

0 views
Skip to first unread message

Xavier Roche

unread,
Sep 13, 2005, 5:45:48 AM9/13/05
to
Hi folks,

It is possible to migrate a INN 2.4.x spool to another platform
(example: migrate from a Solaris machine to Linux) ? Any known
endianness issues with spools such as timecaf ? Can
history.hash/history.index be kept safely ?

Is rsync'ing a complete spool to another machine, and just start the
server, totally stupid ?

Jeffrey M. Vinocur

unread,
Sep 13, 2005, 5:56:00 AM9/13/05
to
In article <dg676c$2fh$1...@news.httrack.net>,

Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
>
>It is possible to migrate a INN 2.4.x spool to another platform
>(example: migrate from a Solaris machine to Linux) ? Any known
>endianness issues with spools such as timecaf ? Can
>history.hash/history.index be kept safely ?

I'm not actually sure about this. But we routinely recommend
feeding the articles across using NNTP and letting the new
machine build its own history and overview from scratch. See
http://www.eyrie.org/~eagle/faqs/inn.html#S6.4 for the recipe.


>Is rsync'ing a complete spool to another machine, and just start the
>server, totally stupid ?

Well, I guess you could try it and see...I wish I had something
more definite to tell you.


--
Jeffrey M. Vinocur
je...@litech.org

Russ Allbery

unread,
Sep 15, 2005, 1:02:37 AM9/15/05
to
Xavier Roche <xro...@free.fr.NOSPAM.invalid> writes:

> It is possible to migrate a INN 2.4.x spool to another platform
> (example: migrate from a Solaris machine to Linux) ? Any known
> endianness issues with spools such as timecaf ? Can
> history.hash/history.index be kept safely ?

tradspool is okay, everything else is suspect. In particular, history,
tradindexed overview, and I'm pretty sure timecaf and buffindexed are all
endian-dependent.

--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Xavier Roche

unread,
Sep 15, 2005, 1:41:32 AM9/15/05
to
Russ Allbery wrote:
> tradspool is okay, everything else is suspect. In particular, history,
> tradindexed overview, and I'm pretty sure timecaf and buffindexed are all
> endian-dependent.

Apparently it is worse: I copied a 2.4.1 timecaf spool to a same
endianness machine (alpha/OSF1 to Linux/Xeon-64) and innd died with
horrible screams:

Sep 14 15:02:36 kayoo kernel: innd[6338]: segfault at 00002aad69fede10
rip 000000000043d9b6 rsp 00007ffffffff9e0 error 4

Moving overwiew to overwiew.old (forcing INN to create an empty
overview) "fixes" the problem - but, of course, everything is empty!

And unfortunately makehistory -O takes ages - I'm wondering if a full
innxmit wouldn't be faster ?

Russ Allbery

unread,
Sep 15, 2005, 1:58:16 AM9/15/05
to
Xavier Roche <xro...@free.fr.NOSPAM.invalid> writes:
> Russ Allbery wrote:

>> tradspool is okay, everything else is suspect. In particular, history,
>> tradindexed overview, and I'm pretty sure timecaf and buffindexed are
>> all endian-dependent.

> Apparently it is worse: I copied a 2.4.1 timecaf spool to a same
> endianness machine (alpha/OSF1 to Linux/Xeon-64) and innd died with
> horrible screams:

> Sep 14 15:02:36 kayoo kernel: innd[6338]: segfault at 00002aad69fede10
> rip 000000000043d9b6 rsp 00007ffffffff9e0 error 4

They're also dependent on the size of various data types, yeah.

> And unfortunately makehistory -O takes ages - I'm wondering if a full
> innxmit wouldn't be faster ?

It shouldn't be, but makehistory isn't necessarily that optimized.

Xavier Roche

unread,
Sep 15, 2005, 5:02:35 AM9/15/05
to
Russ Allbery wrote:
> They're also dependent on the size of various data types, yeah.

But type sizes should be consistence in this case (alpha/opteron have
identical sizes and endianness, if I am not mistaken)

Unfortunately, makehistory crashes while rebuilding the history:

..
@04000043119302C300000000000000000000@
makehistory: no Message-ID header in @04000043119302C400000000000000000000@
*** glibc detected *** double free or corruption (out):
0x00002aaaaadde8c8 ***
Aborted

I guess the only reliable way is to respool the zillions of messages,
which is going to take several weeks :(

Frank Slootweg

unread,
Sep 15, 2005, 7:40:32 AM9/15/05
to
Xavier Roche <xro...@free.fr.nospam.invalid> wrote:
> Russ Allbery wrote:
> > They're also dependent on the size of various data types, yeah.
>
> But type sizes should be consistence in this case (alpha/opteron have
> identical sizes and endianness, if I am not mistaken)

Russ talks about *data types*, not word length. The same (C) data type
might have a different length on different hardware (and even on
different OSs/C-environments on the same hardware). And then there are
the data *alignment* (i.e. byte boundary, 2-byte boundary, 4-byte
boundary, etc.) rules which can be different. Isn't binary data fun!? :-)

[deleted]

Xavier Roche

unread,
Sep 15, 2005, 3:41:14 PM9/15/05
to
Frank Slootweg wrote:
> Russ talks about *data types*, not word length. The same (C) data type

Argh. So I assume the struct's are directly written on disk.

So, let's innxmit ..

Russ Allbery

unread,
Sep 15, 2005, 3:43:49 PM9/15/05
to
Xavier Roche <xro...@free.fr.NOSPAM.invalid> writes:
> Frank Slootweg wrote:

>> Russ talks about *data types*, not word length. The same (C) data type

> Argh. So I assume the struct's are directly written on disk.

Right. INN's data structures are all about speed and simplicity of code,
rather than about portability. (The exception is the ovdb overview
backend, which should be as portable between platforms as BerkeleyDB is.)

0 new messages