On 07/01/2014 03:38 PM, COCHE Sébastien wrote:
OK, but how can I know if an application use fcntl lock ?
Use strace and check if uses fcntl locks.
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 ?
If they are already in split-brain damage is already done. This is
distributed file-system problem not application's.
Pranith
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@xxxxxxxxxx]
Envoyé : mardi 1 juillet 2014 11:43
À : COCHE Sébastien
Cc : Pranith Kumar Karampuri; gluster-users@xxxxxxxxxxx
Objet : Re: 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@xxxxxxxxxx] Envoyé :
lundi 30 juin 2014 18:08 À : COCHE Sébastien Cc :
gluster-users@xxxxxxxxxxx Objet : Re: 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@xxxxxxxxxx] Envoyé :
lundi 30 juin 2014 17:49 À : COCHE Sébastien;
gluster-users@xxxxxxxxxxx<mailto:gluster-users@xxxxxxxxxxx>
Objet : Re: 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@xxxxxxxxxxx<mailto:Gluster-users@xxxxxxxxxxx>
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
