[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] GFS bug with fcntl/flock ?



Hi Robert,

I am running InterSystems Caché 5.0.19 for AMD64, and an strace output from their utility reveals a problem with fcntl/flock on the GFS filesystem (mount -t gfs /dev/VGSHARE/lvol0 /usr/local):

    open("/usr/local/etc/cachesys/cache.reg", O_RDONLY|O_NONBLOCK) = 3
    fcntl(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
    len=0}) = -1 ENOLCK (No locks available)

The only place GFS returns ENOLCK is when mandatory locking is turned on. It looks like you have the flags for mandatory locking set on this particular file. i.e. S_ISGID is set and S_IXGRP is not set. If you do an 'ls -al' on this file, you should see something like
   [adas radium locking]$ ls -al templock
   -rwxr-Sr-x  1 adas adas 6 Oct 13 13:50 templock
The 'S' in the permissions for the group indicate mandatory locking. GFS does not support mandatory locking and will refuse to
apply fcntl() or flock() on such files.
You can try doing the same fcntl() with start=0 and len=0 on some other regular file on gfs and see if that works for you.

When I put their files on an ordinary ext3 filesystem, all works fine:

    open("/usr/local/etc/cachesys/cache.reg", O_RDONLY|O_NONBLOCK) = 3
    fcntl(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
    len=0}) = 0

When you copied the files over, they might have lost these flags, or your ext3 fs supports mandatory locking ('-o mand' mount option)

The man page on fcntl states that when flock is setup with whence=SEEK_SET, start=0, and len=0, the lock will occur on the entire file... so locking zero bytes in this manner is acceptable. Help?

This works correctly in my test environment.

Hope this helps.

Regards,
--Abhi


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]