Re: [fuse-devel] [fuse] getattr() results ignored when writeback cache is active

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 20, 2017 at 5:31 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
> On Sep 20 2017, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
>> On Wed, Sep 20, 2017 at 1:50 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>>> Hi,
>>>
>>> I'm having another problem with FUSE's writeback cache in SSHFS.
>>>
>>> As far as I can tell, the FUSE kernel module issues getattr() requests,
>>> but then silently discards the reported mtime and file size.
>>>
>>> For SSHFS, this means that if a file has been accessed, and is then
>>> changed on the server, the changed attributes don't make it to the
>>> client and the file appears truncated or \0-filled.
>>>
>>> To me this looks like a bug.. am I missing something?
>>
>> 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?


Fuse supports the following writeback modes:

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

In write-through mode (default) each write modifies the page cache as well as
immediately being sent to userspace.

In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flaga) writes go to
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.  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
opened for O_WRONLY it is possible that read requests will be generated by the
kernel.

Thanks,
Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux