Paul Ripke wrote:
> I'm guessing you may have tripped over PR kern/20191... If you can get
> into ddb or debug a crash dump, check uvmexp.free and uvmexp.paging. If
> free is low (maybe <= 5) and paging > 0, you've probably run into this
> problem.

Thanks for the excellent hint.

Until now I haven't been able to get beyond plain lockups. I also don't do
this very often with my limited free time and since I want to start from a
clean point every time which means 5hrs of parity rewrite. 

As in the bug report I _did_ mount the fs with -o softdep. However, the box
has 1GB of memory and swap is not on the RAID, although I guess that is not
strictly required to trip over the bug as per:

"After some more research: the problem occurs when the page daemon
 pages out to a RAID5 volume in extreme low memory situations. The
 destination may be a swap device, or it may be a normal RAID5
 filesystem where the page daemon is flushing dirty file pages to
 free memory."

So I'm not entirely sure I'm even affected by this bug. Anyway, I will try
the attached patch and see if it makes a difference.

BTW, I wonder if RAIDframe+cgd on 1.6.1 is a smart "long-term" strategy to
use for personal data. I plan to eventually upgrade to the next stable branch
after 1.6 and want to keep the whole thing running without swapping all data
over to something new too soon. Any thoughts anyone?

Regards

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++