fuse does not show lock info in /proc/.../fdinfo/...

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

fuse does not show lock info in /proc/.../fdinfo/...

Maxim Patlasov-3
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?

Thanks,
Maxim

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: fuse does not show lock info in /proc/.../fdinfo/...

Miklos Szeredi
On Fri, Jun 3, 2016 at 8:49 PM, Maxim Patlasov <[hidden email]> 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.  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

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: fuse does not show lock info in /proc/.../fdinfo/...

Miklos Szeredi
On Thu, Jun 16, 2016 at 3:22 PM, Stanislav Kinsburskiy
<[hidden email]> wrote:

> Hello Miklos,
>
> 16.06.2016 13:49, Miklos Szeredi пишет:
>>
>> On Fri, Jun 3, 2016 at 8:49 PM, Maxim Patlasov <[hidden email]>
>> 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)

Suppose range 0-9 is locked remotely two processes are concurrently
trying to lock the following ranges (nonblocking):

A: 5-15
B: 10-19

The situation is clear enough: "A" should fail, "B" should succeed.

However, with the above logic "B" might fail as well if it's done
after "A" acquired the lock locally, but before failure from the
remote lock operation was received

Thanks,
Miklos

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel