11:58 a.m.
On 1/28/19 12:45 PM, Jeff Becker wrote:
One more question below...
On 1/28/19 9:37 AM, Daniel Gryniewicz wrote:
> A lot of that looks very out-of-date. The description of what goes in
> the Path statement is correct, but there is no longer an NFSv4_Proxy
> section. Instead, configuration goes in the FSAL subsection of the
> export. You can look at the sample proxy.conf in the repo here:
>
> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/config_samples/p...
>
>
> Or you can look at the man page for FSAL PROXY here:
>
>
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/doc/man/ganesha-...
>
>
> (And sorry for writing PSEUDO in my last email, I meant PROXY)
>
> Daniel
>
> On 1/28/19 12:29 PM, Jeff Becker wrote:
>> Hi,
>>
>> On 1/25/19 5:36 AM, Daniel Gryniewicz wrote:
>>> The path given to PSEUDO needs to be the full path exported by the
>>> other NFS server, not any kind of local mount. So, when you mount
>>> the other server directly, you do this:
>>>
>>> mount -t nfs <server>:<remotepath> <localpath>
>>>
>>> What needs to go in that Path config statement is <remotepath> not
>>> <localpath>. PSEUDO isn't accessing a mount (and, indeed, you
>>> probably should not have the remote server mounted on the Ganesha
>>> box), it's acting as it's own NFS client, and translating NFS calls
>>> directly.
Do you mean on the client mounting the Ganesha server, I should not also
be directly mounting the remote filesystem for which the Ganesha server
is proxying access? Thanks.
Hmm... I think a full explanation is necessary. There are three
machines involved here. First, the original NFS server, hosting the
base filesystem. Lets call this server O, for original. Next, there's
the Ganesha server, which we'll call G. Finally, there's the Client,
which we'll call C. They're likely connected something like this:
O -------- G -------- C
O has one path, when it comes to NFS: it's export path. Let's call this
/exportO. If you were to mount this on a client directly, you would use
a command like this:
mount -t nfs O:/exportO /mnt
Next, G has 2 paths: The export from O that's it's accessing
(O:/exportO) and the export it's providing to clients (call this
/exportG). In the Ganesha config, the Path statement refers to the
export from O, and the Pseudo statement refers to the export from G. So
the config snippit would look like this:
EXPORT {
# ...
# Export on the original server O
Path = /exportO;
# Path we are exporting to clients
Pseudo = /exportG;
FSAL {
Name = PROXY;
Srv_Addr = O;
}
# ...
}
C, again, only has one path to worry about, the one exported from G. To
mount this, you would use a command like this:
mount -n nfs G:/exportG /mnt
So, in effect, Ganesha is acting as both a client and as a server. It
needs to configure it's client using the Path and Srv_Addr statements,
and it's server with the Pseudo statement.
Hope this helps.
Daniel