Referrals probably have the same issue. Will need to test when I get back into the office.

But referrals only help with initial mount; after the mount is established, the connections stay where they were established. If a volume moves to a new node, that doesn’t keep locality. They’re also not much help with FlexGroup volumes.

________________________________ From: Sebastian Goetze spgoetze@gmail.com Sent: Tuesday, August 17, 2021 6:45 AM To: Parisi, Justin; tmacmd@gmail.com Cc: toasters@teaparty.net; fschmid@ubimet.com Subject: Re: pNFS

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Justin,

I'm wondering: Does that also go for referrals? Would the IP returned to the client respect the incoming LIF's Broadcast Domain and return the IP of a LIF in the same BD? Or should you refrain from referrals in that situation, too?

I checked TR-4067, but didn't find a mention about that.

@Florian: Could be, that NFS4.0/4.1 referrals are the solution to keeping your paths local, especially, if your volumes do not move around...

Sebastian

On 16.08.2021 18:41, Parisi, Justin via Toasters wrote:

FYI TR-4067 calls out this exact issue as well. There’s currently no way to “blacklist” inelegible interfaces for pnfs. If it’s in the SVM, it will be used with pNFS, regardless of if it’s reachable.

We have an open RFE to allow you to specify LIFs for pNFS to avoid this problem. In the meantime you can blacklist devices from the client as per page 54 of the tr.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters