linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>

  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).