From: Jeff Layton <jlayton@kernel.org>
To: Manfred Schwarb <manfred99@gmx.ch>, linux-nfs@vger.kernel.org
Subject: Re: nfs4.1+: workaround for defunct clientaddr?
Date: Mon, 03 Oct 2022 07:39:02 -0400 [thread overview]
Message-ID: <8cd63730f7b5f3e2aa3bde98587de0c6a42b384b.camel@kernel.org> (raw)
In-Reply-To: <39bf58c7-47d9-744b-6d26-d672aa713024@gmx.ch>
On Sun, 2022-10-02 at 14:35 +0200, Manfred Schwarb wrote:
> Hi,
>
> I have 2 boxes connected with 2 network cards each, one
> crossover connection and one connection via LAN.
> I want to use the crossover connection for backup,
> so I want to be able to select exactly this wire when
> doing my NFS backup transfers. Everything interconnected via NFS4.1
> and automount.
>
> Now the thing is, if there is an already existing connection
> via LAN, I am not able to select the crossover connection,
> there is some session reuse against my will.
>
> automount config:
> /net/192.168.99.1 -fstype=nfs4,nfsvers=4,minorversion=1,clientaddr=192.168.99.100 / 192.168.99.1:/
> /net2/192.168.98.1 -fstype=nfs4,nfsvers=4,minorversion=1,clientaddr=192.168.98.100 / 192.168.98.1:/
>
> mount -l:
> 192.168.99.1:/data on /net/192.168.99.1/data type nfs4 (...,clientaddr=192.168.99.100,addr=192.168.99.1)
> 192.168.99.1:/data on /net2/192.168.98.1/data type nfs4 (...,clientaddr=192.168.99.100,addr=192.168.99.1)
>
> As you see, both connections are on "192.168.99.1:/data", and the backup runs
> over the same wire as all user communication, which is not desired.
> This even happens if I explicitly set some clientaddr= option.
>
> Now I found two workarounds:
> - downgrade to NFS 4.0, clientaddr seems to work with it
> - choose different NFS versions, i.e. one connection with
> minorversion=1 and the other with minorversion=2
>
> Both possibilities seem a bit lame to me.
> Are there some other (recommended) variants which do what I want?
>
> It seems different minor versions result in different "nfs4_unique_id" values,
> and therefore no session sharing occurs. But why do different network
> interfaces (via explicitly set clientaddr= by user) not result in different
> "nfs4_unique_id" values?
>
> Thanks for any comments and advice,
> Manfred
That sounds like a bug. We probably need to compare the clientaddr
values in nfs_compare_super or nfs_compare_mount_options so that it
doesn't match if the clientaddrs are different.
As a workaround, you can probably mount the second mount with
-o nosharecache and get what you want.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2022-10-03 11:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 12:35 nfs4.1+: workaround for defunct clientaddr? Manfred Schwarb
2022-10-03 11:39 ` Jeff Layton [this message]
2022-10-03 11:55 ` Manfred Schwarb
2022-10-03 12:26 ` Jeff Layton
2022-10-03 13:24 ` Manfred Schwarb
2022-10-03 14:18 ` Olga Kornievskaia
2022-10-03 16:14 ` Manfred Schwarb
2022-10-03 19:36 ` Olga Kornievskaia
2022-10-03 14:44 ` Tom Talpey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8cd63730f7b5f3e2aa3bde98587de0c6a42b384b.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=manfred99@gmx.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).