On Sep 21 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
> Oh, I understand now. Your example actually demonstrates that
> FUSE_WRITEBACK_CACHE must not be used if it's possible to modify
> underlying data (/tmp/issue_93/file_1) externally w.r.t fuse
> filesystem. That's correct. But initial statement:
>
>> this mode of operation is not suitable for any network filesystem
>> even if no write operations are actually carried out
>
> is not, because it's not impossible to protect underlying data against
> such an external change somehow. A network filesystem is not obliged
> to keep transparent correspondence like /tmp/issue_93_mnt/file_1 <-->
> /tmp/issue_93/file_1. It can keep all user data (and metadata) in
> internal structures making any external modifications
> impossible. Then, implementing exclusive write semantics would make
> using FUSE_WRITEBACK_CACHE safe. Agree?
I agree with what you're saying, but I don't agree that this should go
into the documentation for which the sentence in dispute was intended
:-). I think in 93% of all cases, the simplified statement will be more
helpful to a potential FUSE user than the correct one.
If this bothers you a lot, can we compromise and just be a little more
vague overall? I.e.,
| This mode of operation is therefore generally not suitable for
| filesystems where modifications may not come through the (local) FUSE
| layer (i.e, most network filesystems).
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
