Hi,
I'd appreciate hearing from anyone who is running a Postfix cluster with
shared mboxes mounted on an OCFS2 volume. (It looks like directory
entries aren't indexed/hashed on OCFS2, so this rules out Maildirs --
please correct me if this has changed.) Here follows some of my
notes/questions:
I have a four node VMware team set up running a fairly untuned Postfix
2.2 setup on Debian testing. (Presumably there's nothing wrong with
running OCFS2 on non-commercial distros that haven't been blessed by
Oracle.)
Access to shared storage is via AoE (vblade on another machine on the
LAN).
On Debian's 2.6.16-2 kernel I was able to trigger a BUG on one of the
nodes while stress-testing Postfix, see:
http://edmonds.ath.cx/ocfs2_node1_log.txt
Is this anything dangerous? I've upgraded to Debian's 2.6.17-2 kernel
and I haven't been able to trigger it so far.
Under stress-testing (i.e., mailbombing) I see a certain percentage of
mail getting deferred but eventually delivered:
Aug 20 20:23:00 node2 postfix/virtual[3696]: 3D04C54BE3:
to=<user1@test.localdomain>, relay=virtual, delay=9240, status=deferred
(mailbox /var/mail/test.localdomain/user1: unable to lock for exclusive
access: Resource temporarily unavailable)
Is there any way to reduce this lock contention? I assume this will be
less of an issue when running on non-virtual hardware with faster I/O
and a far smaller mail load?
I also see to a lesser degree messages in syslog of this form:
(2703,0):ocfs2_extent_map_insert:603 ERROR: status = -17
Where the only variant is the first number in the tuple. What does this
mean? Is it harmless?
Thanks!
--
Robert Edmonds
That error message is not only harmless but was silenced in OCFS2 1.2.1. Means you are running a fairly old release. Robert Edmonds wrote:> Hi, > > I'd appreciate hearing from anyone who is running a Postfix cluster with > shared mboxes mounted on an OCFS2 volume. (It looks like directory > entries aren't indexed/hashed on OCFS2, so this rules out Maildirs -- > please correct me if this has changed.) Here follows some of my > notes/questions: > > I have a four node VMware team set up running a fairly untuned Postfix > 2.2 setup on Debian testing. (Presumably there's nothing wrong with > running OCFS2 on non-commercial distros that haven't been blessed by > Oracle.) > > Access to shared storage is via AoE (vblade on another machine on the > LAN). > > On Debian's 2.6.16-2 kernel I was able to trigger a BUG on one of the > nodes while stress-testing Postfix, see: > > http://edmonds.ath.cx/ocfs2_node1_log.txt > > Is this anything dangerous? I've upgraded to Debian's 2.6.17-2 kernel > and I haven't been able to trigger it so far. > > Under stress-testing (i.e., mailbombing) I see a certain percentage of > mail getting deferred but eventually delivered: > > Aug 20 20:23:00 node2 postfix/virtual[3696]: 3D04C54BE3: > to=<user1@test.localdomain>, relay=virtual, delay=9240, status=deferred > (mailbox /var/mail/test.localdomain/user1: unable to lock for exclusive > access: Resource temporarily unavailable) > > Is there any way to reduce this lock contention? I assume this will be > less of an issue when running on non-virtual hardware with faster I/O > and a far smaller mail load? > > I also see to a lesser degree messages in syslog of this form: > > (2703,0):ocfs2_extent_map_insert:603 ERROR: status = -17 > > Where the only variant is the first number in the tuple. What does this > mean? Is it harmless? > > Thanks! > >