(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.

Hans

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