Quantcast

release() and flush()

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

release() and flush()

Yue Li
hi,

I exported the FUSE via NFS, and it worked pretty well.

While looking at the traces in fuse's debugging mode (-d) from the
writing of a large file (~5GB) at an NFS client, I had two questions
regarding release() and fuse():

1. I saw release() function gets called multiple times in the middle and
of course at the end. However if I don't use NFS, and test the file
system locally, it seems release() only gets called at the end.

2. I also saw flush() function never gets called during the NFS based
test. But it gets called before release() if I test the FS locally.

Why are there such differences? According to the semantics of release(),
isn't it suppose to only called after the last piece of data gets
written instead of in the middle of the data transferring?

Best,

Yue



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
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: release() and flush()

Nikolaus Rath
On Apr 08 2017, Yue Li <yli-wUU9E3n5/[hidden email]> wrote:

> hi,
>
> I exported the FUSE via NFS, and it worked pretty well.
>
> While looking at the traces in fuse's debugging mode (-d) from the
> writing of a large file (~5GB) at an NFS client, I had two questions
> regarding release() and fuse():
>
> 1. I saw release() function gets called multiple times in the middle and
> of course at the end. However if I don't use NFS, and test the file
> system locally, it seems release() only gets called at the end.
>
> 2. I also saw flush() function never gets called during the NFS based
> test. But it gets called before release() if I test the FS locally.
>
> Why are there such differences? According to the semantics of release(),
> isn't it suppose to only called after the last piece of data gets
> written instead of in the middle of the data transferring?

NFS mounts are designed to survive a server reboot. Therefore, you can
almost never assume that specific actions of the NFS client will result
in specific requests to your filesystem. What you see are the actions of
the NFS server, which may open, close, read and write files
independently of client requests.



Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
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: release() and flush()

Michael Theall-2
Hi Yue,

This is especially true for NFSv3 clients. It is stateless, so you will get open/read/release for every client read request and open/write/flush?/release for every client write request.

Since an open(2) on my filesystem is expensive, I added an "nfs3" mount option which caches open file handles by (inode, uid, mode). This keeps the file open for several seconds in case more requests are coming in. If no request comes in for a configured timeout, I close the file. This increases performance on my filesystem for NFSv3 clients at the expense of fudging some POSIX semantics.

Regards,
Michael Theall

On Sat, Apr 8, 2017, 19:35 Nikolaus Rath <[hidden email]> wrote:
On Apr 08 2017, Yue Li <yli-wUU9E3n5/[hidden email]> wrote:
> hi,
>
> I exported the FUSE via NFS, and it worked pretty well.
>
> While looking at the traces in fuse's debugging mode (-d) from the
> writing of a large file (~5GB) at an NFS client, I had two questions
> regarding release() and fuse():
>
> 1. I saw release() function gets called multiple times in the middle and
> of course at the end. However if I don't use NFS, and test the file
> system locally, it seems release() only gets called at the end.
>
> 2. I also saw flush() function never gets called during the NFS based
> test. But it gets called before release() if I test the FS locally.
>
> Why are there such differences? According to the semantics of release(),
> isn't it suppose to only called after the last piece of data gets
> written instead of in the middle of the data transferring?

NFS mounts are designed to survive a server reboot. Therefore, you can
almost never assume that specific actions of the NFS client will result
in specific requests to your filesystem. What you see are the actions of
the NFS server, which may open, close, read and write files
independently of client requests.



Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
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: release() and flush()

Yue Li
hi Michael,

Thanks again for the nice suggestions!

It is amazing that it seems I always ran into the problems you solved
before...

Best,

Yue

On 4/9/17 10:08 PM, Michael Theall wrote:

> Hi Yue,
>
> This is especially true for NFSv3 clients. It is stateless, so you will get
> open/read/release for every client read request and
> open/write/flush?/release for every client write request.
> Since an open(2) on my filesystem is expensive, I added an "nfs3" mount
> option which caches open file handles by (inode, uid, mode). This keeps the
> file open for several seconds in case more requests are coming in. If no
> request comes in for a configured timeout, I close the file. This increases
> performance on my filesystem for NFSv3 clients at the expense of fudging
> some POSIX semantics.
>
> Regards,
> Michael Theall
>
> On Sat, Apr 8, 2017, 19:35 Nikolaus Rath <[hidden email]> wrote:
>
> On Apr 08 2017, Yue Li <yli-wUU9E3n5/
> [hidden email]> wrote:
>> hi,
>>
>> I exported the FUSE via NFS, and it worked pretty well.
>>
>> While looking at the traces in fuse's debugging mode (-d) from the
>> writing of a large file (~5GB) at an NFS client, I had two questions
>> regarding release() and fuse():
>>
>> 1. I saw release() function gets called multiple times in the middle and
>> of course at the end. However if I don't use NFS, and test the file
>> system locally, it seems release() only gets called at the end.
>>
>> 2. I also saw flush() function never gets called during the NFS based
>> test. But it gets called before release() if I test the FS locally.
>>
>> Why are there such differences? According to the semantics of release(),
>> isn't it suppose to only called after the last piece of data gets
>> written instead of in the middle of the data transferring?
> NFS mounts are designed to survive a server reboot. Therefore, you can
> almost never assume that specific actions of the NFS client will result
> in specific requests to your filesystem. What you see are the actions of
> the NFS server, which may open, close, read and write files
> independently of client requests.
>
>
>
> Best,
> -Nikolaus
>
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>               »Time flies like an arrow, fruit flies like a Banana.«
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> --
> fuse-devel mailing list
> To unsubscribe or subscribe, visit
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...