1:13 p.m.
NFSv3 doesn't have any IP failover concept but it does have NFS server or
NFS client reboots or crashes. Think of IP failover as NFS server crashing
and restarting (albeit on another node). Yes, NFS client is supposed to
re-write all UNSTABLE writes. Write verifier is meant to detect this. We
found some bugs in NFS clients where they didn't actually resend UNSTABLE
writes but Linux is not one of them!
If you set NFS_Commit = TRUE, yes Ganesha will write the data to persistent
storage (aka disk), but you will have heavy performance hit. As Dan
indicated this was really meant for VMWare client where it was sending
write followed by commit for any random write (Linux client just sends one
FILE_SYNC write and avoids unnecessary commit)
On Wed, Mar 18, 2020 at 11:08 PM Daniel Gryniewicz <dang(a)redhat.com> wrote:
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
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org