Re: RFC: What to do about Allocate in the NFS server for FreeBSD13?

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Mon, 13 Dec 2021 16:30:44 UTC
On Mon, Dec 13, 2021 at 04:26:42PM +0000, Rick Macklem wrote:
> Hi,
> 
> There are two problems with Allocate in the NFSv4.2 server in FreeBSD13:
> 1 - It uses the thread credentials instead of the ones for the RPC.
> 2 - It does not ensure that file changes are committed to stable storage.
> These problems are fixed by commit f0c9847a6c47 in main, which added
> ioflag and cred arguments to VOP_ALLOCATE().
> 
> I can think of 3 ways to fix Allocate in FreeBSD13:
> 1 - Apply a *hackish* patch like this:
> +	savcred = p->td_ucred;
> +	td->td_ucred = cred;
>  	do {
>  		olen = len;
>  		error = VOP_ALLOCATE(vp, &off, &len);
>  		if (error == 0 && len > 0 && olen > len)
>  			maybe_yield();
>  	} while (error == 0 && len > 0 && olen > len);
> +	p->td_ucred = savcred;
>  	if (error == 0 && len > 0)
>  		error = NFSERR_IO;
> +	if (error == 0)
> +		error = VOP_FSYNC(vp, MNT_WAIT, p);
> The worst part of it is temporarily setting td_ucred to cred.
> 
> 2 - MFC'ng commit f0c9847a6c47. Normally changes to the
>      VOP/VFS are not MFC'd. However, in this case, it might be
>      ok to do so, since it is unlikely there is an out of source tree
>      file system with a custom VOP_ALLOCATE() method?
I do not see much wrong with #2, this is what I would do myself.

> 
> 3 - Just disable it. Currently it is disabled by default and it
>      could just be wired down disabled.
>      Allocate is not that useful, since ZFS does not support it.
> 
> As an aside to this, the IETF NFSv4 working group seems to
> have agreed that NFS4ERR_NOTSUPP can be returned by a
> NFSv4.2 server on a 'per file system basis" instead of globally,
> since the Linux knfsd already does this.
> --> As such, Allocate can be enabled by default in main and
>        could be enabled by default in FreeBSD13, if #1 or #2 was
>        done.
>        --> It still would not work for ZFS exports.
> 
> So, what do you think is the preferred alternative?
> 
> rick
>