Hi Simon,

This issue is a variant of Bug 801 
(http://bugs.gluster.com/show_bug.cgi?id=801).<http://bugs.gluster.com/show_bug.cgi?id=801%29.>
 Mercurial is accessing file /uwsgi/.hg/store/00changelog.i.a using two fds. 
Based on default policy of glusterfs whether to use direct-io-mode or 
buffered-mode, one of the fd is accessing the file in direct-io-mode and other 
in buffered mode. As mentioned in comment #27 of the bug, this has some issues. 
As a work around, you can use --direct-io-mode option of glusterfs to override 
the default behaviour (It does not make difference for this problem whether you 
set it on or off). Please let us know, whether this fixes your issue.

regards,
Raghavendra.
________________________________
From: gluster-users-boun...@gluster.org [gluster-users-boun...@gluster.org] on 
behalf of Anand Avati [anand.av...@gmail.com]
Sent: Thursday, June 09, 2011 8:05 PM
To: Simon Litchfield
Cc: gluster-users@gluster.org
Subject: Re: [Gluster-users] Write-behind breaks Mercurial

This is interesting. write-behind guarantees ordering of read/write such that 
you always read written data. Do you happen to know if Mercurial reads and 
writes from different file descriptors on the same file? Can you give us logs 
and configuration details of your setup?

Avati

On Mon, Jun 6, 2011 at 10:41 PM, Simon Litchfield 
<si...@s29.com.au<mailto:si...@s29.com.au>> wrote:
Hi all

It seems Mercurial doesn't work with "write behind" on. Any ideas?

With write-behind --

root@dj1:~/mnt# gluster volume set conf performance.write-behind on
Set volume successful
root@dj1:~/mnt# hg clone http://projects.unbit.it/hg/uwsgi
destination directory: uwsgi
requesting all changes
adding changesets
transaction abort!
rollback completed
abort: integrity check failed on 00changelog.i:24!

Without write-behind --

root@dj1:~/mnt# gluster volume set conf performance.write-behind off
Set volume successful
root@dj1:~/mnt# hg clone http://projects.unbit.it/hg/uwsgi
destination directory: uwsgi
requesting all changes
adding changesets
adding manifests
adding file changes
added 1169 changesets with 3532 changes to 332 files
updating to branch default
278 files updated, 0 files merged, 0 files removed, 0 files unresolved

Shouldn't the write behind cache be reading unwritten data before it hits the 
disk?

Cheers
Simon

_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org<mailto:Gluster-users@gluster.org>
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Reply via email to