Yep, I think you're right. I looked at this very briefly and didn't
see anything obviously broken; could you create a bug in our tracker
(tracker.newdream.net) with your findings?
Unfortunately we're not focusing much on the filesystem right now, but
with the record we won't lose track of the bug, and somebody might
pick it up on an ambitious weekend. :)
-Greg
On Thu, Jun 28, 2012 at 9:16 AM, Daniel Godás <dgodas@xxxxxxxxx> wrote:
> fcntl locks work as expected, the following code proves it:
>
> --- snip ---
>
> struct flock s;
>
> s.l_type = (exclusive ? F_WRLCK : F_RDLCK);
> s.l_whence = SEEK_SET;
> s.l_start = 0;
> s.l_len = 0;
> s.l_pid = getpid();
>
> if (block) {
> if (fcntl(fd, F_SETLKW, &s) != -1)
> return fd;
> } else {
> if (fcntl(fd, F_SETLK, &s) != -1)
> return fd;
> }
>
> --- snip ---
>
> However, imho the behaviour with flock locks is bogus and should be looked into.
>
>
> 2012/6/28 Daniel Godás <dgodas@xxxxxxxxx>:
>>> What versions are you using?
>>
>> Ceph 0.41, kernel 3.2.2 (kernel client)
>>
>>> Anyway, I imagine this is a Ceph bug, but have you run this on a non-Ceph mount on the same system and checked that the behavior is as you expect?
>>
>> Yes, I ran it on an ext4 mount and works as expected
>>
>>
>> 2012/6/28 Gregory Farnum <greg@xxxxxxxxxxx>:
>>> What versions are you using? This sound familiar, although I think we previously fixed it for fcntl locks, which are different than flock locks in some annoying ways.
>>> Anyway, I imagine this is a Ceph bug, but have you run this on a non-Ceph mount on the same system and checked that the behavior is as you expect?
>>>
>>>
>>> On Thursday, June 28, 2012 at 4:49 AM, Daniel Godás wrote:
>>>
>>>> Hi,
>>>>
>>>> I obtained a POSIX file lock with the following code:
>>>>
>>>> --- snip ---
>>>>
>>>> ...
>>>> std::string x = "/tmp/ceph_mount/lock_file";
>>>> std::ofstream lock_file(x);
>>>> lock_file.close();
>>>>
>>>> // Lock automatically released by the OS when the process dies
>>>>
>>>> if (Sync::get_file_lock(x) == -1) {
>>>> return false;
>>>> }
>>>>
>>>> ...
>>>>
>>>> --- snip ---
>>>>
>>>> The code should create the file if it doesnt exist or just open it and
>>>> close it if it does. Then the lock is taken. This is the code for
>>>> get_file_lock:
>>>>
>>>> ---snip---
>>>>
>>>> static int get_file_lock(const std::string& path,
>>>> bool block = false,
>>>> bool exclusive = true)
>>>> {
>>>> int fd, flags;
>>>>
>>>> if ((fd = open(path.c_str(), O_RDONLY)) == -1)
>>>> throw LockingException(path);
>>>>
>>>> flags = (exclusive ? LOCK_EX : LOCK_SH);
>>>> flags |= (block ? 0 : LOCK_NB);
>>>>
>>>> if (flock(fd, flags) == 0)
>>>> return fd;
>>>>
>>>> close(fd);
>>>> return -1;
>>>> }
>>>>
>>>> ---snip---
>>>>
>>>> I never release the lock but I expect the operating system (and ceph)
>>>> to release it when the process terminates as this is normal POSIX
>>>> behaviour. The observed behaviour is that the lock never gets released
>>>> and after the process dies I can do the following:
>>>>
>>>> ---snip---
>>>>
>>>> dev proc # cat locks
>>>> 1: POSIX ADVISORY WRITE 4425 07:00:132 0 EOF
>>>> 2: FLOCK ADVISORY WRITE 2906 fd:02:783456 0 EOF
>>>>
>>>> ---snip---
>>>>
>>>> The lock taken by the process is the second one and the PID is correct
>>>> (it's the PID of the process that took the lock). However the process
>>>> doesn't exist any more, which I can verify with ps.
>>>>
>>>> Is this a bug in CEPH, am I doing something stupid, is it the expected
>>>> behaviour?
>>>>
>>>> Regards,
>>>> Dan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx (mailto:majordomo@xxxxxxxxxxxxxxx)
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
