lookup counts and locking in llfuse

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

lookup counts and locking in llfuse

Peter Amstutz
Hello,

My coworker and I are scratching our heads over this document:

https://github.com/python-llfuse/python-llfuse/blob/master/developer-notes/lookup_counts.rst

Our FUSE driver currently does something very similar to the "class WontWork" example and we are getting an error that does look like we are doing it the wrong way, but we don't understand the explanation for why
it is wrong.  The document says that in the forget() method, there is a race condition "forget() may have been interrupted by lookup() between `if` and `del`".  However, I don't understand why calls to lookup(), forget() and open() are not all serialized by the global llfuse lock? My understanding was that llfuse operations only execute in parallel when an operation explicitly releases the lock?  Is the behavior of the
llfuse global lock different from a normal mutex?

Thanks,
Peter

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
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: lookup counts and locking in llfuse

Nikolaus Rath
On Apr 27 2016, Peter Amstutz <[hidden email]> wrote:

> Hello,
>
> My coworker and I are scratching our heads over this document:
>
> https://github.com/python-llfuse/python-llfuse/blob/master/developer-notes/lookup_counts.rst
>
> Our FUSE driver currently does something very similar to the "class
> WontWork" example and we are getting an error that does look like we
> are doing it the wrong way, but we don't understand the explanation
> for why it is wrong.  The document says that in the forget() method,
> there is a race condition "forget() may have been interrupted by
> lookup() between `if` and `del`".  However, I don't understand why
> calls to lookup(), forget() and open() are not all serialized by the
> global llfuse lock?  My understanding was that llfuse operations only
> execute in parallel when an operation explicitly releases the lock?

That is correct. But python-llfuse has no way of knowing if e.g. the
forget() handler will release the lock or not, so it can not rely on
this serialization.

I think you are assuming that WontWork example is meant to implement on
Operations class that can be used with python-llfuse. That is not
correct. But the target audience of the document you are reading are not
python-llfuse users, but developers of python-llfuse. The class you are
looking at is a simplified, potential implementation of python-llfuse
itself.

> Is the behavior of the llfuse global lock different from a normal
> mutex?

No. But the global lock will also become optional soon, which is another
reason why python-llfuse can't manage lookup counts for the user.

Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel