Mailing List Archive

Re:
did you also try to set the ndmpd debug level ?

Harbhajan Julka wrote:

> Hi everybody,
> Has anyone ever been in this situation where an autoloader is connected
> to a NetApp filer and you are trying to figure out the information like
> Extended Sense data, etc sent by the filer upon opening the device,
> targetting it according to the NDMP version 4 documentation.
> I am going through such a problem where i have sent SCSI CDB's to the
> filer like SCSI_INQUIRY, SCSI_READ_ELEMENT_STATUS, SCSI_MOVE_MEDIUM, and
> all you get is something which makes no sense. I am aware quiet roughly
> about the informaiton i should be getting with each of these requests,
> but i dont get that. I dont know how to figure out if i can use the only
> information that is sent back by the filer to find whats wrong and what
> can be changed.
>
> Any suggestions are appreciated,
> Cheers,
> Sonia.
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeover>
>
Re: Re: [ In reply to ]
Just an FYI a new update to that TR is coming soon.


Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Toasters <toasters-bounces@teaparty.net> on behalf of tmac <tmacmd@gmail.com>
Sent: Monday, July 6, 2020 9:51:07 PM
To: Scott Eno <cse@hey.com>
Cc: Toasters <toasters@teaparty.net>
Subject: Re:

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.



https://www.netapp.com/us/media/tr-4067.pdf

Hard, intr, nfsvers=3, rsize=65536,wsize=65536,proto=tcp,mountproto=tcp

Dont forget to modify the client to increase/set tcp_max_slot_table_entries to 128.

--tmac

Tim McCarthy, Principal Consultant

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

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



On Mon, Jul 6, 2020 at 8:45 PM Scott Eno via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>> wrote:



---------- Forwarded message ----------
From: Scott Eno <cse@hey.com<mailto:cse@hey.com>>
To: Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Cc:
Bcc:
Date: Tue, 07 Jul 2020 00:42:56 +0000
Subject: fstab nfsv3 mount favorites?
Hi,

It?s been a number of years since I worked in a Linux/NFS shop, so while I search for my old fstab mount options for a one-off project, does anyone have their go-to fstab nfsv3 mount options handy? The exported volume is on an ONTAP 9.6 cluster if it matters.



---------- Forwarded message ----------
From: Scott Eno via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
To: Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Cc:
Bcc:
Date: Tue, 7 Jul 2020 01:43:01 +0100
Subject:
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
RE: Re: [ In reply to ]
We get lots of questions about NFSv4, especially for the security and locking aspects.

The main issues people see with it are performance (especially with high metadata workloads) and complexity in setup.

It’s a stateful protocol, so it also sees disruption during failovers.

Mostly, people use it for the following reasons:


* Their business makes it a requirement for the security
* They have an application that requires it for the locking
* They want ACLs
* They only want to open up a single port over a firewall

If you just want it for ACLs, ONTAP allows you to set v4 ACLs and still use NFSv3:

https://whyistheinternetbroken.wordpress.com/2017/08/11/nfsv4acls-nfsv3mounts/

From: Toasters <toasters-bounces@teaparty.net> On Behalf Of Sebastian P. Goetze
Sent: Friday, October 2, 2020 3:26 AM
To: Douglas Siggins <siggins@gmail.com>
Cc: Toasters <Toasters@teaparty.net>
Subject: Re:

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.


I teach NetApp and do have students once in a while using NFS v4, but usually only when necessary, e.g. routing through firewalls (which in my experience seems to be the #1 reason using v4). I did have people using pNFS in production, but that's rare.

Some are evaluating, though. Maybe when multipathing is supported (regular like VMware, not pNFS), there will be an uptick in adoption...

My 2c

Greetings from Northfriesland

Sebastian


sent from my mobile, spellchecker might have messed up...

On Thu, 1 Oct 2020, 02:33 Douglas Siggins <siggins@gmail.com<mailto:siggins@gmail.com>> wrote:
Yes, thanks folks. It appears there's not much v4 out there as suspected.



On Wed, Sep 30, 2020, 20:12 Jeff Cleverley via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>> wrote:



---------- Forwarded message ----------
From: Jeff Cleverley <jeff.cleverley@broadcom.com<mailto:jeff.cleverley@broadcom.com>>
To: Wayne McCormick <Wayne.McCormick@sjrb.ca<mailto:Wayne.McCormick@sjrb.ca>>
Cc: Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Bcc:
Date: Wed, 30 Sep 2020 18:03:42 -0600
Subject: Re: Any Openstack/Netapp FAS deployments w cinder NFS, v3 or v4
Wayne,

Just so you know your posts are working, I'll reply. I have no experience with that at this point in time. Personally I don't see an issue posting to ensure the NetApp configurations are correct or compatible with the configurations.

Jeff

On Fri, Sep 25, 2020 at 9:09 AM Wayne McCormick <Wayne.McCormick@sjrb.ca<mailto:Wayne.McCormick@sjrb.ca>> wrote:
I hope I’m doing this right… (posting to the list I mean).

I have four MySQL servers using NFSv4, but not with krb5. The rest of the environment is v3.

We did do a pilot with OpenStack Container Platform and we used v3 (v4 was enabled, so it may have used it) provisioning via Trident with success. We also used Trident to provision iSCSI volumes. Worked quite well.

Hope that helps a little.

Wayne

From: Toasters <toasters-bounces@teaparty.net<mailto:toasters-bounces@teaparty.net>> On Behalf Of Douglas Siggins
Sent: Friday, September 25, 2020 9:01 AM
To: Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Subject: Re: Any Openstack/Netapp FAS deployments w cinder NFS, v3 or v4


CAUTION: This email is from an external source. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Crickets ? :)

Alright let us remove openstack qualifier. Does anyone use v4 or know anyone that does with Netapp FAS?

On Tue, Sep 22, 2020 at 6:53 PM Douglas Siggins <siggins@gmail.com<mailto:siggins@gmail.com>> wrote:
Greetings,
Just reaching out for experiences on Openstack deployments with Netapp NFS. Are you using the default v4 or have switched the mount options to v3? We have a pretty good base of ISCSI, but based on performance and manageability are considering making the jump.

Speaking of NFSv4, outside of openstack has anyone made any large deployments? Is it as solid as v3? using uid/gid, is anyone using sec=krb5?



Regards,
Douglas
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters


--
** Please note my email address has changed to jeff.cleverley@broadcom.com<mailto:jeff.cleverley@broadcom.com>

Jeff Cleverley
Factory Systems Engineer
4380 Ziegler Road
Building 1, Dock 1
Fort Collins, Colorado 80525
970-288-4611



---------- Forwarded message ----------
From: Jeff Cleverley via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
To: Wayne McCormick <Wayne.McCormick@sjrb.ca<mailto:Wayne.McCormick@sjrb.ca>>
Cc: Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Bcc:
Date: Thu, 1 Oct 2020 01:04:02 +0100
Subject:
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
AW: Re: [ In reply to ]
This sounds interesting and I’ve tried that now:

CLUSTER::> version -node *
nodeA :
NetApp Release 9.3P6: Thu Jun 14 20:21:25 UTC 2018

nodeB :
NetApp Release 9.3P6: Thu Jun 14 20:21:25 UTC 2018

2 entries were displayed.

CLUSTER::> cluster image package show
Package Version Package Build Time
---------------- ------------------
9.3P6 6/15/2018 00:21:25
9.5P12 4/10/2020 22:20:31
9.7P11 1/13/2021 03:00:49
3 entries were displayed.

CLUSTER::> cluster image update -version 9.7P11
Starting validation for this update...
It can take several minutes to complete validation...

[… your house will burn, your kids will die …]

Warning: Validation has reported warnings.

Info: The upgrade will happen in two stages.
Stage 1: Cluster will be upgraded to intermediate release (Data ONTAP 9.5P12)
Stage 2: Cluster will be upgraded from Data ONTAP 9.5P12 to Data ONTAP 9.7P11

CLUSTER::> cluster image show-update-progress

Upgrade Stage (1 of 2): Upgrade from 9.3P6 to 9.5P12

Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:00:28
Data ONTAP updates in-progress 01:17:00 00:00:05

So thanks, learned something new here that will save us some time for multi-hop upgrades ????

Best,

Alexander Griesser
Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.com<mailto:AGriesser@anexia-it.com>
Web: http://www.anexia-it.com<http://www.anexia-it.com/>

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Toasters <toasters-bounces@teaparty.net> Im Auftrag von tmac
Gesendet: Donnerstag, 4. März 2021 04:56
An: Brian Parent <bparent@ucsd.edu>
Cc: toasters@teaparty.net
Betreff: Re:

That is correct and wrong at the same time ;)

You still cannot go directly from 9.3 to 9.7. I have heard you can load up 9.5 and 9.7 images and it will progress through:
9.3 -> 9.5 and then 9.5 -> 9.7

Still a double hop, but somewhat automated.

Personally, I would still do the 9.3 -> 9.5, wait at least 24 hours and then do the 9.5 -> 9.7

--tmac

Tim McCarthy, Principal Consultant

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

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



On Wed, Mar 3, 2021 at 8:44 PM Brian Parent via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>> wrote:



---------- Forwarded message ----------
From: Brian Parent <bparent@ucsd.edu<mailto:bparent@ucsd.edu>>
To: Heino Walther <hw@beardmann.dk<mailto:hw@beardmann.dk>>
Cc: "toasters@teaparty.net<mailto:toasters@teaparty.net>" <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Bcc:
Date: Wed, 3 Mar 2021 17:41:48 -0800
Subject: Re:
I'm hearing conflicting information about being limited to 2 versions per hop.
Our support team says once we're at 9.3, we should be able to go directly to 9.7.

I guess we'll find out, and I can update this list on how it goes.
The update is scheduled for late March.

Re:
> From: Heino Walther <hw@beardmann.dk<mailto:hw@beardmann.dk>>
> Date: Fri, 5 Feb 2021 19:08:57 +0000
> Subject: SV:
> To: Brian Parent <bparent@ucsd.edu<mailto:bparent@ucsd.edu>>, "toasters@teaparty.net<mailto:toasters@teaparty.net>"
> <toasters@teaparty.net<mailto:toasters@teaparty.net>>
>
> I would recommend 9.7p10
>
> Be aware that you can only jump 2 versions… so it’s 9.1 to 9.3 to 9.5 to 9.7 ????
> I would recommend a pause between each version, and get the latest patched version also…
> I seem to remember one specific version where the cluster certificate in the downloaded ontap version was expired, which resulted in an upgrade of the cluster never completing… no downtime or anything, but NetApp support had to fix the cluster database… ????
>
> I have been working with NetApp for 15 years and never done a real production revert in my life ????. But maybe I’m just lucky?
>
> /Heino
>
>
> I've got an AFF8020 running 9.1P10 and wondering whether I should target 9.6P10 or 9.7P10 as the destination version.
> I'm aware that such an upgrade will require a hop to 9.3 first.
> I'm also aware that reversion can not skip a release, which is a little scary. I *really* hope I don't have to revert
> from 9.6 or 9.7 all the way back to 9.3 (3 or 4 hops).
>
> What I'm looking for is advice on 9.6p10 vs. 9.7p10. Any horror stories of either release?
> I'm leaning towards 9.7p10, just because it's more recent.
>
>
> Fra: Toasters <toasters-bounces@teaparty.net<mailto:toasters-bounces@teaparty.net>> på vegne af Brian Parent via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
> Dato: fredag, 5. februar 2021 kl. 19.22
> Til: toasters@teaparty.net<mailto:toasters@teaparty.net> <toasters@teaparty.net<mailto:toasters@teaparty.net>>
> Emne: <no subject>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net<mailto:Toasters@teaparty.net>
> https://urldefense.com/v3/__https://www.teaparty.net/mailman/listinfo/toasters__;!!Mih3wA!QxORDgWRDHzpMqq8n1se9Qyhg0knsLVaxgXy6W8O4nYcjoHvQMp0ckrekdY6qvU$<https://urldefense.com/v3/__https:/www.teaparty.net/mailman/listinfo/toasters__;!!Mih3wA!QxORDgWRDHzpMqq8n1se9Qyhg0knsLVaxgXy6W8O4nYcjoHvQMp0ckrekdY6qvU$>

--
Brian Parent
Information Technology Services Department
ITS Computing Infrastructure Operations Group
its-ci-ops-help@ucsd.edu<mailto:its-ci-ops-help@ucsd.edu> (team email address for Service Now)
UC San Diego
(858) 534-6090



---------- Forwarded message ----------
From: Brian Parent via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
To: Heino Walther <hw@beardmann.dk<mailto:hw@beardmann.dk>>
Cc: "toasters@teaparty.net<mailto:toasters@teaparty.net>" <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Bcc:
Date: Thu, 4 Mar 2021 01:42:00 GMT
Subject:
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
SV: Re: [ In reply to ]
You are right, snapdiff it self is not NDMP, but rather the way ONTAP finds the changed files on the system in a quick way?
But you would normally use the NDMP protocol to get data out of your system, or else you will have to mount it on your backup server as a NFS/CIFS share and back it up like that? which is typically slow compared to NDMP.

/Heino

Fra: Basil <basilberntsen@gmail.com>
Dato: l?rdag, 10. april 2021 kl. 12.56
Til: Heino Walther <hw@beardmann.dk>
Cc: Brian Parent <bparent@ucsd.edu>, toasters@teaparty.net <toasters@teaparty.net>
Emne: Re:
Snapdiff is new actually- not NDMP. I am experiencing a bug in gmail on ios so I can?t paste the link but the first Google result for netapp ndmp snapdiff is the blog post explaining it :)

On Sat, Apr 10, 2021 at 6:36 AM Heino Walther <hw@beardmann.dk<mailto:hw@beardmann.dk>> wrote:
As fas as I can remember snapdiff is using NDMP which should be a standard and open protocol, but NetApp, EMC and others have made their specific changes to their version of NDMP which basically make them not interchangeable.
So I guess you will need a NetApp controller in order to restore your data.
There is a slim chance that files can be restored to other NDMP devices (CIFS or NFS), but LUNs are required to be restored to a NDMP.

You can either just keep a NetApp controller ready for this (with no service on it) or maybe just setup an ONTAP Select virtual instance in vSphere which you will be able to restore to, and it?s not as expensive and a NetApp Hardware box.

/Heino

Fra: Toasters <toasters-bounces@teaparty.net<mailto:toasters-bounces@teaparty.net>> p? vegne af Brian Parent via Toasters <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Dato: l?rdag, 10. april 2021 kl. 02.12
Til: toasters@teaparty.net<mailto:toasters@teaparty.net> <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Emne: <no subject>
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
Re: Re: [ In reply to ]
>>>>> "Joseph" == Joseph Zoda <joseph.zoda@palmbeachschools.org> writes:

Joseph> Andre - I second that.... especially after all this time.

Me too... if it's so critical, it should be on by default. But I've
never used it in all my years doing this.
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters
RE: Re: [ In reply to ]
Yeah it’s interesting that they aren’t created automatically.

It could have something to do with issues it causes. Especially if you are using SRM \ SRA within an NFS VMWare environment.

Chris

From: Toasters <toasters-bounces@teaparty.net> On Behalf Of André M. Clark
Sent: 30 April 2021 14:20
To: Scott M Gelb <scottgelb@yahoo.com>; Parisi, Justin <justin.parisi@netapp.com>; Scott M Gelb via Toasters <toasters@teaparty.net>; John Stoffel <john@stoffel.org>
Subject: Re:

[EXTERNAL]

One thing that I have always thought about with SVM root vol protection is, if it is an operational recommendation, why aren’t they automatically created in a System Manager workflow when a NAS SVM is created? Things to make you say, Hmmmmmmmn


From: Scott M Gelb via Toasters <toasters@teaparty.net><mailto:toasters@teaparty.net>
Reply: Scott M Gelb <scottgelb@yahoo.com><mailto:scottgelb@yahoo.com>
Date: April 28, 2021 at 16:46:47
To: Parisi, Justin <justin.parisi@netapp.com><mailto:justin.parisi@netapp.com>, John Stoffel <john@stoffel.org><mailto:john@stoffel.org>
Cc: toasters@teaparty.net<mailto:toasters@teaparty.net> <toasters@teaparty.net><mailto:toasters@teaparty.net>
Subject:


I have used both DP and LS over the years and am back to using LS more often for reasons Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump through to re-create the mirrors after a failover test. LS mirror promote and recreate after had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to recover svm root, but to follow best practices for NAS, still implement them. I don't create mirrors on all nodes and use 1-2 copies depending on cluster size.

An interesting test in mirror activation, is that the mirror picks up the existing SVM junctions regardless of the state of SVM root mirror. For example:

1) An SVM has 4 junction paths
2) SVM root mirror LS or DP to protect SVM root
3) unmount 3 of the junction paths leaving 1 junction path
4) failover to the root mirror (promote LS or break/make-vsroot DP)
5) SVM root running on the failed over volume has the 1 junction path, not the 4 that existed at the time of the mirror... there was no real failure, and the procedure with the SVM running keeps the current state. If a real disaster, I would expect recovery to what was in the mirror, but have never had to recover svm root.

An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if feasible. Not a show stopper or requirement, nor high priority.

On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel <john@stoffel.org<mailto:john@stoffel.org>> wrote:



Justin> Another pretty major difference between LS and DP methods;
Justin> DP method requires manual intervention when a failover/restore is needed.

This is fine in my case, because I'm really trying to protect against
a shipping failure, though it's tempting to do more to protect against
root volume failures as well. Though I've honestly never had one, nor
had a netapp fail so badly in 22+ years of using them that I lost data
from hardware failures.

Closest I came was on a F740 (I think) using the DEC StorageWorks
canisters and shelves. I had a two disk failure in an aggregate. One
disk you could hear scrapping the heads on the platter, the other was
a controller board failure. Since I had nothing to lose, I took the
good controller board off the head crash drive and put it onto the
other disk. System came up and found the data and started
rebuilding. Whew! Raid-DP is a good thing today for sure.


