[Gluster-users] has anybody ever used these features?

[Carlos Capriotti]

I can comment about my FEELING on this one:

Option: nfs.trusted-sync
Default Value: (null)
Description: All writes and COMMIT requests are treated as async. This
implies that no write requests are guaranteed to be on server disks when
the write reply is received at the NFS client. Trusted sync includes
trusted-write behavior. Off by default.


I could be wrong, but, from what I gather this will NOT make sure your
files are ACTUALLY written to the disk, and could be on (cache)  memory
somewhere, so, another client trying to access it from disk would read old
or unstable data. A disaster for multiple clients accessing the same file.

If you have one client accessing that file (VM images are an example), or
is you have read-only files (web servers) that could make your file access
quicker.


Again, this is what I interpreted. And I am using that option.

KR,





On Tue, Apr 8, 2014 at 8:02 PM, Khoi Mai <KHOIMAI at up.com> wrote:

> Option: nfs.mem-factor
> Default Value: (null)
> Description: Use this option to make NFS be faster on systems by using
> more memory. This option specifies a multiple that determines the to tal
> amount of memory used. Default value is 15. Increase to use more memory in
> order to improve performance for certain use cases.Please co nsult
> gluster-users list before using this option.
>
> Option: nfs.mem-factor
> Default Value: (null)
> Description: Use this option to make NFS be faster on systems by using
> more memory. This option specifies a multiple that determines the to tal
> amount of memory used. Default value is 15. Increase to use more memory in
> order to improve performance for certain use cases.Please co nsult
> gluster-users list before using this option.
>
> Option: nfs.trusted-sync
> Default Value: (null)
> Description: All writes and COMMIT requests are treated as async. This
> implies that no write requests are guaranteed to be on server disks when
> the write reply is received at the NFS client. Trusted sync includes
> trusted-write behaviour. Off by default.
>
> Option: nfs.trusted-write
> Default Value: (null)
> Description: On an UNSTABLE write from client, return STABLE flag to force
> client to not send a COMMIT request. In some environments, combi ned with a
> replicated GlusterFS setup, this option can improve write performance. This
> flag allows user to trust Gluster replication logic to sync data to the
> disks and recover when required. COMMIT requests if received will be
> handled in a default manner by fsyncing. STABLE wr ites are still handled
> in a sync manner. Off by default.
>
> My question is when would you want to use these features.  When do you not
> want to use these features?  My environment has a requirement for
> glusterNFS right now because the FUSE client has shown instability under
> certain load that I cannot recreate with glusterNFS.
>
>
>
> Khoi Mai
>
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
> Any use, review, disclosure, copying, distribution or reliance by others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are not the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140409/c43a14f1/attachment.html>