<div dir="ltr">Can you provide the following details from the time of the pop3 test on FUSE mount:<div><br></div><div>1. mount FUSE client with -LTRACE and logs from that session</div><div><br></div><div>2. strace -f -p <pop3 daemon> -o /tmp/pop3-strace.log</div>
<div><br></div><div>Thanks,</div><div>Avati</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 23, 2013 at 3:56 PM, W K <span dir="ltr"><<a href="mailto:wkmail@bneit.com" target="_blank">wkmail@bneit.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We brought up a test cluster to investigate GlusterFS.<br>
<br>
Using the Quick Start instructions, we brought up a 2 server 1 brick replicating setup and mounted to it from a third box with the fuse mount (all ver 3.4.1)<br>
<br>
# gluster volume info<br>
<br>
Volume Name: mailtest<br>
Type: Replicate<br>
Volume ID: 9e412774-b8c9-4135-b7fb-<u></u>bc0dd298d06a<br>
Status: Started<br>
Number of Bricks: 1 x 2 = 2<br>
Transport-type: tcp<br>
Bricks:<br>
Brick1: gluster2:/gluster1/mailtest/<u></u>brick1<br>
Brick2: gluster1:/gluster1/mailtest/<u></u>brick1<br>
Options Reconfigured:<br>
server.root-squash: no<br>
<br>
We then began loading the cluster with data (from a nearby Mailserver) by rsyncing Maildirs onto the mount. We chose maildirs because small files are supposed to be a worst case scenario in Gluster.<br>
<br>
During our testing, everything worked great. Speed was acceptable (we are familiar with other Distributed File Systems, so we don't have unrealistic expectations).<br>
<br>
We yanked cords, turned off machines and generally tortured the setup, all to good effect. Everything performs as advertised, though you have to do a LOT of googling to get some of the answers when 'recovering'. There appears to be a lot of 'secret' recipes to get things done and I think the doc site should link to JoeJulians blog, among others <grin>.<br>
<br>
We then decided to see what email Maildir performance was like using a pop3 tester program.<br>
<br>
So we quickly installed qmail which has the qmail-pop3d daemon.<br>
<br>
The result was that the pop daemon cant see the email<br>
<br>
# telnet localhost 110<br>
Trying 127.0.0.1...<br>
Connected to localhost.<br>
Escape character is '^]'.<br>
+OK <20481.1385248027@mailtest><br>
USER glusttest<br>
+OK<br>
PASS somepass<br>
+OK<br>
LIST<br>
+OK<br>
.<br>
<br>
If we copy that SAME directory over to /users (not on the gluster mount), then the LIST command shows that email. So we know that the qmail-pop3d setup is working fine.<br>
<br>
LIST<br>
+OK<br>
1 3120<br>
2 11157<br>
3 3267<br>
etc.<br>
<br>
So since we normally use POP/IMAP over NFS, we decided to try the gluster NFS mount.<br>
<br>
That the NFS mount gave us an even stranger result. It doesn't even see the Maildir.<br>
<br>
# telnet localhost 110<br>
Trying 127.0.0.1...<br>
Connected to localhost.<br>
Escape character is '^]'.<br>
+OK <20488.1385248223@mailtest><br>
USER glusttest<br>
+OK<br>
PASS somepass<br>
-ERR this user has no $HOME/Maildir<br>
Connection closed by foreign host.<br>
<br>
<br>
We have verified that the NTP daemon and thus the time settings are correct.<br>
There are NO errors corresponding to this activity in any of the log files on either the data servers or the mount (logs only refer to the mount/unmount ops).<br>
Using the command line, we can manually manipulate files on the mount to our hearts content (as root or as an appropriate user) with no errors. mkdir, rm, touch, all work fine.<br>
<br>
However, using the VmailMGR command line tools, we are unable to add new users when mounted under NFS<br>
<br>
# su - glusttest<br>
<br>
$ vadduser test2<br>
Enter the user's new password:<br>
Please type it again for verification:<br>
vadduser: error adding the virtual user:<br>
Can't create the mail directory './users/test2'<br>
<br>
then when its manually created qmail refused to deliver to that Maildir because it cant see the install<br>
(in this case .qmail file)<br>
<br>
1385249260.729221 delivery 146770: failure: Sorry,_no_mailbox_here_by_<u></u>that_name._(#5.1.1)/<br>
<br>
<br>
Under the FUSE mount, VmailMGR tools work fine and email is able to be delivered to the Maildir.<br>
<br>
$ vadduser test3<br>
Enter the user's new password:<br>
Please type it again for verification:<br>
vadduser: user 'test3' successfully added.<br>
<br>
but of course the pop3 daemon doesn't see the email that qmail process just was just delivered.<br>
<br>
Finally, you can see from the info provided, that we deliberately disabled root_squash (since thats a new 3.4 feature) but that made no difference to any of the above results.<br>
<br>
SELINUX is disabled on all 3 machines.<br>
<br>
So....<br>
<br>
What is going on here?<br>
<br>
Its not a mission critical, as GlusterFS is probably inappropriate for a mailserver, but I really need to understand what is going on so I can recommend GlusterFS for other situations.<br>
<br>
Is this a MailDir thing or is something else going on?<br>
<br>
<br>
Sincerely,<br>
<br>
-bill<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.<u></u>org/mailman/listinfo/gluster-<u></u>users</a><br>
</blockquote></div><br></div>