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

[Nikolaus Rath <Nikolaus@rath.org>]

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@virtuozzo.com> 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@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.«