Justin> LS Mirrors are running in parallel and incoming reads/access
Justin> requests (other than NFSv4) hit the LS mirrors rather than the
Justin> source volume, so if one fails, you don’t have to do anything
Justin> right away; you’d just need to resolve the issue at some
Justin> point, but no interruption to service.

That's a decent reason to use them.

Justin> LS mirrors can also have a schedule to run to avoid needing to
Justin> update them regularly. And, if you need to write to the SVM
Justin> root for some reason, you’d need to access the .admin path in
Justin> the vsroot; LS mirrors are readonly (like DP mirrors).

The default for 9.3 seems to be 1 hour, but I bumped it to every 5
minutes, because I have Netbackup backups which use snapshots and 'vol
clone ...' to mount Oracle volumes for backups. I had to hack my
backuppolicy.sh script to put in a 'sleep 305' to make it work
properly.

Trying to make it work generically with 'snapmirror update-ls-set
<vserver>:<source>' wasn't working for some reason, so the quick hack
of a sleep got me working.


But I am thinking of dropping the LS mirrors and just going with DP
mirrors of all my rootvols instead, just because of this issue.


But let's do a survey, how many people on here are using LS mirrors of
your rootvols on your clusters? I certainly wasn't across multiple
clusters.

Jhn


_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters<https://clicktime.symantec.com/3Mv9ujoNQEkcpi63Sctndn57Vc?u=https%3A%2F%2Fwww.teaparty.net%2Fmailman%2Flistinfo%2Ftoasters>
_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters<https://clicktime.symantec.com/3Mv9ujoNQEkcpi63Sctndn57Vc?u=https%3A%2F%2Fwww.teaparty.net%2Fmailman%2Flistinfo%2Ftoasters>

This email is being sent by a subsidiary of Arthur J. Gallagher Holdings (UK) Limited, part of the Arthur J. Gallagher & Co. global group of companies. For details of the registered office, company number and, where applicable, regulated status of our subsidiaries, please visit https://www.ajginternational.com/legal-regulatory-information/.

We are the data controller of any personal information you provide to us or personal information that has been provided to us by a third party. We collect and process information about you in order to arrange insurance policies and to process claims. Your information is also used for business purposes such as fraud prevention and detection and financial management. This may involve sharing your information with third parties such as insurers, reinsurers, other brokers, claims handlers, loss adjusters, credit reference agencies, service providers, professional advisors, our regulators, police and government agencies or fraud prevention agencies.

We may record telephone calls to help us monitor and improve the service we provide. For further information on how your information is used and your rights in relation to your information please see our privacy notice at https://www.ajginternational.com/Privacy-Policy/. If you are providing personal data of another individual to us, you must tell them you are providing their information to us and show them a copy of this notice.

Where you are obtaining a non-consumer policy of (re)insurance, or cover for additional risks or renewal under an existing policy, you are required to make a fair presentation of the risk to a (re)insurer which discloses every material circumstance which you know or ought to know relating to the risk to be insured. A circumstance is material if it would influence the judgment of a prudent insurer in determining whether to provide insurance for the risk and, if so, on what terms. Disclosure must be reasonably clear and accessible to a prudent insurer and made in good faith. The aforementioned duty of disclosure is the applicable duty under the laws of England and Wales. If your policy is not subject to English law you are expected to disclose risk information in accordance with the requirements of the applicable law. In such circumstances we expect you will disclose risk information at least equal to the standard required under English law and where the applicable law requires you to disclose information over and above the level required under English law you will provide such information in accordance with that law.

Where you are obtaining a consumer policy of insurance, you must read each question and answer honestly and fully and must take reasonable care to not make a misrepresentation.

Failure to comply with the above disclosure requirements, as they apply to you, could mean that your policy of (re)insurance is void, its terms are materially altered or that (re)insurers are not liable to pay all or part of your claim(s). If you are in any doubt as to your obligations you should ask your usual contact.

This e-mail and any attachments are CONFIDENTIAL and may contain legally privileged information. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although the above company has taken reasonable precautions to ensure this e-mail and any attachments are free of any virus or other defect that may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and the above company does not accept any responsibility for any loss or damage arising in any way from its use.
RE: Re: [ In reply to ]
>>>>> "Chris" == Chris Hague <Chris_Hague@ajg.com> writes:

Chris> Yeah it’s interesting that they aren’t created automatically.

Chris> It could have something to do with issues it causes. Especially
Chris> if you are using SRM \ SRA within an NFS VMWare environment.

We're using ESX NFS datastores, so now I'm wondering if I've
potentially screwed myself over at some point.

It might just be smarter to make snapmirrors of my various VServer
rootvols instead. It's not like I've ever had any performance issues
with my rootvols, and now I have to wait 5 minutes for changes (vol
clone... vol mount ...) to take effect, or push the updates manually.

I honestly think this is a poor design which could be improved.

John


Chris> From: Toasters <toasters-bounces@teaparty.net> On Behalf Of André M. Clark
Chris> Sent: 30 April 2021 14:20
Chris> To: Scott M Gelb <scottgelb@yahoo.com>; Parisi, Justin <justin.parisi@netapp.com>; Scott M Gelb
Chris> via Toasters <toasters@teaparty.net>; John Stoffel <john@stoffel.org>
Chris> Subject: Re:

Chris> [EXTERNAL]

Chris> One thing that I have always thought about with SVM root vol protection is, if it is an
Chris> operational recommendation, why aren’t they automatically created in a System Manager workflow
Chris> when a NAS SVM is created? Things to make you say, Hmmmmmmmn

Chris> From: Scott M Gelb via Toasters <toasters@teaparty.net>
Chris> Reply: Scott M Gelb <scottgelb@yahoo.com>
Chris> Date: April 28, 2021 at 16:46:47
Chris> To: Parisi, Justin <justin.parisi@netapp.com>, John Stoffel <john@stoffel.org>
Chris> Cc: toasters@teaparty.net <toasters@teaparty.net>
Chris> Subject:

Chris> I have used both DP and LS over the years and am back to using LS more often for reasons
Chris> Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump
Chris> through to re-create the mirrors after a failover test. LS mirror promote and recreate after
Chris> had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to
Chris> recover svm root, but to follow best practices for NAS, still implement them. I don't create
Chris> mirrors on all nodes and use 1-2 copies depending on cluster size.

Chris> An interesting test in mirror activation, is that the mirror picks up the existing SVM
Chris> junctions regardless of the state of SVM root mirror. For example:

Chris> 1) An SVM has 4 junction paths

Chris> 2) SVM root mirror LS or DP to protect SVM root

Chris> 3) unmount 3 of the junction paths leaving 1 junction path

Chris> 4) failover to the root mirror (promote LS or break/make-vsroot DP)

Chris> 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that
Chris> existed at the time of the mirror... there was no real failure, and the procedure with the
Chris> SVM running keeps the current state. If a real disaster, I would expect recovery to what
Chris> was in the mirror, but have never had to recover svm root.

Chris> An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to
Chris> manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/
Chris> vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if
Chris> feasible. Not a show stopper or requirement, nor high priority.

Chris> On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel <john@stoffel.org> wrote:

Justin> Another pretty major difference between LS and DP methods;
Justin> DP method requires manual intervention when a failover/restore is needed.

Chris> This is fine in my case, because I'm really trying to protect against
Chris> a shipping failure, though it's tempting to do more to protect against
Chris> root volume failures as well. Though I've honestly never had one, nor
Chris> had a netapp fail so badly in 22+ years of using them that I lost data
Chris> from hardware failures.

Chris> Closest I came was on a F740 (I think) using the DEC StorageWorks
Chris> canisters and shelves. I had a two disk failure in an aggregate. One
Chris> disk you could hear scrapping the heads on the platter, the other was
Chris> a controller board failure. Since I had nothing to lose, I took the
Chris> good controller board off the head crash drive and put it onto the
Chris> other disk. System came up and found the data and started
Chris> rebuilding. Whew! Raid-DP is a good thing today for sure.

Justin> LS Mirrors are running in parallel and incoming reads/access
Justin> requests (other than NFSv4) hit the LS mirrors rather than the
Justin> source volume, so if one fails, you don’t have to do anything
Justin> right away; you’d just need to resolve the issue at some
Justin> point, but no interruption to service.

Chris> That's a decent reason to use them.

Justin> LS mirrors can also have a schedule to run to avoid needing to
Justin> update them regularly. And, if you need to write to the SVM
Justin> root for some reason, you’d need to access the .admin path in
Justin> the vsroot; LS mirrors are readonly (like DP mirrors).

Chris> The default for 9.3 seems to be 1 hour, but I bumped it to every 5
Chris> minutes, because I have Netbackup backups which use snapshots and 'vol
Chris> clone ...' to mount Oracle volumes for backups. I had to hack my
Chris> backuppolicy.sh script to put in a 'sleep 305' to make it work
Chris> properly.

