[Gluster-devel] Problems with flock functionality with fuse-2.7.0-gls3 and tls 450
kbenson at a-1networks.com
Fri Aug 10 20:38:19 UTC 2007
On Friday 10 August 2007 13:11, Harris Landgarten wrote:
> There is a typo in my email it should read
> $ ruby ./testlock.rb /mnt/glusterfs/test/testfile 60
> When another instance was started:
> $ ruby ./testlock.rb /mnt/glusterfs/test/testfile
> opening /mnt/glusterfs/test/testfile and locking
> ./testlock.rb:6:in `initialize': No such file or directory -
> /mnt/glusterfs/test/testfile (Errno::ENOENT) from ./testlock.rb:6:in `open'
> from ./testlock.rb:6:in `open_locked'
> from ./testlock.rb:24
> The script attempts to open a file in "w" mode and get a LOCK_EX on it
> before writing. Therefore it either creates or recreates the file. The
> second instance should block until the LOCK_UN is requested by the first
> instance. It instead reports ENOENT. Rerunning the second instance once the
> first instance releases the lock succeeds with another LOCK_EX being
> granted. BTW, you must be running fuse-2.7.0-gls3 and recompile glusterfs
> with the libfuse.so from that for this the work because flock support was
> just added by the Gluster team. Stock fuse does not support flock yet.
This looks very similar to what I posted about yesterday. Can you confirm
whether this happens on files that already exist, or just files the the first
run of the locking script creates? Not that I'll be the one fixing it, but
the devs might like to have confirmation as to whether it's related, and not
two separate issues.
- Kevan Benson
- A-1 Networks
More information about the Gluster-devel