I had originally enabled gjournal and seemed to have no problems but I was seeing errors in messages regarding dma write failures and after some research concluded I had setup gjournal incorrectly. I setup the gjournal again properly with soft updates disabled and doing a fresh newfs, mount showed it as enabled and I had the .journal mounted. Started copying files to it from another partition as I wanted to set that up on gjournal also and the copying I felt would be a good stress test to see if the errors stop, the errors were gone and I felt great but as it was about 80 gig of data to copy I went away to do something else for a bit. Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=499054080000 active=499691355136 inactive=4990$ cpuid = 0 7.0-RC1 Fair to say this is not as stable as ufs + soft updates then? googling did show other occurances of problem or is there a patch/workaround for the issue? disks are both 500 gig each. Chris
Chris wrote:> Came back to see box had rebooted itself from a journal related panic. > > panic: Journal overflow (joffset=499054080000 active=499691355136 inactive=4990$ > cpuid = 0AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it "tuning errors"), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080203/a0fdcb5b/signature.pgp
On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote:> Chris wrote: > > >Came back to see box had rebooted itself from a journal related panic. > > > >panic: Journal overflow (joffset=499054080000 active=499691355136 > >inactive=4990$ > >cpuid = 0 > > AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can be > transfered from the journal to the data area.Is there something stopping gjournal from temporarily blocking writes to the journal to allow it to flush the journaled data to the provider? Thanks, Gary
> AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can be > transfered from the journal to the data area. > > >To double it is to do another newfs and start from scratch again or can I somehow increase the size without losing the data on the drive? Does a larger journal incease write speeds as I am finding them very poor around 60% of a sync + soft updates drive. Chris
Chris wrote:>> AFAIK this means that the journal is too small for your machine - try >> doubling it until there are no more panics. >> >> If so, this is the same class of errors as ZFS (some would call it >> "tuning errors"), only this time the space reserved for the on-disk >> journal is too small, and the fast drives fill it up before data can be >> transfered from the journal to the data area. >> >> >> > > To double it is to do another newfs and start from scratch again or > can I somehow increase the size without losing the data on the drive?If you use an external journal, you can re-create the journal keep the data, if you use an "inline" journal on the same drive as the file system (the default configuration), you need to re-create both the journal and the file system (newfs).> Does a larger journal incease write speeds as I am finding them very > poor around 60% of a sync + soft updates drive.No. An external journal could help you to increase the performance. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080203/003a398e/signature.pgp