hi,
actually, squirrelmail is not mounting any fuse device. You are right...
why? :) it's all stored in a database.
as for the cheap hardware.... i'm using virtual machines from Xen to
build both nodes and clients. The thing is that i've already tried to
run nodes and dovecots in non-virtual servers, but i get the same error
sooner or later.
Finally, thanks to help of the people in the glusterfs channel on the
IRC, i upgraded all the packages to the latest development version and
i'll let you know if that works for me.
Thank you all.
En/na Bill Cole ha escrit:
At 11:10 AM +0100 1/28/08, Jordi Moles wrote:
hi.
i've got a clustered mail system with glusterfs and some postfix,
squirrelmail and dovecot machines sharing the same storage system
through glusterfs.
Why?
I can see the Postfix/Dovecot justification (barely) but it seems
pointless for SquirrelMail. What storage does SquirrelMail share with
the other types of machines, and why? Since SquirrelMail normally
accesses mail only via IMAP, there's no point in making the back end
of the IMAP server visible to it.
each server has only postfix or squirrel or dovecot installed on it.
The thing is... dovecot servers hang very often and the last thing
they always log is this:
*************
login: Unable to handle kernel paging request at 0000000000100108 RIP:
[<ffffffff88020838>] :fuse:request_end+0x45/0x109
PGD 1f729067 PUD 1faae067 PMD 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in: ipv6 fuse dm_snapshot dm_mirror dm_mod
Pid: 678, comm: glusterfs Not tainted 2.6.18-xen #1
RIP: e030:[<ffffffff88020838>] [<ffffffff88020838>]
:fuse:request_end+0x45/0x109
RSP: e02b:ffff88001f04dd68 EFLAGS: 00010246
RAX: 0000000000200200 RBX: ffff88001db9fa58 RCX: ffff88001db9fa68
RDX: 0000000000100100 RSI: ffff88001db9fa58 RDI: ffff88001f676400
RBP: ffff88001f676400 R08: 00000000204abb00 R09: ffff88001db9fb58
R10: 0000000000000008 R11: ffff88001f04dcf0 R12: 0000000000000000
R13: ffff88001db9fa90 R14: ffff88001f04ddf8 R15: 0000000000000001
FS: 00002b29187c53b0(0000) GS:ffffffff804cd000(0000)
knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000
Process glusterfs (pid: 678, threadinfo ffff88001f04c000, task
ffff88001fc5a860)
Stack: ffff88001db9fa58 ffff88001f676400 00000000fffffffe
ffffffff88021056
ffff88001f04def8 000000301f04de88 ffffffff8020dd40 ffff88001f04ddb8
ffffffff80225ca3 ffff88001de23500 ffffffff803ef023 ffff88001f04de98
Call Trace:
[<ffffffff88021056>] :fuse:fuse_dev_readv+0x385/0x435
This is almost certainly a bug in the kernel proper, the fuse module,
or possibly the glusterfs client. If you're using cheap hardware it
could also be caused by a hardware issue like an intermittent memory
failure. This failure is at too low a level to be the fault of a
misbehaving application.
[...]
these are basic debian etch brand new set ups, they have nothing else
than dovecot and glusterfs-client installed on them. The thing is all
machines i've got have the very same version of glusterfs-client, but
only the dovecot ones hang.
Do you have any idea?
The same failure across multiple machines implies a problem in
software, not hardware.
The fact that Dovecot is poking this bug where postfix and
squirrelmail are not is not particularly surprising, and doesn't
really indicate a Dovecot flaw. A mailstore server like Dovecot makes
more complex demands for proper behavior from a filesystem than an MTA
like Postfix.
