[geeks] bah.

[Jonathan C. Patschke]

On Fri, 13 Mar 2009, Phil Stracchino wrote:

> Actually, my "most probable cause" theory about the stability issues is
> that the 3Ware board is shaky.

That's what I would suspect, too.

> In the meantime, once I can get the BIOS flashed to v1.08 I'll be trying
> the FreeBSD route again and see if it'll boot amd64 then.

I hope it works out.  Despite 3ware's support team, the hardware is
decent (and you already have it).

>> For example, the gjournal manpage nowhere tells you that if you have
>> enough I/O activity to overrun the journal, your box will panic.  That's
>> the sort of things folks might want to know, just perhaps.
>
> Huh.  Yeah, that'd be an important thing to know ....  but that
> shouldn't be relevant to heavy I/O activity on the storage array managed
> by ZFS, not on the boot pair managed by geom, should it?

No, the things that make ZFS panic are unrelated and largely controllable.
ZFS panics are almost always due to running out of non-pageable physical
memory, which you can corral by limiting the amount of memory ZFS can
gobble up.  GEOM journal panics are largely due to implementation
misfeatures.  GEOM mirrors don't necessarily use gjournal, by the way; you
have to turn that on separately.

The GEOM journal can likely be tuned, too, but I got so disgusted with it
that I didn't look into how one does that.  The downside to not using it
is that, should my podcast server ever crash hard, I've got a few hundred
GB full of files to fsck.  Background fsck mitigates some of that risk,
but filesystem writes are lethargic while background fsck goes one.

-- 
Jonathan Patschke ( "They don't have the right to read a book out loud."
Elgin, TX         (                  --Paul Aiken
USA               (                    Executive Director, Authors Guild