|
From: | Gordan Bobic |
Subject: | Re: [Gluster-devel] Client side AFR race conditions? |
Date: | Tue, 06 May 2008 22:05:14 +0100 |
User-agent: | Thunderbird 1.5.0.12 (X11/20080430) |
Martin Fick wrote:
--- address@hidden wrote:Hmm... So you are saying the problem is writingwithout locking?No, others are saying that. :) I am saying that writing without locking should be supported (after allhow do I lock from a script, certainly writing to glusterfs from a script should be supported?) andit can cause split brain if using AFR.
Actually, GFS does this by effectively locking a file. Locks aren't just flock/fcntl POSIX locks. They are lower level than that. Without this, you have no hope of achieving truly local FS kind of consistency. And yes - it takes a performance hit for this. But I've yet to hear of a theoretical proposition that completely does away with this.
Should writing to a file not involve an implicit lock, regardles of flock?While that might solve it, it certainly would be a performance hit. At this point I would welcome even the slow locking solution. Since it seems pretty easy to cause this problem, I would not trust AFR to say a mail spool without some way of preventing this.
Indeed - I think the only solution is implicit write-locking. open() for write has to lock the file across the cluster.
And then we start needing directory metadata journalling, or else you have the same problem with the race condition and disconnected operation. Without a metadata journal to replay, there is no way to tell which version xyz of the several possible on several servers is the most up to date / correct one (if any).
Gordan
[Prev in Thread] | Current Thread | [Next in Thread] |