Hello, Ivan.
You wrote 3 февраля 2008 г., 23:35:44:
If so, this is the same class of errors as ZFS (some would call it
tuning errors)
Why this is ever possible on stable (I know, that stable doesn't
meand really stable these days, but at least it is not -CURRENT,
whcih can be experimental)
Ok, subsystem can not work efficiently. Degrade service. Swith to
one 512 byte sector per second speed mode. Disable all caches, doesn't
try to work with all features. Complain 10 times/second on console (and
dmesg buffer). Ok. But PANIC?! NO-NO-NO!!!
Yes given the fact I had a panic and
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
Chris wrote:
Came back to see box had rebooted itself from a journal related panic.
panic: Journal overflow (joffset=49905408 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.
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=49905408 active=499691355136
inactive=4990$
cpuid = 0
AFAIK this means that the journal is too small for
Ivan Voras wrote:
Chris wrote:
Came back to see box had rebooted itself from a journal related panic.
panic: Journal overflow (joffset=49905408 active=499691355136
inactive=4990$
cpuid = 0
AFAIK this means that the journal is too small for your machine - try
doubling it until there
I did some experimentation with gjournal a few weeks ago to determine
how I might partition
a new server, as well as how large to make my journals and where. I did
find that for the computers
I have tested so far, a 1 gig (default size) journal seems to be
sufficient, but half of that or
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
Gary Palmer wrote:
On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote:
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
Chris wrote:
If the only advantage of journaling is to avoid slow fsck's then I may
decide I can live without it, the real attraction to me was been able
to use the much glamorised async which is what made me so shocked when
write speeds were low.
If I understood this thread correctly, the
If I understood this thread correctly, the impression of poor
performance is based on a configuration where both the journal and the
data are on the same physical drive. Intuitively, this will likely
penalize any transaction on the volume, read or write, since you're
asking the drive to not
Michael Butler wrote:
I would think that journaling on one drive and storing the resultant
data-set on another would improve performance enormously (reduced
seek-lengths) and more so if they were 1) high-rpm drives (less
rotational latency) and 2) on different buses (no bus/controller
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
13 matches
Mail list logo