Chris> Trying to make it work generically with 'snapmirror update-ls-set
Chris> <vserver>:<source>' wasn't working for some reason, so the quick hack
Chris> of a sleep got me working.

Chris> But I am thinking of dropping the LS mirrors and just going with DP
Chris> mirrors of all my rootvols instead, just because of this issue.

Chris> But let's do a survey, how many people on here are using LS mirrors of
Chris> your rootvols on your clusters? I certainly wasn't across multiple
Chris> clusters.

Chris> Jhn

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

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

Chris> This email is being sent by a subsidiary of Arthur J. Gallagher Holdings (UK) Limited, part of the
Chris> Arthur J. Gallagher & Co. global group of companies. For details of the registered office, company
Chris> number and, where applicable, regulated status of our subsidiaries, please visit
Chris> https://www.ajginternational.com/legal-regulatory-information/.

Chris> We are the data controller of any personal information you provide to us or personal information
Chris> that has been provided to us by a third party. We collect and process information about you in
Chris> order to arrange insurance policies and to process claims. Your information is also used for
Chris> business purposes such as fraud prevention and detection and financial management. This may
Chris> involve sharing your information with third parties such as insurers, reinsurers, other brokers,
Chris> claims handlers, loss adjusters, credit reference agencies, service providers, professional
Chris> advisors, our regulators, police and government agencies or fraud prevention agencies.

Chris> We may record telephone calls to help us monitor and improve the service we provide. For further
Chris> information on how your information is used and your rights in relation to your information please
Chris> see our privacy notice at https://www.ajginternational.com/Privacy-Policy/. If you are providing
Chris> personal data of another individual to us, you must tell them you are providing their information
Chris> to us and show them a copy of this notice.

Chris> Where you are obtaining a non-consumer policy of (re)insurance, or cover for additional risks or
Chris> renewal under an existing policy, you are required to make a fair presentation of the risk to a
Chris> (re)insurer which discloses every material circumstance which you know or ought to know relating
Chris> to the risk to be insured. A circumstance is material if it would influence the judgment of a
Chris> prudent insurer in determining whether to provide insurance for the risk and, if so, on what
Chris> terms. Disclosure must be reasonably clear and accessible to a prudent insurer and made in good
Chris> faith. The aforementioned duty of disclosure is the applicable duty under the laws of England and
Chris> Wales. If your policy is not subject to English law you are expected to disclose risk information
Chris> in accordance with the requirements of the applicable law. In such circumstances we expect you
Chris> will disclose risk information at least equal to the standard required under English law and where
Chris> the applicable law requires you to disclose information over and above the level required under
Chris> English law you will provide such information in accordance with that law.

Chris> Where you are obtaining a consumer policy of insurance, you must read each question and answer
Chris> honestly and fully and must take reasonable care to not make a misrepresentation.

Chris> Failure to comply with the above disclosure requirements, as they apply to you, could mean that
Chris> your policy of (re)insurance is void, its terms are materially altered or that (re)insurers are
Chris> not liable to pay all or part of your claim(s). If you are in any doubt as to your obligations you
Chris> should ask your usual contact.

Chris> This e-mail and any attachments are CONFIDENTIAL and may contain legally privileged information.
Chris> If you are not the intended recipient of this e-mail message, please telephone or e-mail us
Chris> immediately, delete this message from your system and do not read, copy, distribute, disclose or
Chris> otherwise use this e-mail message and any attachments. Although the above company has taken
Chris> reasonable precautions to ensure this e-mail and any attachments are free of any virus or other
Chris> defect that may affect your computer, it is the responsibility of the recipient to ensure that it
Chris> is virus free and the above company does not accept any responsibility for any loss or damage
Chris> arising in any way from its use.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters
SV: Re: [ In reply to ]
Well since they are snapmirrored, they should be the same as the source?
I cannot change the destination volumes as they are read-only (because they are snapmirror destinations)….. ????

/Heino

Fra: André M. Clark <andre.m.clark@gmail.com>
Dato: fredag, 5. august 2022 kl. 17.48
Til: Timothy Naple <tnaple@vectordata.com>, Heino Walther <hw@beardmann.dk>, toasters@teaparty.net <toasters@teaparty.net>
Emne: Re:
Check to see if your volumes are thin provisioned on the destination side. By default, they would not be thin provisioned.

Regards,
André M. Clark



On August 5, 2022 at 11:03:13, Timothy Naple via Toasters (toasters@teaparty.net<mailto:toasters@teaparty.net>) wrote:
My first guess would be that you might somehow be retaining more snapshots on the destination, perhaps at the volume level? snap list for all the volumes is identical on source and destination? Does df -h on both sides show which volumes, if any, have a size discrepancy?

