(reiserfs) possible problem with Rupasov hash?

Hans Reiser reiser at idiom.com
Mon Jan 17 16:00:06 UTC 2000

This is an INN programming bug which ext2 covers over.  It involves mallocing
and assuming the the byte after the malloc'd memory will be 0.


Pawel Krawczyk wrote:
> 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/

Get Linux (http://www.kernel.org) plus ReiserFS
 (http://devlinux.org/namesys).  If you sell an OS or
internet appliance, buy a port of ReiserFS!  If you
need customizations and industrial grade support, we sell them.

More information about the inn-bugs mailing list