Updated gjournal patches [20061024].

[Fluffles]

Hi Pawel,

I've tried your recent (20061024) gjournal patches on my test
fileserver, which is an amd64 FreeBSD7 box with 8 SATA disks. I'm
currently using graid5 on it, with success.
I've also tried using gjournal, but with little success. The
compilation/installation and creation of the journal device goes as
planned, but i get kernel panics not long after i start writing to it. A
"newfs -b 65536 /dev/raid5/sophia.journal" quickly panicked the system.
After that i tried without the -b parameter; that appeared to work but
not long after i got a panic again; same panic as before.

Please look at the screenshot i made of the panic message:
http://dev.fluffles.net/images/gjournal-panic1.png

Do you know what could be causing the panic? The panic message itself is
not very explanatory. ;-)
Perhaps gjournal doesn't play nice with graid5? I haven't tried it on a
single disk, yet.

Also i have a question about it's performance. You mentioned earlier
that writing big files takes about twice as long with gjournal, i wonder
if this is inherit to journaling itself or due to the current
implementation. Windows' journaling NTFS, for example, isn't slower than
FAT32 with big files if i remember correctly. What major differences in
the journaling process causes this?

Also, in your earlier post you explained the advantages of a journal
with regard to significantly reduces fsck times at boot. But my major
concern is dataloss: on my testserver i've had many kernel
panics/freezes due to the experimental graid5 module being tested by
Arne. This has resulted in the system not being able to boot because the
ad0s2a (read: a!) partition has lost files. And it won't be the first
time a lockup or power failure caused dataloss on my systems. That's why
i want to use gjournal: to protect from dataloss. Am i correct in my
assumption that gjournal addresses my needs in this regard?

Greetings,

Veronica