[Gluster-users] GlusterFS on mailservers

Mon Nov 15 18:13:15 UTC 2010

We are using glusterFS for our cloud mail servers under 32bit with no
problems at all and the cluster is hit fairly hard on a regular basis.

I think what Craig meant by a workaround was not so much for GlusterFS
but for the Dovecot Imap setup.

Using Dovecot with NFS will give the same problems that GlusterFS does 
so it
might not be fair to blame GlusterFS for the imap problems that some see.

By adding dotlock_use_excl = no, mail_nfs_storage = yes, mail_nfs_index 
= yes to our dovecot.conf file we have not had any problems to date.

Our versions in use of GlusterFS is 3.0.5 and dovecot is 1.2.10 running 
on CentOS  5.5.

Hope this helps.

> On Mon, 15 Nov 2010 10:18:28 -0500
> Joe Landman <landman at scalableinformatics.com> wrote:
>
>   
>> On 11/15/2010 09:47 AM, Stephan von Krawczynski wrote:
>>
>>     
>>>> Stephan -
>>>>      Dovecot has been a challenge in the past. We don't specifically test
>>>> with it here, if you are interested in using it with Gluster I would
>>>> suggest testing with 3.1.1, and always keep the index files local, that
>>>> makes a big difference.
>>>>
>>>> Thanks,
>>>>
>>>> Craig
>>>>         
>>> Well, Craig, I cannot follow your advice as these are 32 bit clients and AFAIK
>>> you said 3.1.1 is not expected to be used in such an environment.
>>> Really quite a lot of interesting setups for glusterfs turn around mail
>>> servers, I judge it to be a major deficiency if the fs cannot be used for such
>>>       
>> Quick interjection here:  We have some customers using Dovecot on our 
>> storage units with GlusterFS 3.0.x.  There are some issues, usually 
>> interactions between dovecot and fuse/glusterfs.  Nothing that can't be 
>> worked around.
>>     
>
> Well, a work-around is not the same as "just working". Do you really think that
> it is no sign of a problem if you need a work-around for a pretty standard
> usage request?
>
>   
>>  We are seeing strong/growing interest from our customer 
>> base in this use case.
>>     
>
> Well, that means I am right, not?
>  
>   
>> Craig's advice is spot on.
>>
>>     
>>> purposes. You cannot expect voting for glusterfs if there are other options
>>> that have no problems with such a standard setup. I mean is there something
>>> more obvious than mailservers for such a fs?
>>>       
>> Hmmm ... apart from NFS (which isn't a cluster file system), which has a 
>> number of its own issues, which other cluster file system are you 
>> referring to, that don't have these sorts of issues?  Small file and 
>> small record performance on any sort of cluster file system is very 
>> hard.  You have to get it right first, and then work on the performance 
>> side later.
>>     
>
> I am not talking of performance currently (though argueable), I am talking
> about the shere basic usage. Probably a lot of potential users come from nfs
> setups and want to make them redundant. And none has ever heard of a fs
> problem with 32 bit clients (just as an example) ...
> So this is an obvious problem.
> "Dovecot has been a challenge in the past", well, and how does the fs
> currently cope with this challenge?
> I am no supporter of the idea that fs tuning should be necessary just to make
> something work at all. For faster performance let there be tuning options, but
> for general support of a certain environment? I mean, did you ever tune
> fat,ntfs,extX or the like just to make email work? And don't argue about them
> not being network related: the simple truth is that this product is only a big
> hit if it is as easy to deploy as a local fs. That should be the primary goal.
>  
>   
>>> Honestly, I got the impression that you're heading away from the mainstream fs
>>> usage to very special environments and usage patterns.
>>> I feel very sorry about that because 2.X looked very promising. But I did not
>>> find a single setup where 3.X could be used at all.
>>>       
>> While I respect your opinion, I do disagree with it. In our opinion 
>> 3.1.x has gotten better than 3.0.x, which was a huge step up from 2.0.x.
>>     
>
> 2.0.x was something like a filesystem, 3.X is obviously heading to be a
> storage platform. That makes a big difference. And I'd say it did not get
> really better in general comparing apples to apples. glusterfs 2.0.x is a lot
> closer to a useable filesystem (lets say on linux boxes) than glusterfs 3.X is
> to netapp or emc storage platforms. There is nothing comparable to glusterfs
> 2.0.X on its boxes whereas one cannot really choose glusterfs storage in
> comparison to netapp. I mean you're trying to enter the wrong league because
> the big players will just crash you.
>  
>   
>> Regards,
>>
>> Joe
>>
>> -- 
>> Joseph Landman, Ph.D
>> Founder and CEO
>> Scalable Informatics, Inc.
>> email: landman at scalableinformatics.com
>> web  : http://scalableinformatics.com
>>         http://scalableinformatics.com/jackrabbit
>> phone: +1 734 786 8423 x121
>> fax  : +1 866 888 3112
>> cell : +1 734 612 4615
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>     
>
>   