(reiserfs) possible problem with Rupasov hash?

Pawel Krawczyk kravietz at ceti.pl
Sat Jan 15 03:01:46 UTC 2000

Our w3cache & news server was running 2.2.14/3.5.15 so far with Rupasov
hash enabled, on over 11 GB of diskspace.

Today I've decided to upgrade to 3.5.16 and after installing new kernel
I've got some problems with INN which got crazy on messed up article
numbers, which became in effect out of synchronization with the active
file. I've got lots 'file exists' errors in INN log file, when it
attempted to symlink articles to names it thought were unused.

It took me about 2 hours to repair that, but most of the time was taken
by reiserfsck --rebuild-tree (3.5.16 version), which was horribly slow
on 2.8 GB partition (filled in about a half). Now, after rebuilding the
active file everything is working OK (still on 3.5.16).

What's interesting I've noticed no problems with Squid, which uses
the majority of ReiserFS diskpace on the server (two separate partitions,
each 4.2 GB big). It also uses Rupasov hash and the only difference
I can think about is that Squid spool is one directory with hundreds
of thousands cached files in it, while the news spool is traditional
comp/unix/programmer-like directory tree. 

I'm not sure if it makes any difference for the hash, so any suggestions
would be valuable. I've always dreamed of moving to CNFS spool, if
that could help :)

Pawel Krawczyk, CETI internet, Krakow. http://ceti.pl/~kravietz/

-- Attached file included as plaintext by Listar --

More information about the inn-bugs mailing list