Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow compared to Linux kernel NFSv4

Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow compared to Linux kernel NFSv4

['J. Bruce Fields']

(Moving discussion to linux-nfs list, as it's no longer a Ganesha
issue.)

On Mon, Apr 11, 2016 at 08:40:50AM -0700, Frank Filz wrote:
> Use of async on knfsd is not fair to use in performance evaluation. I have
> long lobbied for renaming the async option to "I don't care about my data."

Yes, renaming might be doable.  "I_dont_care_about_my_data" is a little
cumbersome.  I'm not sure what's best.  Maybe "unsafe_commit"?  Though
that might give the incorrect impression it's just about the commit
operation.

I'm not sure how to manage the transition.

	- Even if they're using "async", they don't deserve to have
	  their server suddenly break on upgrade, so we need to continue
	  to respect "async" in existing /etc/exports files.
	- Are there scripts that scan exports for "sync" or "async"
	  options anywhere, and how might they go wrong?  Maybe I'm
	  overthinking this.

Maybe it'd be good enough to:

	- keep kernel interfaces the same.
	- in nfs-utils, use "unsafe_commit" in all output in place of
	  "async".  Accept "async" as a synonym, but possibly warn that
	  it's been renamed.

--b.

Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow compared to Linux kernel NFSv4

[Cedric Blancher]

Rename "async" to "nodataconsistency"?

Ced

On 11 April 2016 at 18:41, J. Bruce Fields <bfields@fieldses.org> wrote:
> (Moving discussion to linux-nfs list, as it's no longer a Ganesha
> issue.)
>
> On Mon, Apr 11, 2016 at 08:40:50AM -0700, Frank Filz wrote:
>> Use of async on knfsd is not fair to use in performance evaluation. I have
>> long lobbied for renaming the async option to "I don't care about my data."
>
> Yes, renaming might be doable.  "I_dont_care_about_my_data" is a little
> cumbersome.  I'm not sure what's best.  Maybe "unsafe_commit"?  Though
> that might give the incorrect impression it's just about the commit
> operation.
>
> I'm not sure how to manage the transition.
>
>         - Even if they're using "async", they don't deserve to have
>           their server suddenly break on upgrade, so we need to continue
>           to respect "async" in existing /etc/exports files.
>         - Are there scripts that scan exports for "sync" or "async"
>           options anywhere, and how might they go wrong?  Maybe I'm
>           overthinking this.
>
> Maybe it'd be good enough to:
>
>         - keep kernel interfaces the same.
>         - in nfs-utils, use "unsafe_commit" in all output in place of
>           "async".  Accept "async" as a synonym, but possibly warn that
>           it's been renamed.
>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Cedric Blancher <cedric.blancher@gmail.com>
Institute Pasteur