12:38 p.m.
On 3/18/20 12:25 PM, alxg(a)weka.io wrote:
> If everything operates correctly, it should be okay to use
unstable
> writes with commits, even in a cluster, assuming the cluster has proper
> Grace handling.
So what you mentioned before about using only stable writes to avoid corruption - did you
mean this only in the sense of persistency?
I was actually thinking of client side (sync vs. async mounts).
But IMHO the user should anyways be aware of using `fsync` to make
sure data gets to the disk. I was mainly concerned about the interoperability of unstable
writes and floating IPs failovers - but you're saying that most FSALs do allow
unstable writes to some kind of RAM only cache (e.g. pagecache or some userspace lib) on
the ganesha host, and syncing them to the actual disks only on `commit`, and that works
with floating IPs, and the client knows to correctly mark pagecache on its side as not
dirty anymore only after a commit - right?
You misunderstand, or I'm not clear. Ganesha does not have any data
caching, in RAM or otherwise. Various FSALs can/do have various forms
of caching built into their filesystems. One example is the kernel
pagecache used by FSAL_VFS. libcephfs, used by FSAL_CEPH, also has data
caching, both on the client and on the server. Unstable writes use
these caches, whether they be on the Ganesha server, or elsewhere in the
cluster, whether they be in RAM or on some other form of storage. All
Ganesha requires is that the FSAL provide the commit2() op, that ensures
that all previous writes to that handle are permanently committed to
durable storage.
Daniel