[Gluster-devel] Client side afr, locking, race condition, simultanous writes, out of sync

[Anand Babu Periasamy]

Now I got it. With or without application locks, FS should guarantee
atomicity for writes in O_APPEND mode. This one reason justifies
a **RACE CONDITION** in AFR.

Thanks to Gordan Bobic and Martin Fick for identifying this issue and
more importantly for working hard to make me understand :). We will
put top priority and fix this ASAP.

Also thinking about the performance hit, loading write-behind on top
of AFR will nullify the lock delays. Even otherwise, performance is
secondary to reliability and correctness of the system.

Krishna, please hold locks while writing to multiple sub-volumes in AFR
to ensure atomicity. Keep it as default behavior with or without
O_APPEND mode.

--
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
The GNU Operating System [http://www.gnu.org]
Z RESEARCH Inc [http://www.zresearch.com]



Gordan Bobic wrote:
> Martin Fick wrote:
>> --- gordan at bobich.net wrote:
>>> On Fri, 9 May 2008, Anand Babu Periasamy wrote:
>>>> You are always expected to hold locks and issue
>>>> writes in a multi user mode.
>>
>> In the real world people will use scripts without locks and will risk 
>> corruption.  This corruption should only affect the application.  Here 
>> we are
>> talking about backup utilities and other applications that will 
>> potentially be affected. Imagine a file that is inconsistent and 
>> untouched for years after that, it could return alternating
>> results every night on a backup making backups
>> excessive.  It could trigger an rsynced volume to
>> constantly resync.  These are not issues that a
>> filesytem should introduce.
>>
>>
>>> ... but what happens when both sides are appending to the file? Logs 
>>> being an obvious example - they are not always locked.
>>
>> For the record, I tested this yesterday and if you modify the stress 
>> script to append to each file; you will see similar inconsistent split 
>> brain activity.
> 
> I couldn't agree more. These are all rather dangerous problems.
> 
> Could the developers please provide any insight into when these basic 
> consistency issues are likely to be addressed and if the rest of us can 
> help somehow?
> 
> Gordan
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel