Re: [fuse] writeback cache triggers read() for O_WRONLY files - bug?

[Nikolaus Rath <Nikolaus@rath.org>]

Hi again,

Small clarification: the O_APPEND flag muddles the water a bit (I'll
write a second mail about that). The behavior that I'm describing here
also happens if userspace opens without O_APPEND but seeks to the end of
the file before writing.

Best,
-Nikolaus

On Aug 04 2017, Nikolaus Rath <Nikolaus@rath.org> wrote:
> Hello,
>
> When enabling writeback cache for SSHFS, appending to files overwrites
> data at a different position (cf. https://github.com/libfuse/sshfs/issues/72).
>
> When trying to track this issue down, I noticed that the libfuse
> passthrough_ll example also has problems with appending: calling
> fuse_reply_data gives a "Bad File Descriptior" error.
>
> This in turn I traced this down to the fact that when writeback caching
> is enabled, and userspace calls open(name, O_WRONLY|O_APPEND) the kernel
> passes the O_WRONLY flag on to libfuse. But when userspace then writes
> data, the kernel issues a read() request to libfuse (presumably to fill
> the write cache) - for a file that has been opened write-only.
>
> In the passthrough_ll example, this then fails because the underlying
> file has also been opened O_WRONLY and the strace read then fails.
>
> I am not sure what to make of this. Is this behavior of the kernel
> correct? Should libfuse be prepared to accept READ requests for files
> that have been opened write-only? Or should the kernel never open files
> write-only when writeback caching is enabled?
>
> (I am not sure if something like this is also the cause of the
> dataloss problem in SSHFS, but it seems worth addressing in any case)
>
> Thanks,
> -Nikolaus
>
> -- 
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>              »Time flies like an arrow, fruit flies like a Banana.«


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

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