[Gluster-users] Concurrent writes management.
COCHE Sébastien
SCOCHE at sigma.fr
Tue Jul 1 10:08:53 UTC 2014
OK, but how can I know if an application use fcntl lock ?
Few common examples : Apache webserver, KVM hypervisor, Postgresql/mysql Database
What's happen if two split-brained nodes run the same database file or the same virtual machine virtualdisk ?
How can I know if those solutions use fcntl lock ?
Sorry for my insistence :-/
Sébastien Coché,
Architecte Infrastructure (DIP)
SIGMA Informatique - www.sigma.fr
8 rue Newton - CS 84533 - 44245 LA CHAPELLE SUR ERDRE CEDEX
Tél : (+33) 2.53.48.92.57 - Mob : 06 22 25 03 74
-----Message d'origine-----
De : Niels de Vos [mailto:ndevos at redhat.com]
Envoyé : mardi 1 juillet 2014 11:43
À : COCHE Sébastien
Cc : Pranith Kumar Karampuri; gluster-users at gluster.org
Objet : Re: [Gluster-users] Concurrent writes management.
On Tue, Jul 01, 2014 at 07:28:15AM +0000, COCHE Sébastien wrote:
> Does it mean that if I use gluster FUSE driver or NFS client, fcntl
> locks are manages and no data corruption could happen ?
It is always good practise to use read/write fcntl locks when multiple processes or threads use the same file. These locks are handled correctly for files located on Gluster volumes. The application developer is responsible for implementing these locks, Gluster does not magically/transparently add these (I don't think any filesystem can do that).
Cheers,
Niels
>
> Sébastien Coché,
> Architecte Infrastructure (DIP)
> SIGMA Informatique - www.sigma.fr<http://www.sigma.fr/>
> 8 rue Newton - CS 84533 - 44245 LA CHAPELLE SUR ERDRE CEDEX Tél :
> (+33) 2.53.48.92.57 - Mob : 06 22 25 03 74
>
> De : Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Envoyé :
> lundi 30 juin 2014 18:08 À : COCHE Sébastien Cc :
> gluster-users at gluster.org Objet : Re: [Gluster-users] Concurrent
> writes management.
>
>
> On 06/30/2014 09:26 PM, COCHE Sébastien wrote:
> Thank you for your response.
> I understand that the file exist only one time on the volume. But it can be accessed in write, by many nodes (clients) at the same time.
> What's happen in those case ?
> Nothing bad will happen to the filesystem. But the file may not be meaningful if the applications writing to it don't synchronize overlapping concurrent writes with fcntl locks.
>
> Pranith
>
>
>
> Sébastien Coché,
> Architecte Infrastructure (DIP)
> SIGMA Informatique - www.sigma.fr<http://www.sigma.fr/>
> 8 rue Newton - CS 84533 - 44245 LA CHAPELLE SUR ERDRE CEDEX Tél :
> (+33) 2.53.48.92.57 - Mob : 06 22 25 03 74
>
> De : Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Envoyé :
> lundi 30 juin 2014 17:49 À : COCHE Sébastien;
> gluster-users at gluster.org<mailto:gluster-users at gluster.org>
> Objet : Re: [Gluster-users] Concurrent writes management.
>
>
> On 06/30/2014 07:49 PM, COCHE Sébastien wrote:
> Hello
>
> I have a question regarding concurrent write.
> How are manage those writes ? Is there a risk of data corruption ?
> Is there a lock mechanism, against corruption ? If yes, how it work ?
> I already had a look to forum and documents but I did not found a deep dive explanation.
> For plain distribute volumes there exists only one file in the volume with the data. All the operations on the file happen just like they happen on normal filesystem. For replicated/distributed replicated volumes there are internal locks taken by replication feature to avoid any in-consistencies.
> Please check https://github.com/gluster/glusterfs/blob/master/doc/features/afr-v1.md to know more about it.
>
> Pranith
>
>
>
> Thank for your feedback
> Sorry for my poor english ;-)
>
> Sebastien
>
>
>
>
>
> _______________________________________________
>
> Gluster-users mailing list
>
> Gluster-users at gluster.org<mailto:Gluster-users at gluster.org>
>
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
More information about the Gluster-users
mailing list