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.«
