On Thursday 09 August 2007 19:13, Harris Landgarten wrote:
> I ran the following ruby program named testlock.rb:
>
> #!/usr/bin/ruby
>
> class File
> def File.open_locked(*args)
> File.open(*args) do |f|
> begin
> f.flock(File::LOCK_EX)
> result = yield f
> ensure
> f.flock(File::LOCK_UN)
> return result
> end
> end
> end
> end
>
> file = ARGV.shift || "./testlockfile"
> delay = ARGV.shift || 10
> hostname = `hostname`
> hostname.chomp!
> puts "opening #{file} and locking"
> File.open_locked(file, "w"){ |f| f.puts "test"; puts "#{Time.now} : locking
> file"; sleep delay.to_i; f.puts "finished" } puts "#{file} #{hostname} end
> #{Time.now}"
> puts "#{file} #{hostname} unlocked"
Either this looks very familiar or we think alike. ;)
> When run on the local file system as:
>
> $ ruby ./testlock.rb testfile 60
>
> I ran another instance on the same client and it blocked until the first
> instance released the LOCK_EX and then completed.
>
> The same test was run on gluster as:
>
> $ ruby ./testlock.rb /mnt/glusterfs/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
>
> Glusterfs is reporting the LOCK_EX file as ENOENT when another LOCK_EX is
> requested instead of blocking.
Are you attempting this on an already existing file, or a new file? If you
look at the previous thread, you'll see I've reported a problem with locking
from different clients on a new file. When I attempt this on an already
created file, it works for me though, and that was TLA patch 449.
--
- Kevan Benson
- A-1 Networks
