On 09/21/2017 12:21 PM, Nikolaus Rath wrote:
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.
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?
Best,
-Nikolaus