Maybe a 2nd guess would be that the space guarantee settings are different on the destination volumes.
________________________________
From: Toasters <toasters-bounces@teaparty.net<mailto:toasters-bounces@teaparty.net>> on behalf of Heino Walther <hw@beardmann.dk<mailto:hw@beardmann.dk>>
Sent: Friday, August 5, 2022 7:31 AM
To: toasters@teaparty.net<mailto:toasters@teaparty.net> <toasters@teaparty.net<mailto:toasters@teaparty.net>>
Subject: Space issues on older NetApp...


Hi there



We have two systems that mirror eachothers volumes via snapmirror.

We are talking 7mode ONTAP 8.1.4

The two systems have the same controller: FAS3240

They have the same disks and aggregate configuration (70TB aggregates)



On the source side we use volumes that are thin-provisioned with LUNs that have space reservation enabled, the LUNs are mostly close to 16TB (which is max)



All volumes are snapmirrored to volumes on the destination system with the same size and placed on the same aggregates that mirror the source aggregates in size…



The aggregates on the source are all below 95% used.



Yet.. we are now at the situation where a few destination aggregates are 100% full, while the source aggregates are still under 95% used…

I have checked almost everything, like aggregate snapshot reserves etc.. but they should be the same…



Can anyone explain why this can happen?



We are of cause at a “deadlock” now.. I don’t think we can add anymore disks to the aggregates as they are max size…

The only think I can think of is either delete a volume from the affected aggregates, and re-sync the volume and hope it doesn’t fill up again…



Another way would be to add disks and build a new aggregate, and move some of the volumes…



Is there something I have missed? ????



/Heino


_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
https://www.teaparty.net/mailman/listinfo/toasters
Re: SV: Re: [ In reply to ]
Not neceraily true. Unless it is an AFF, depending on how the destination
volume was created, the guarantee will be set to volume. You can modify
this, even on a snap mirror destination. Take a look. ????


On 5August 2022 at 14:09:28, Heino Walther (hw@beardmann.dk) wrote:

Well since they are snapmirrored, they should be the same as the source?

I cannot change the destination volumes as they are read-only (because they
are snapmirror destinations)….. ????



/Heino



*Fra: *André M. Clark <andre.m.clark@gmail.com>
*Dato: *fredag, 5. august 2022 kl. 17.48
*Til: *Timothy Naple <tnaple@vectordata.com>, Heino Walther <hw@beardmann.dk>,
toasters@teaparty.net <toasters@teaparty.net>
*Emne: *Re:

Check to see if your volumes are thin provisioned on the destination side.
By default, they would not be thin provisioned.



Regards,

André M. Clark





On August 5, 2022 at 11:03:13, Timothy Naple via Toasters (
toasters@teaparty.net) wrote:

My first guess would be that you might somehow be retaining more snapshots
on the destination, perhaps at the volume level? snap list for all the
volumes is identical on source and destination? Does df -h on both sides
show which volumes, if any, have a size discrepancy?



Maybe a 2nd guess would be that the space guarantee settings are different
on the destination volumes.
------------------------------

*From:* Toasters <toasters-bounces@teaparty.net> on behalf of Heino Walther
<hw@beardmann.dk>
*Sent:* Friday, August 5, 2022 7:31 AM
*To:* toasters@teaparty.net <toasters@teaparty.net>
*Subject:* Space issues on older NetApp...



Hi there



We have two systems that mirror eachothers volumes via snapmirror.

We are talking 7mode ONTAP 8.1.4

The two systems have the same controller: FAS3240

They have the same disks and aggregate configuration (70TB aggregates)



On the source side we use volumes that are thin-provisioned with LUNs that
have space reservation enabled, the LUNs are mostly close to 16TB (which is
max)



All volumes are snapmirrored to volumes on the destination system with the
same size and placed on the same aggregates that mirror the source
aggregates in size…



The aggregates on the source are all below 95% used.



Yet.. we are now at the situation where a few destination aggregates are
100% full, while the source aggregates are still under 95% used…

I have checked almost everything, like aggregate snapshot reserves etc..
but they should be the same…



Can anyone explain why this can happen?



We are of cause at a “deadlock” now.. I don’t think we can add anymore
disks to the aggregates as they are max size…

The only think I can think of is either delete a volume from the affected
aggregates, and re-sync the volume and hope it doesn’t fill up again…



Another way would be to add disks and build a new aggregate, and move some
of the volumes…



Is there something I have missed? ????



/Heino



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