On 09/21/2017 10:53 AM, Nikolaus Rath wrote:
On Sep 21 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
On 09/21/2017 03:12 AM, Nikolaus Rath wrote:
On Sep 20 2017, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
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.
.."this mode of operation is not suitable for any network filesystem
even if no write operations are actually carried out".
Not true. A network filesystem can guarantee that the file is never
changed outside by implementing exclusive write lease semantics: when
someone opens file for writing first time the metadata server grants
exclusive rights for that mount, then declines all subsequent open
requests from other mounts; and similarly while a file is being kept
opened for reading, the metadata server declines all open-for-writing
requests from other mounts.
In practice that doesn't seem to work, see the example in my first
message. The file is only ever accessed on one mount at a time, yet the
changes do not propagate (and would result in data corruption if another
mount would attempt to read or modify the file afterwards).
In your example you modified file bypassing fuse mount:
> echo -e "\nrevision 2" >> /tmp/issue_93/file_1
That's like mangling block device while ordinary local fs is running on
top of it.
Best,
-Nikolaus
