Mailing List Archive

Re:
I would respectfully disagree.

pNFS does not stripe data across controllers. Data is distributed, not
striped.
Every node is a metadata server and will redirect the client process to the
node directly holding the volume. No striping.

Maybe you are confusing pNFS with FlexGroups which distributes files across
nodes.
A very long time ago in ONTAP GX, there >>was<< an ability to stripe data
across controllers. That feature was removed upon going to ONTAP 8.0

--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*



On Mon, Aug 16, 2021 at 9:36 AM Michael Bergman via Toasters <
toasters@teaparty.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Michael Bergman <michael.bergman@ericsson.com>
> To: Toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 13:34:17 +0000
> Subject: Re: pNFS not working on vserver when several lifs with different
> Vlans available
> On 2021-08-16 15:13, Florian Schmid wrote:
> > Is this really the case? Is the pNFS process really not Vlan aware and
> > sends any IP from that node where volume is located, even when the IP is
> > in a different network than the client IP?
>
> Yes. That's how pNFS is supposed to work. That's the whole point one can
> say, of pNFS. It's striping of the data traffic (not metadata) across
> several nodes, all at once.
>
> In that respect, the setup you say you have, this:
>
> "On the vServer, we have several different Vlans and each Vlans has an
> interface for each node there. Our storage network is completely switched,
> so no routing between Vlans possible."
>
> is totally wrong for pNFS. In such a set up you definitely do not want
> pNFS.
>
> /M
>
>
>
> ---------- Forwarded message ----------
> From: Michael Bergman via Toasters <toasters@teaparty.net>
> To: Toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 14:34:25 +0100
> Subject:
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters
Re: [ In reply to ]
Just out of curiosity, what is the output of "network interface show
-vserver pnfs-svm"
The answer might lie there.
I doubt it is a VLAN issue and more a network design issue.

I found this:

https://mysupport.netapp.com/site/article?lang=en&page=%2FAdvice_and_Troubleshooting%2FData_Storage_Software%2FONTAP_OS%2FNFSv4.1_client_Read%2F%2FWrite_operation_may_be_slow_or_hang_when_pNFS_is_enabled_on_the_SVM&type=reference

Issue

- When NFS client attempts to Read/Write to the SVM with pNFS enabled,
the operation hangs, with "nfs: [LIF address / hostname] server not
responding" in /var/log/messages.

Cause

- This issue occurs in situations where pNFS is enabled on an SVM and
there are LIFs created in different subnets, which are non-routable by the
client
- Data ONTAP may provide any LIF which belong's to the same SVM as the
referral to a client
- The Read/Write operation hangs because the data LIF IP is not
reachable by the client

Solution

- Make sure clients can reach all data LIFs of the SVM

-or-

- Disable support for pNFS on the SVM



--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*



On Mon, Aug 16, 2021 at 9:16 AM Florian Schmid via Toasters <
toasters@teaparty.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Florian Schmid <fschmid@ubimet.com>
> To: toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 13:13:15 +0000 (UTC)
> Subject: pNFS not working on vserver when several lifs with different
> Vlans available
> Hi,
>
> I had a very strange incident some weeks ago.
>
> We are on 9.7 branch.
>
> In one of our vServers, where we had NFSv4 and 4.1 enabled, clients with
> NFSv4.1 and pNFS where unable to read or write data.
> Directory listing was possible.
>
> On the vServer, we have several different Vlans and each Vlans has an
> interface for each node there. Our storage network is completely switched,
> so no routing between Vlans possible.
>
> After creating a NetApp case, they told me, that pNFS doesn't handle Vlans
> and the client will get any IP on that node, even when the IP is from a
> different Vlan and therefor not accessible from the client.
>
> Is this really the case? Is the pNFS process really not Vlan aware and
> sends any IP from that node where volume is located, even when the IP is in
> a different network than the client IP?
>
> As suggested from NetApp, I have disabled pNFS and now everything is
> working.
>
> What is your experience here?
> Is anybody using pNFS with NetApp and if yes, do you only have one network
> in your vServer or is the client able to access all IPs there through
> different Vlans?
>
> I'm curious about your answers.
>
> Best regards
> Florian Schmid
>
>
>
>
> ---------- Forwarded message ----------
> From: Florian Schmid via Toasters <toasters@teaparty.net>
> To: toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 14:13:20 +0100
> Subject:
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters
Re: [ In reply to ]
Wow...Thanks Justin.
I guess that was possibly an oversight when developed (and hence the RFE)?
--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*



On Mon, Aug 16, 2021 at 12:09 PM Parisi, Justin via Toasters <
toasters@teaparty.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: "Parisi, Justin" <Justin.Parisi@netapp.com>
> To: Michael Bergman <michael.bergman@ericsson.com>, Toasters <
> toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 16:06:37 +0000
> Subject: Re:
> 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.
>
> https://www.netapp.com/pdf.html?item=/media/10720-tr-4067.pdf
> ------------------------------
> *From:* Toasters <toasters-bounces@teaparty.net> on behalf of Michael
> Bergman via Toasters <toasters@teaparty.net>
> *Sent:* Monday, August 16, 2021 11:10:12 AM
> *To:* Toasters <toasters@teaparty.net>
> *Subject:*
>
> 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.
>
>
>
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters
>
>
>
> ---------- Forwarded message ----------
> From: "Parisi, Justin via Toasters" <toasters@teaparty.net>
> To: Michael Bergman <michael.bergman@ericsson.com>, Toasters <
> toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Mon, 16 Aug 2021 17:06:46 +0100
> Subject:
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters
Re: [ In reply to ]
Ain?t that the truth!

I had a customer using 18 month old red hat kernels (not patch for a long time)

They upgraded ontap to something modern and either did not realize (likely) or forgot they were using nfs v4.1/pnfs. As soon as ontap finished the boot of the last node to the latest version, ALL the rhel boxes panicked. Upon review it was due to a bug fixed 15 months ago in the kernel. The fix was simple, Chang the mounts to v3.

So sane thought, if you go down the 4.1 path it is best to keep everything current both client and server to avoid nasty bugs

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Toasters <toasters-bounces@teaparty.net> on behalf of Michael Bergman via Toasters <toasters@teaparty.net>
Sent: Tuesday, August 17, 2021 7:52:28 AM
To: Toasters <toasters@teaparty.net>
Subject:

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters
Re: [ In reply to ]
Not from a position of experience, but if I had to hazard a guess, I think
that deduplication would eventually cause all the blocks to be recognized
and squished.

On Wed, Aug 18, 2021 at 12:49 PM Scott Eno via Toasters <
toasters@teaparty.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Scott Eno <cse@hey.com>
> To: Toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Wed, 18 Aug 2021 12:46:10 -0400
> Subject: move files without snapshot growth?
> Hi,
>
> Anyone on this list have a favorite way of moving files from one folder to
> another folder on the same CIFS volume without causing snapshot growth?
>
> I gotta move 10TB+ of data from one folder structure to another folder
> structure on the same CIFS vol. We keep snapshots for a year so I really
> don't want to hang on to 10TB+ of snapshot data for a year.
>
> Can XCP do this somehow? Powershell?
>
> Sorry if this ends up wrapped in a no subject email. I don't know what
> causing that.
>
>
>
> ---------- Forwarded message ----------
> From: Scott Eno via Toasters <toasters@teaparty.net>
> To: Toasters <toasters@teaparty.net>
> Cc:
> Bcc:
> Date: Wed, 18 Aug 2021 17:46:13 +0100
> Subject:
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters