FUSE: write() after release()

FUSE: write() after release()

[Oleg Chernovskiy]

[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]

Hi,


I'm writing primarily because of the bug users are reporting

in my network-based filesystem [1]. In short, rsync first creates temporary file,

flushes and closes it and then immediately opens it again. The problem is,

sometimes I see that afterwards it tries to write to a closed fd resulting in IO error.


Is there a possibility that FUSE can execute fresh OPEN call before pending RELEASE

for the same inode that was processed?


I see OPEN calls are always sync in fuse_open_common but RELEASE seems to be

async as I see it goes to background queue in

fuse_release_common->fuse_file_put->fuse_request_send_background, can this be the reason?


Is there something that I'm missing? Maybe it's me implementing fs in wrong way?

How is this kind of behavior is corrected?


[1]: https://github.com/libfuse/libfuse/issues/295



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: FUSE: write() after release()

[Miklos Szeredi]

On Sun, Sep 16, 2018 at 12:35 AM, Oleg Chernovskiy <kanedias@xaker.ru> wrote:
> Hi,
>
>
> I'm writing primarily because of the bug users are reporting
>
> in my network-based filesystem [1]. In short, rsync first creates temporary file,
>
> flushes and closes it and then immediately opens it again. The problem is,
>
> sometimes I see that afterwards it tries to write to a closed fd resulting in IO error.
>
>
> Is there a possibility that FUSE can execute fresh OPEN call before pending RELEASE
>
> for the same inode that was processed?

Yes.

>
>
> I see OPEN calls are always sync in fuse_open_common but RELEASE seems to be
>
> async as I see it goes to background queue in
>
> fuse_release_common->fuse_file_put->fuse_request_send_background, can this be the reason?

Right.

>
>
> Is there something that I'm missing? Maybe it's me implementing fs in wrong way?
>
> How is this kind of behavior is corrected?

I don't quite get what the problem is.   The filesystem needs to
handle multiple parallel open instances of the same inode anyway.
What's special about this case of two slightly overlapping open
instances as opposed to two fully overlapping open instances?

Thanks,
Miklos

Re: FUSE: write() after release()

[Miklos Szeredi]

On Mon, Sep 17, 2018 at 9:24 AM, Oleg Chernovskiy <kanedias@xaker.ru> wrote:
> The problem is, I initially tried implementing fs thinking that release call
> is executed if there are no open instances of file.
>
> Isn't that the case for non-fuse filesystems?

There's some amount of confusion here because of the way file handles
can be duplicated on UNIX (e.g. by dup() or fork(), etc).   So
remember the difference between file descriptor (which references an
open file) and the open file itself.

1) If you call open(2) twice on the same path, you'll get two open
files, and hence you'll get two releases when the files are closed.

2) If you call open(2) once, then dup(), and then close the first fd,
you'll *not* get a release (only a flush, which is called on every
close(2)).  When you close the second file descriptor, only then
you'll get the release.

I think this is documented pretty well in the fuse header files.

Thanks,
Miklos