Hi Maxim, Any reason the kernel doesn't fix up the flags before sending the open request? I assume the kernel will enforce that userspace can't read from a file opened with O_WRONLY if writeback cache is enabled? Is the same also true without writeback cache, i.e. can the filesystem safely ignore O_WRONLY/O_RDONLY at all times? Thanks! -Nikolaus On Aug 04 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote: > Hi Nikolaus, > > > If writeback caching is enabled, libfuse must be prepared to get READ > requests from kernel. Hence, even if an user wants WRONLY, libfuse > should open RDWR. > > > Thanks, > > Maxim > > > On 08/04/2017 12:00 PM, Nikolaus Rath wrote: >> 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@xxxxxxxx> 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.«
