On 09/22/2017 12:34 PM, Nikolaus Rath wrote:
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).
The way how Miklos conveyed it:
This mode
assumes that all changes to the filesystem go through the FUSE kernel module
(size and atime/ctime/mtime attributes are kept up-to-date by the kernel), so
it's generally not suitable for network filesystems.
looks perfect. Thank you!
Maxim
