Hello Miklos,
16.06.2016 13:49, Miklos Szeredi пишет:
On Fri, Jun 3, 2016 at 8:49 PM, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
Hi Miklos,
fuse_file_lock() since its inception in 2006 implements F_SETLK command like
this:
if (fc->no_lock)
err = posix_lock_file(file, fl, NULL);
else
err = fuse_setlk(file, fl, 0);
where fc->no_lock is a per-mount-point tunable. It would be more natural to
posix-lock in both cases, like this:
err = posix_lock_file(file, fl, NULL);
if (!err && !fc->no_lock)
err = fuse_setlk(file, fl, 0);
Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never
called, and from end-user perspective it is weird that the file was locked
successfully, but "fdinfo" does not show the lock.
Do you think there were some reasons to implement it that way -- not calling
posix_lock_file unconditionally?
Calling posix_lock_file() *before* we know the file can actually be
locked may be setting us up for weird bugs.
Could you elaborate a bit on these bugs?
(BTW, it's done like this in NFS)
It could be called
afterwards, when we already know the real locking operation succeeded.
But we need to think very carefully about races between two locking
operations, because locking state update is non-atomic after that
change.
So I think this possibly can be done, but needs some thought.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
