Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking does not work on file systems using bindfs #36

Closed
earlruby opened this issue Jul 27, 2016 · 5 comments
Closed

Locking does not work on file systems using bindfs #36

earlruby opened this issue Jul 27, 2016 · 5 comments

Comments

@earlruby
Copy link

On an Ubuntu 16.04 system, flock fails to lock a file on a file system bound with bindfs.

Set up:

root@ubuntu:~# bindfs -V
bindfs 1.12.6
root@ubuntu:~# uname -a
Linux ubuntu 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# mkdir -p /test/realfs /test/bindfs1 /test/bindfs2
root@ubuntu:~# bindfs /test/realfs /test/bindfs1
root@ubuntu:~# bindfs /test/realfs /test/bindfs2
root@ubuntu:~# df -k
Filesystem                  1K-blocks    Used Available Use% Mounted on
udev                           480048       0    480048   0% /dev
tmpfs                           99844    4744     95100   5% /run
/dev/mapper/ubuntu--vg-root   6597808 1327856   4911760  22% /
tmpfs                          499204       0    499204   0% /dev/shm
tmpfs                            5120       0      5120   0% /run/lock
tmpfs                          499204       0    499204   0% /sys/fs/cgroup
/dev/sda1                      482922   56252    401736  13% /boot
tmpfs                             100       0       100   0% /run/lxcfs/controllers
tmpfs                           99844       0     99844   0% /run/user/0
bindfs                        6597808 1327856   4911760  22% /test/bindfs1
bindfs                        6597808 1327856   4911760  22% /test/bindfs2

Test flock on two different directories, same underlying fs, second lock should fail but does not:

root@ubuntu:~# flock -n -x -o /test/bindfs1/lockfile sleep 30 &
[1] 5102
root@ubuntu:~# flock -n -x -o /test/bindfs2/lockfile sleep 10
root@ubuntu:~# echo $?
0

Test flock on two different directories, the bindfs fs and the underlying fs, second lock should fail but does not:

root@ubuntu:~# flock -n -x -o /test/bindfs1/lockfile sleep 30 &
root@ubuntu:~# flock -n -x -o /test/realfs/lockfile sleep 10
root@ubuntu:~# echo $?
0

The expected behavior is for a file locked on a bindfs filesystem to attempt to lock the same file on the underlying file system.

@earlruby
Copy link
Author

I also tried using fcntl locks, which also failed to work. I used the following Python script within a bindfs directory to test:

#!/usr/bin/python
import fcntl, os, time
fd = open('./lockfile', 'w')
fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB)
time.sleep(30)
fcntl.lockf(fd, fcntl.LOCK_UN)
fd.close()

When executed twice in the same directory, the second lock attempt fails to lock an already-locked file, as expected:

root@ubuntu:/test/bindfs1# ./fcntl-locktest &
[1] 5159
root@ubuntu:/test/bindfs1# ./fcntl-locktest
Traceback (most recent call last):
  File "./fcntl-locktest", line 5, in <module>
    fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB)
IOError: [Errno 11] Resource temporarily unavailable

However, when run in two different bindfs directories, both bound to the same underlying filesystem, it "succeeds" in locking the same file twice, indicating that fcntl locks are not working:

root@ubuntu:/test/bindfs1# ./fcntl-locktest &
[1] 5161
root@ubuntu:/test/bindfs1# cd ../bindfs2
root@ubuntu:/test/bindfs2# ./fcntl-locktest

Also "succeeds" in locking the same file twice when locking the file on the underlying file system, indicating that fcntl locks are not working:

root@ubuntu:/test/bindfs1# ./fcntl-locktest &
[1] 5165
root@ubuntu:/test/bindfs1# cd ../realfs/
root@ubuntu:/test/realfs# ./fcntl-locktest

The expected behavior is that the second lock attempt should fail.

mpartel added a commit that referenced this issue Jul 31, 2016
@mpartel
Copy link
Owner

mpartel commented Jul 31, 2016

This should now be implemented in the master branch for both types of locks, but it requires --multithreaded to avoid deadlocks. Please test and let me know if it works. I'll probably make a release after a week if no problems are reported.

The problems with --multithreaded are probably fixable with a simple in-process lock, but sadly I don't have the time to do that right now. The code itself should be thread-safe i.e. I don't expect it to crash (what little global mutable state there is is behind a lock).

@earlruby
Copy link
Author

earlruby commented Aug 4, 2016

I rebuilt using the current master + the latest FUSE and I see see this issue:

root@ubuntu-14:/test/bindfs1# which bindfs
/usr/local/bin/bindfs
root@ubuntu-14:/test/bindfs1# bindfs -V
bindfs 1.13.1
root@ubuntu-14:~# mkdir -p /test/realfs /test/bindfs1 /test/bindfs2
root@ubuntu-14:~# bindfs /test/realfs /test/bindfs1
root@ubuntu-14:~# bindfs /test/realfs /test/bindfs2
root@ubuntu-14:~# flock -n -x -o /test/bindfs1/lockfile sleep 30 &
[1] 1734
root@ubuntu-14:~# flock -n -x -o /test/bindfs2/lockfile sleep 10
root@ubuntu-14:~# echo $?
0

(Second lock succeeds, should fail.)

@mpartel
Copy link
Owner

mpartel commented Aug 4, 2016

Sorry, I forgot to mention you need to pass the new flag --enable-lock-forwarding to make it work (new man page entry).

Enabling lock forwarding by default is blocked on some problems with multithreaded mode.

@earlruby
Copy link
Author

earlruby commented Aug 4, 2016

Just tried:

root@ubuntu-14:~# bindfs --enable-lock-forwarding --enable-ioctl --multithreaded /test/realfs /test/bindfs1
root@ubuntu-14:~# bindfs --enable-lock-forwarding --enable-ioctl --multithreaded /test/realfs /test/bindfs2
root@ubuntu-14:~# flock -n -x -o /test/bindfs1/lockfile sleep 30 &
[1] 1798
root@ubuntu-14:~# flock -n -x -o /test/bindfs2/lockfile sleep 10
root@ubuntu-14:~# echo $?
1

Success! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants