On Sep 20 2017, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
>>> Writeback cache assumes that the file is never changed outside the
>>> mounted filesystem, so it's not suitable for any network fs currently.
>>>
>>> Apparently the above is not documented anywhere :(
>>
>> Ouch.
>>
>> I will of course put this into the libfuse documentation, but it would
>> be much nicer if things like that could be documented somewhere in the
>> kernel. After all, these are not properties of libfuse but the kernel
>> module - and some filesystems use the fuse interface without using
>> libfuse.
>>
>> (This actually applies to large chunk of information that's currently
>> only in the libfuse documentation).
>>
>> Any chance of that happening? I understand that bringing
>> Documentation/filesystems/fuse.txt up to date would be a major
>> endeavour, but maybe one could just start by putting at least this
>> information into e.g. a new Documentation/filesystems/fuse/writeback.txt
>> file? Together with the requirement that the filesystem has to support
>> reading from files opened O_WRONLY?
>
> Something like this?
Anything is better than nothing. Well, almost anything, but that
definitely includes your draft :-).
> Fuse supports the following writeback modes:
"write modes", or maybe "access modes", not "writeback modes", right?
> - direct-io
> - write-through
> - writeback-cache
>
> In direct-io mode (enabled by the FOPEN_DIRECT_IO flag) the page cache is
> completely bypassed for reads and writes.
I'd add "No read-ahead takes place." (if that's true)
>
> In write-through mode (default) each write modifies the page cache as well as
> immediately being sent to userspace.
Reads may be satisfied from the page cache, and data may be read-ahead
by the kernel to fill the page-cache.
> In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flaga)
> writes go to
Typo in "flaga"
> the cache only, which means that the write(2) syscall can often complete very
> fast. The dirty pages are later sent to userspace using write
> requests.
I think it would be great to be more specific than "later". Maybe "when
the file is no longer opened by any process, when explicitly requested
by an fsync() call, or when the dirty data is evicted from the cache by
the kernel for other reasons" (if that's correct).
> This
> mode assumes that the file is never changed outside the mounted filesystem, so
> it's not suitable for any network fs. If a partial page is written, then the
> page needs to be first read from userspace. This means, thet even for
> files
"that", not "thet"
> opened for O_WRONLY it is possible that read requests will be generated by the
> kernel.
Nice!
Thanks!
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
