On Sep 21 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
> On 09/21/2017 11:31 AM, Nikolaus Rath wrote:
>
>> On Sep 21 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
>>> 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.
>> Huh? That's exactly what a network filesystem would see when another
>> host writes to the filesystem. The change doesn't come through the local
>> FUSE layer.
>
> In your example the change didn't come through any FUSE layer.
It did. The filesystem reported the updated mtime and size in its
getattr() response. The kernel ignored it.
> When another host writes to a network filesystem, the filesystem has a
> choice to process the request intelligently. In your example, you
> didn't give FUSE a chance because "/tmp/issue_93" was not fuse mount.
Right. /tmp/issue_93 substitutes for the network. The filesystem gets
notification through the network, aka by reading this mountpoint. It
then attempts to pass this on to the FUSE layer, but is being ignored.
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
