Re: gjournal locks up

From: David N <davidn04_at_gmail.com>
Date: Mon, 25 May 2009 20:39:33 +1000
2009/5/25 Ivan Voras <ivoras_at_freebsd.org>:
> David N wrote:
>> Hi,
>>
>> I've got gjournal on two computers running 7.2-RELEASE (AMD64 and
>> i386) both with SATA-I. (150)
>>
>> GPT + GMirror + GJournal
>>
>> I've had it soft lock, locking up with no HDD activity. And can't do
>> anything, except a hard reset. on both machines.
>>
>> Box1 (i386) removed a slow HDD and replaced with a faster one, that
>> stopped the locking.
>> Box2 (AMD64) just happened today whilst test installing zimbra
>> (Importing MySQL tables).
>>
>> Both have 2GB Journals on /usr and 1GB on /var
>>
>> Has there been any stability patches for GJournal that I can test out?
>> or has there been any commited lately?
>>
>> Or even some tuning that could be done?
>>
>> If you like i can install a DEBUG Kernel and try to lock it again.
>> (Usually heavy disk activity should do it).
>
> You need to provide more data. How do you know that "gjournal" has
> locked up? There is comparatively little in gjournal itself that can
> lock up. Is the machine still responsive to network? In what states
> (wait channels) are the processes on the machine?
>
>

The network seems okay.

The SSH session doesn't close. It just sits there, initiating another
SSH just sits there as well, it doesn't time out or anything.

I'll compile a debug kernel tonight, and I'll put in the other disk
that "should" lock up, tomorrow and copy a few gigs across.


The first time it locked up was when i was copying
cp -va
from one disk (degraded mirrror) to the other disk (degraded mirror +
gjournal). Copied around 40GB until it locked up. It did it 3 times
before i manage to copy everything over. Re-syncing of the mirror
works fine.

Should i use
options KDB
options DDB
options INVARIANTS
options INVARIANTS_SUPPORT
options WITNESS
options DIAGNOSTIC
?

Regards
David N
Received on Mon May 25 2009 - 08:39:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:48 UTC