Quantcast

close() / release() ordering question

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

close() / release() ordering question

David Sorber
I'm using FUSE 2.9.4 and I'm seeing intermittent weirdness with the ordering of client-side close() calls and FUSE release() calls for my file system.  I suspect that I'm doing something wrong but I'd like to confirm that my assumption is correct.

That is, am I correct in assuming that when a user closes a FUSE file, the FUSE release() function (implemented in my file system) runs to completion before the close() function returns to the caller?

-David

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
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
|  
Report Content as Inappropriate

Re: close() / release() ordering question

Miklos Szeredi
On Tue, Jan 10, 2017 at 4:18 PM, David Sorber <[hidden email]> wrote:
> I'm using FUSE 2.9.4 and I'm seeing intermittent weirdness with the ordering
> of client-side close() calls and FUSE release() calls for my file system.  I
> suspect that I'm doing something wrong but I'd like to confirm that my
> assumption is correct.
>
> That is, am I correct in assuming that when a user closes a FUSE file, the
> FUSE release() function (implemented in my file system) runs to completion
> before the close() function returns to the caller?

No, your assumption is false, because ->release() is asynchronous.  If
you want something synchronous with close() you need to implement the
->fush() call.

Thanks,
Miklos

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
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
|  
Report Content as Inappropriate

Re: close() / release() ordering question

David Sorber
I see... So, to confirm, the FUSE flush () call get called automatically, in a synchronous fashion as you said, when a FUSE file is closed?

Thanks for the clarification.
-David

On Tue, Jan 10, 2017 at 10:44 AM, Miklos Szeredi <[hidden email]> wrote:
On Tue, Jan 10, 2017 at 4:18 PM, David Sorber <[hidden email]> wrote:
> I'm using FUSE 2.9.4 and I'm seeing intermittent weirdness with the ordering
> of client-side close() calls and FUSE release() calls for my file system.  I
> suspect that I'm doing something wrong but I'd like to confirm that my
> assumption is correct.
>
> That is, am I correct in assuming that when a user closes a FUSE file, the
> FUSE release() function (implemented in my file system) runs to completion
> before the close() function returns to the caller?

No, your assumption is false, because ->release() is asynchronous.  If
you want something synchronous with close() you need to implement the
->fush() call.

Thanks,
Miklos


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
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
|  
Report Content as Inappropriate

Re: close() / release() ordering question

Miklos Szeredi
On Tue, Jan 10, 2017 at 4:50 PM, David Sorber <[hidden email]> wrote:
> I see... So, to confirm, the FUSE flush () call get called automatically, in
> a synchronous fashion as you said, when a FUSE file is closed?

When close(2) syscall is called or when file descriptor is closed
implicitly (process exit), then ->flush() will get called.

However an open file may have other references that get put without an
actual ->flush operation: like when the file descriptor is sent over a
unix domain socket with the SCM_RIGHTS message and the socket is
closed.

So the rules are:

 ->flush is always implied by close(2).  This can happen multiple
times in the lifetime of an open file (try close(dup(fd) or fork()).
Can return an error.

 ->release is only called once for each ->open.  It's not a
synchronous operation, and cannot return an error.

Thanks,
Miklos

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
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
|  
Report Content as Inappropriate

Re: close() / release() ordering question

David Sorber
Got it, many thanks!  

I inherited this file system and clearly my predecessor did not realize he should have been using flush() instead of release().  In looking at the documentation I think warning notes, similar to those found for the flush() call, should be added to the release() call to make sure folks realize the distinction.

Thanks again,
-David

On Tue, Jan 10, 2017 at 11:10 AM, Miklos Szeredi <[hidden email]> wrote:
On Tue, Jan 10, 2017 at 4:50 PM, David Sorber <[hidden email]> wrote:
> I see... So, to confirm, the FUSE flush () call get called automatically, in
> a synchronous fashion as you said, when a FUSE file is closed?

When close(2) syscall is called or when file descriptor is closed
implicitly (process exit), then ->flush() will get called.

However an open file may have other references that get put without an
actual ->flush operation: like when the file descriptor is sent over a
unix domain socket with the SCM_RIGHTS message and the socket is
closed.

So the rules are:

 ->flush is always implied by close(2).  This can happen multiple
times in the lifetime of an open file (try close(dup(fd) or fork()).
Can return an error.

 ->release is only called once for each ->open.  It's not a
synchronous operation, and cannot return an error.

Thanks,
Miklos


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...