(reiserfs) possible problem with Rupasov hash?
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