Skip to content

Commit

Permalink
ceph: support file lock on directory
Browse files Browse the repository at this point in the history 
Link: http://tracker.ceph.com/issues/24028
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
  • Loading branch information
@ukernel
ukernel committed May 15, 2018
1 parent 816f885 commit ae2a853
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions fs/ceph/dir.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1486,6 +1486,8 @@ const struct file_operations ceph_dir_fops = {
.release = ceph_release,
.unlocked_ioctl = ceph_ioctl,
.fsync = ceph_fsync,
.lock = ceph_lock,

This comment has been minimized.

Sign in to view

Copy link
@socketpair

socketpair May 15, 2018 •
edited
Loading

I'm unsure about .lock. Is it posix locks ? I think they are not applicable to directories.

This comment has been minimized.

Sign in to view

Copy link
@jtlayton

jtlayton May 15, 2018

Contributor

Yes, .lock is for POSIX locks. Linux generally does allow you to set locks on directories. Some underlying filesystems don't allow it, of course, but the VFS layer and most filesystems don't really care what sort of inode you're setting a lock on.

This comment has been minimized.

Sign in to view

Copy link
@socketpair

socketpair May 15, 2018

image

byte-range is not defined for directories. So, these locks are not defined for them. Does not it ?

This comment has been minimized.

Sign in to view

Copy link
@socketpair

socketpair May 15, 2018

  1. F_SETLKW generates EBADF (for F_WRLCK) on dirs on my system.
  2. F_SETLKW works (for F_RDLCK), but following F_GETLKW returns F_UNLCK.

Seems, this is a workaround for something. Anyway, noone use that. I would prefer not to fill .lock.

This comment has been minimized.

Sign in to view

Copy link
@jtlayton

jtlayton May 15, 2018

Contributor

POSIX locks are advisory, so they don't really have a strict relationship to the byte range of the actual inode. Under Linux, you can lock a byte range of a directory (again not all filesystems allow this, but the "simple" in-kernel implementation does). As long as two cooperating applications know how to interpret such a lock on a directory, it's fine to do so.

This comment has been minimized.

Sign in to view

Copy link
@jtlayton

jtlayton May 15, 2018

Contributor

I don't feel strongly either way, but POSIX (and the Linux file locking code) does not really make a distinction about the inode type. You can generally set locks on any type of inode (providing you can get a fd that allows it).

FWIW, F_GETLK should probably have been named F_TESTLK. Basically what it does is ask "would I be allowed to set the supplied lock"? Assuming that the l_type passed in was F_RDLCK, F_UNLCK Is correct there since there would be no conflict.

This comment has been minimized.

Sign in to view

Copy link
@socketpair

socketpair May 15, 2018

OK. Seems, you are right. Thanks, good job.
.flock = ceph_flock,
};

const struct file_operations ceph_snapdir_fops = {
Expand Down

0 comments on commit ae2a853

Please sign in to comment.