On 10/3/2022 9:24 AM, Manfred Schwarb wrote:
Am 03.10.22 um 14:26 schrieb Jeff Layton:
On Mon, 2022-10-03 at 13:55 +0200, Manfred Schwarb wrote:
Am 03.10.22 um 13:39 schrieb Jeff Layton:
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.
Actually, I take it back, clientaddr is specifically advertised as being
for NFSv4.0 only. The workaround for you is "nosharecache", which will
force the mount under /net2 to get a new superblock altogether.
But clientaddr is silently accepted on NFS4.1+, and seemingly silently does nothing.
The point is, RFC5661 explicitely tells
"NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality".
NFSv4.1 doesn't have a clientaddr in the protocol, only 4.0.
I believe the reason that the clientaddr option is accepted by mount is
to handle multi-protocol negotiate. If the admin requests "any NFSv4"
and provides an explicit clientaddr, it is only needed when falling
all the way down to 4.0, but ignoring it would be incorrect. So perhaps
the mount command could use a tweak.
So this behavior comes as a surprise.
Well, it wouldn't have been an issue if the missing comparison bug that
Jeff mentions was fixed... I think that's the real issue.
Tom.
As a workaround, you can probably mount the second mount with
-o nosharecache and get what you want.
Indeed, nosharecache works. But the man page has some scary words for it:
"This is considered a data risk".
Yeah, it does sound scary but it's not a huge issue unless you're doing
I/O to the same files at the same time via both mounts. With
"sharecache" (the default) you get better cache coherency in that
situation since the inode and its pagecache are the same.
So I guess this is equivalent to the minorversion=1/minorversion=2 trick
cache coherency wise then?
With "nosharecache" you need to be more careful to flush caches, etc. if
you are doing reads and writes to the same files via different paths. If
you need careful coordination there, then you probably want to use file
locking.
Thanks for these explanations, it is appreciated!
Manfred
--
Jeff Layton <jlayton@xxxxxxxxxx>
