[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] [fuse] getattr() results ignored when writeback cache is active
From:       Maxim Patlasov <mpatlasov () virtuozzo ! com>
Date:       2017-09-26 6:55:11
Message-ID: f8ff3346-cc4b-8710-1ecb-4ef7ed5f3fae () virtuozzo ! com
[Download RAW message or body]

On 09/22/2017 12:34 PM, Nikolaus Rath wrote:

> On Sep 21 2017, Maxim Patlasov <mpatlasov@virtuozzo.com> 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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
-- 
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]