toasters

toasters@lists.teaparty.net

13520 discussions

AW: CSM MismatchRemoteDevice
by Alexander Griesser 23 Jun '20

23 Jun '20

All cluster ports up here: CLUSTER::> net int show -role cluster (network interface show) Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- Cluster Node1_clus1 up/up 169.254.101.103/16 node1 e0a true Node1_clus2 up/up 169.254.210.167/16 node1 e0b true Node2_clus1 up/up 169.254.44.143/16 node2 e0a true Node2_clus2 up/up 169.254.161.155/16 node2 e0b true Node3_clus1 up/up 169.254.15.190/16 node3 e0a true Node3_clus2 up/up 169.254.223.100/16 node3 e0b true Node4_clus1 up/up 169.254.183.224/16 node4 e0a true node4_clus2 up/up 169.254.221.115/16 node4 e0b true 8 entries were displayed. CLUSTER::> net port show -broadcast-domain Cluster (network port show) Node: node1 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node2 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node3 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node4 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy 8 entries were displayed. Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com Web: 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 -----Ursprüngliche Nachricht----- Von: Jason Gorrie <jbgorrie(a)uwaterloo.ca> Gesendet: Mittwoch, 17. Juni 2020 13:54 An: Alexander Griesser <AGriesser(a)anexia-it.com> Betreff: Re: CSM MismatchRemoteDevice Hi, I have pages of those on a newly expanded cluster (was 6 nodes, now 10 for a tech refresh). CDP is enabled all over, and “net device-discovery show” shows good data. Currently 9.5P12. I do have one of the ports down (bad cable, RMA taking 4+ days) so perhaps that is why? — Jason > On Jun 17, 2020, at 00:33, Alexander Griesser <AGriesser(a)anexia-it.com> wrote: > > Hey toasters, > > anyone ever experienced such messages in the event log? Mines are getting flooded here. > It’s a 4-Node cluster (9.6P1) and someone forgot to enable CDP on two of the nodes, which (according to the syslog translator) might seem to be the reason for this issue. > > CLUSTER::> event log show > Time Node Severity Event > ------------------- ---------------- ------------- --------------------------- > 6/17/2020 06:28:18 node1 ERROR csm.mismatchRemoteDevice: CSM connection between source LIF 1012 and destination address 169.254.221.115 might not be optimal for session 0b05995fad05cdb0. The source is currently connected to CLUSTER-sw02 remote device and the destination is currently connected to - remote device. > > https://mysupport.netapp.com/site/bugs-online/syslog-translator/details?eve… > > The corrective action in this link just says: > „Ensure that the Cisco Discover Protocol (CDP) is running on the nodes and switches. In addition, ensure that the cluster ports are up and the cluster LIFs are configured and hosted according to the suggested cluster configuration." > > I’ve enabled CDP now for all nodes, cluster ports are up and all the lifs are where they should be. > Do I need to restart this CSM service or something like that in order to retry CDP resolution and get rid of this message? > > Thanks, > > Alexander Griesser

5 17

Re: CSM MismatchRemoteDevice
by Heino Walther 17 Jun '20

17 Jun '20

Thanks Henk I am well aware of this, as this is just in use because we are migrating from an AFF8080 to A700, and then we will remove the AFF8080 and switches once we have completed the migration of volumes… It’s just switches, and pretty basic, so I have no issues that it is on an older FW level 😊 /Heino

3 2

RE: CSM MismatchRemoteDevice
by RUIS Henk 17 Jun '20

17 Jun '20

Hi, For consistency check ONTAP cluster and switches use CONFIGADVISOR. For reference/compliance version table see support site. ONTAP 9.7P2 does limit support CN1610 switches (from 9.6 actualy) Your CN1610 should be 1.3.0.2 with rcf 1.2 Met vriendelijke groet / Kind regards, Henk Ruis Technical Consultant Tel: +31 88 988 9003 - henk.ruis(a)axians.com<mailto:henk.ruis@axians.com> Dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht ten onrechte ontvangt, wordt u verzocht de inhoud niet te gebruiken, maar de afzender direct te informeren door het bericht te retourneren en het daarna te verwijderen. Axians staat niet in voor de juiste overbrenging van een verzonden e-mail, noch voor de tijdige ontvangst daarvan. Van: Toasters <toasters-bounces(a)teaparty.net<mailto:toasters-bounces@teaparty.net>> Namens Heino Walther Verzonden: woensdag 17 juni 2020 14:45 Aan: Tim McCarthy <tmacmd(a)gmail.com<mailto:tmacmd@gmail.com>>; Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>; Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> CC: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Onderwerp: Re: CSM MismatchRemoteDevice My mistake 😉 Here is my output just for reference…. I think it’s a pretty old software I have on the switches 😉 DK01NETAPP01::*> system cluster-switch show-all Switch Type Address Model --------------------------- ------------------ ---------------- --------------- nasw01 cluster-network 172.19.7.145 CN1610 Serial Number: Unknown Is Monitored: false Reason: IP address not reachable Software Version: 1.1.0.7 Version Source: ISDP nasw02 cluster-network 172.19.7.146 CN1610 Serial Number: Unknown Is Monitored: false Reason: IP address not reachable Software Version: 1.1.0.7 Version Source: ISDP 2 entries were displayed. Fra: Tim McCarthy <tmacmd(a)gmail.com<mailto:tmacmd@gmail.com>> Dato: onsdag den 17. juni 2020 kl. 14.36 Til: Heino Walther <hw(a)beardmann.dk<mailto:hw@beardmann.dk>>, Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>, Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> Cc: "toasters(a)teaparty.net<mailto:toasters@teaparty.net>" <toasters(a)teaparty.net<mailto:toasters@teaparty.net>> Emne: Re: CSM MismatchRemoteDevice Should be system cluster-switch show-all The command you had is for the FC switch for things like flex array (attached storage through a FC switch) I’d like some others to try this: If you have a switched cluster run this command and record version of ontap you have and the time it takes to complete (it may take a few moments-minutes) system cluster-switch show Then run this command and note the time (which should be instant or near instant) I want to open a bug on this but need more details like when / which release this actually stopped responding quickly. Get Outlook for iOS<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2F…> ________________________________ From: Toasters <toasters-bounces(a)teaparty.net<mailto:toasters-bounces@teaparty.net>> on behalf of Heino Walther <hw(a)beardmann.dk<mailto:hw@beardmann.dk>> Sent: Wednesday, June 17, 2020 8:22:09 AM To: Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>; Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> Cc: toasters(a)teaparty.net<mailto:toasters@teaparty.net> <toasters(a)teaparty.net<mailto:toasters@teaparty.net>> Subject: Re: CSM MismatchRemoteDevice An even without any switches configured __ DK01NETAPP01::> switch show (storage switch show) This table is currently empty. __. Go figure... /Heino D. 17.06.2020 14.20 skrev "Alexander Griesser" <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>: In your case, it is able to read the switch name - in my case, it's not (name is just "-"). So maybe this is is also the reason for the message, because CDP was disabled in the first place. I think what I'm looking for here is a way to "restart" this CSM daemon or to restart the validation/detection process, if that's possible at all. Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anexia…> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Ursprüngliche Nachricht----- Von: Heino Walther <hw(a)beardmann.dk<mailto:hw@beardmann.dk>> Gesendet: Mittwoch, 17. Juni 2020 14:18 An: Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>; Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> Cc: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Betreff: Re: CSM MismatchRemoteDevice OK, mine looks like this... and as you can see two nodes are connected to the same switches... So I get this error... 6/17/2020 14:10:40 DK01NETAPP01-03 ERROR csm.mismatchRemoteDevice: CSM connection between source LIF 1001 and destination address 169.254.48.70 might not be optimal for session 0a05a7bb5da3abb3. The source is currently connected to nasw02 remote device and the destination is currently connected to nasw01 remote device. (I get other such messages... so I assumed it was because of the cabling) DK01NETAPP01::> network device-discovery show -platform CN1610 Node/ Local Discovered Protocol Port Device (LLDP: ChassisID) Interface Platform ----------- ------ ------------------------- ---------------- ---------------- DK01NETAPP01-04/cdp e3a nasw01 0/2 CN1610 e3c nasw02 0/2 CN1610 DK01NETAPP01-01/cdp e0a nasw01 0/3 CN1610 e0c nasw01 0/4 CN1610 DK01NETAPP01-03/cdp e3a nasw01 0/1 CN1610 e3c nasw02 0/1 CN1610 DK01NETAPP01-02/cdp e0a nasw02 0/3 CN1610 e0c nasw02 0/4 CN1610 8 entries were displayed. Maybe it's the switch config? I sadly does not have any remote management to my switches..... I'm on ONTAP 9.7P2 so pretty new version... /Heino D. 17.06.2020 14.13 skrev "Alexander Griesser" <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>: I would say that the cabling is correct: CLUSTER::> network device-discovery show -platform CN1610 Node/ Local Discovered Protocol Port Device (LLDP: ChassisID) Interface Platform ----------- ------ ------------------------- ---------------- ---------------- Node1 /cdp e0a sw01 0/1 CN1610 e0b sw02 0/1 CN1610 node2 /cdp e0a sw01 0/2 CN1610 e0b sw02 0/2 CN1610 node3 /cdp e0a sw01 0/3 CN1610 e0b sw02 0/3 CN1610 node4 /cdp e0a sw01 0/4 CN1610 e0b sw02 0/4 CN1610 8 entries were displayed. Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anexia…> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Ursprüngliche Nachricht----- Von: Heino Walther <hw(a)beardmann.dk<mailto:hw@beardmann.dk>> Gesendet: Mittwoch, 17. Juni 2020 14:11 An: Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>>; Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> Cc: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Betreff: Re: CSM MismatchRemoteDevice Hi there I have the same messages in my 4-node cluster. I believe it's because of the cluster cabling isn't correct (in my case anyway) we have two interconnected cluster switches, I think it's because we hooked up two cluster ports to the same switch.... We are in the process of migrating to a new cluster pair, so we don't want to investigate it further because the clustering works __ But I would suggest to check that you have one cluster cable from each host in each of your cluster switches... /Heino D. 17.06.2020 14.01 skrev "Toasters på vegne af Alexander Griesser" <toasters-bounces(a)teaparty.net på vegne af AGriesser(a)anexia-it.com<mailto:toasters-bounces@teaparty.net%20på%20vegne%20af%20AGriesser@anexia-it.com>>: All cluster ports up here: CLUSTER::> net int show -role cluster (network interface show) Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- Cluster Node1_clus1 up/up 169.254.101.103/16 node1 e0a true Node1_clus2 up/up 169.254.210.167/16 node1 e0b true Node2_clus1 up/up 169.254.44.143/16 node2 e0a true Node2_clus2 up/up 169.254.161.155/16 node2 e0b true Node3_clus1 up/up 169.254.15.190/16 node3 e0a true Node3_clus2 up/up 169.254.223.100/16 node3 e0b true Node4_clus1 up/up 169.254.183.224/16 node4 e0a true node4_clus2 up/up 169.254.221.115/16 node4 e0b true 8 entries were displayed. CLUSTER::> net port show -broadcast-domain Cluster (network port show) Node: node1 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node2 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node3 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy Node: node4 Speed(Mbps) Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status --------- ------------ ---------------- ---- ---- ----------- -------- e0a Cluster Cluster up 9000 auto/10000 healthy e0b Cluster Cluster up 9000 auto/10000 healthy 8 entries were displayed. Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anexia…> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Ursprüngliche Nachricht----- Von: Jason Gorrie <jbgorrie(a)uwaterloo.ca<mailto:jbgorrie@uwaterloo.ca>> Gesendet: Mittwoch, 17. Juni 2020 13:54 An: Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>> Betreff: Re: CSM MismatchRemoteDevice Hi, I have pages of those on a newly expanded cluster (was 6 nodes, now 10 for a tech refresh). CDP is enabled all over, and “net device-discovery show” shows good data. Currently 9.5P12. I do have one of the ports down (bad cable, RMA taking 4+ days) so perhaps that is why? — Jason > On Jun 17, 2020, at 00:33, Alexander Griesser <AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com>> wrote: > > Hey toasters, > > anyone ever experienced such messages in the event log? Mines are getting flooded here. > It’s a 4-Node cluster (9.6P1) and someone forgot to enable CDP on two of the nodes, which (according to the syslog translator) might seem to be the reason for this issue. > > CLUSTER::> event log show > Time Node Severity Event > ------------------- ---------------- ------------- --------------------------- > 6/17/2020 06:28:18 node1 ERROR csm.mismatchRemoteDevice: CSM connection between source LIF 1012 and destination address 169.254.221.115 might not be optimal for session 0b05995fad05cdb0. The source is currently connected to CLUSTER-sw02 remote device and the destination is currently connected to - remote device. > > https://mysupport.netapp.com/site/bugs-online/syslog-translator/details?eve…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmysupport…> > > The corrective action in this link just says: > „Ensure that the Cisco Discover Protocol (CDP) is running on the nodes and switches. In addition, ensure that the cluster ports are up and the cluster LIFs are configured and hosted according to the suggested cluster configuration." > > I’ve enabled CDP now for all nodes, cluster ports are up and all the lifs are where they should be. > Do I need to restart this CSM service or something like that in order to retry CDP resolution and get rid of this message? > > Thanks, > > Alexander Griesser _______________________________________________ Toasters mailing list Toasters(a)teaparty.net<mailto:Toasters@teaparty.net> https://www.teaparty.net/mailman/listinfo/toasters<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.teapa…> _______________________________________________ Toasters mailing list Toasters(a)teaparty.net<mailto:Toasters@teaparty.net> https://www.teaparty.net/mailman/listinfo/toasters<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.teapa…>

1 0

CSM MismatchRemoteDevice
by Alexander Griesser 17 Jun '20

17 Jun '20

Hey toasters, anyone ever experienced such messages in the event log? Mines are getting flooded here. It's a 4-Node cluster (9.6P1) and someone forgot to enable CDP on two of the nodes, which (according to the syslog translator) might seem to be the reason for this issue. CLUSTER::> event log show Time Node Severity Event ------------------- ---------------- ------------- --------------------------- 6/17/2020 06:28:18 node1 ERROR csm.mismatchRemoteDevice: CSM connection between source LIF 1012 and destination address 169.254.221.115 might not be optimal for session 0b05995fad05cdb0. The source is currently connected to CLUSTER-sw02 remote device and the destination is currently connected to - remote device. https://mysupport.netapp.com/site/bugs-online/syslog-translator/details?eve… The corrective action in this link just says: "Ensure that the Cisco Discover Protocol (CDP) is running on the nodes and switches. In addition, ensure that the cluster ports are up and the cluster LIFs are configured and hosted according to the suggested cluster configuration." I've enabled CDP now for all nodes, cluster ports are up and all the lifs are where they should be. Do I need to restart this CSM service or something like that in order to retry CDP resolution and get rid of this message? Thanks, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)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

1 0

Re:
by Joseph Zoda 12 Jun '20

12 Jun '20

Quick and simple answer -- The AFF systems and ONTAP takes care of it all for you.- most of the settings you need are on by default. On Fri, Jun 12, 2020 at 10:02 AM SE via Toasters <toasters(a)www.teaparty.net> wrote: > > > > ---------- Forwarded message ---------- > From: SE <s.eno(a)me.com> > To: toasters(a)teaparty.net > Cc: > Bcc: > Date: Fri, 12 Jun 2020 13:51:56 -0000 > Subject: dedpe: scheduled background vs. inline > Hi, > > I'm pretty sure this discussion has happened here in the past, but as I > migrate our data from spinning disks to AFFs, do I really need to enable a > scheduled background dedupe any longer? Will inline compression and dedupe > provide all the space savings possible? > > > > > > ---------- Forwarded message ---------- > From: SE via Toasters <toasters(a)www.teaparty.net> > To: toasters(a)teaparty.net > Cc: > Bcc: > Date: Fri, 12 Jun 2020 14:52:03 +0100 > Subject: > _______________________________________________ > Toasters mailing list > Toasters(a)www.teaparty.net > https://www.teaparty.net/mailman/listinfo/toasters -- Joe Zoda Infrastructure & Systems Support Division of Information Technology The School District of Palm Beach County 3300 Forest Hill Blvd., Suite B-332 West Palm Beach, FL 33406 joseph.zoda(a)palmbeachschools.org (561) 649-6810 http://www.PalmBeachSchools.org <http://www.palmbeachschools.org/> -- *Disclaimer: *Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing.

1 0

dedpe: scheduled background vs. inline
by SE 12 Jun '20

12 Jun '20

Hi, I'm pretty sure this discussion has happened here in the past, but as I migrate our data from spinning disks to AFFs, do I really need to enable a scheduled background dedupe any longer? Will inline compression and dedupe provide all the space savings possible?

1 0

nfs4_setfacl - Failed setxattr operation: Invalid argument
by Scott Classen 05 Jun '20

05 Jun '20

Hello fellow toasters, I’m deep into the NFSv4 wormhole and flailing miserably. Any help or advice would be greatly appreciated. I am exporting an NFSv4.1 volume from our filer (9.6P6). I can mount the volume on a CentOS7 client. I can make directories as root and chown them to a user in our LDAP directory. I can see the ACL with nfs4_getfacl, but I cannot set/edit the ACLs with nfs4_setfacl. I’ve read both of Justin Parisi’s TRs (TR-4835 - How to Configure LDAP in ONTAP, TR-4067 NFS Best Practice and Implementation Guide) so I think I’ve done everything correctly. I’ve configured both the NetApp and the client to talk to the same OpenLDAP server. Here are some relevant diagnostics: # on the client: [root@als-enable ~]# nfsstat -m /als/BL-831/data from ae10g-1:/BL831/ISPYB Flags: rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.40.38,local_lock=none,addr=192.168.40.100 [root@als-enable ~]# nfs4_getfacl /als/BL-831/data/TEST/ # file: /als/BL-831/data/TEST/ A:d:nobody:rwaDxtTnNcCy A::OWNER@:rwaDxtTnNcCy A:g:GROUP@:rxtncy A::EVERYONE@:rxtncy [root@als-enable ~]# nfs4_setfacl -a A::classen@als-enable.bl1231.als.lbl.gov:rwaDxtTnNcCy /als/BL-831/data/TEST Failed setxattr operation: Invalid argument [root@als-enable ~]# nfs4_setfacl -a A::classen@ALS-ENABLE.BL1231.ALS.LBL.GOV:rwaDxtTnNcCy /als/BL-831/data/TEST Failed setxattr operation: Invalid argument I think nfsid mapping is working. [root@als-enable ~]# nfsidmap -l 4 .id_resolver keys found: gid:root@als-enable.bl1231.als.lbl.gov uid:root@als-enable.bl1231.als.lbl.gov gid:staff@als-enable.bl1231.als.lbl.gov uid:classen@als-enable.bl1231.als.lbl.gov on the filer: sibyls2::*> vserver nfs show -vserver als-enable-ds1 -fields v4.1-acl,v4-id-domain,v4.0-acl vserver v4.0-acl v4-id-domain v4.1-acl -------------- -------- ----------------------------- -------- als-enable-ds1 enabled als-enable.bl1231.als.lbl.gov enabled sibyls2::*> vserver services name-service ns-switch show -vserver als-enable-ds1 Source Vserver Database Order --------------- ------------ --------- als-enable-ds1 hosts files, dns als-enable-ds1 group files, ldap als-enable-ds1 passwd files, ldap als-enable-ds1 netgroup files als-enable-ds1 namemap files, ldap sibyls2::*> vserver services name-service ldap client show -client-config ae-ldap Vserver: als-enable-ds1 Client Configuration Name: ae-ldap LDAP Server List: 192.168.40.38 (DEPRECATED)-LDAP Server List: - Active Directory Domain: - Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: false Schema Template: RFC-2307 LDAP Server Port: 389 Query Timeout (sec): 3 Minimum Bind Authentication Level: anonymous Bind DN (User): cn=ldapadmin,dc=als-enable,dc=als,dc=lbl,dc=gov Base DN: dc=als-enable,dc=als,dc=lbl,dc=gov Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: true Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree Client Session Security: none LDAP Referral Chasing: false Group Membership Filter: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Scott Classen, Ph.D. ALS-ENABLE TomAlberTron Beamline 8.3.1 SIBYLS Beamline 12.3.1 Advanced Light Source Lawrence Berkeley National Laboratory 1 Cyclotron Rd MS6R2100 Berkeley, CA 94720 mobile 510.206.4418 desk 510.495.2697 beamline 510.495.2134 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 3

lun size question
by John Stoffel 07 May '20

07 May '20

>>>>> "Iluhes" == Iluhes via Toasters <toasters(a)teaparty.net> writes: Iluhes> Thanks in advance Iluhes> How can this be? ONTAP, 9.3, size-used is larger than defined size Iluhes> vserver path size space-reserve Iluhes> size-used Iluhes> -------------- ------------------------------------------------------ ------- ------------- Iluhes> --------- Iluhes> vserver1 /vol/lun1/lun1 300.0GB disabled 301.2GB Iluhes> Fractional Reserve: 0% Iluhes> Space Reserved for Snapshot Copies: 0% Iluhes> Snapshot Reserve Used: 0% Probably because there's some amount of overhead. Can you post the exact command you used to show the above info. And maybe the volume info as well? John

1 0

Lun used size issue : size-used is larger than defined size
by Iluhes 06 May '20

06 May '20

Thanks in advance How can this be? ONTAP, 9.3, size-used is larger than defined size vserver path size space-reserve size-used-------------- ------------------------------------------------------ ------- ------------- ---------vserver1 /vol/lun1/lun1 300.0GB disabled 301.2GB Fractional Reserve: 0% Space Reserved for Snapshot Copies: 0% Snapshot Reserve Used: 0%

1 0

NetApp Filer FAS2520 and LACP --->>> replace network stack!
by Andrew Hancock 10 Mar '20

10 Mar '20

Long story but the current Dell Storage Switches have a fault, jumbo frames has failed due to ASIC issues. (confirmed by Dell). We've new Dell Storage switches to replace the two in the datacentre, BUT the entire infrastructure runs through these storage switches. We are trying to decide if we can do this without downtime although risky. The new Dell Storage switches have been tested and jumbo frames is indeed working. Currently Filer is running 8.2.3.7-mode (yes we know old! Flame retardant under-crackers on!), both heads are configured LACP into both switches on the stack Head A e0c - switch 1 e0d - switch 2 e0e - switch 1 e0f - switch 1 Head B e0c - switch 2 e0d - switch 1 e0e - switch 2 e0f - switch 1 Both Heads are in use, with volumes and NFS exports. Failover has been configured properly e.g. we can lose switch 1 or 2 (not at the same time) and service is still available. (just writing this I've had a thought!). We need to replace switch 1 and switch 2 above with switch 1a and switch 2a..... I did wonder if we removed all cables from switch 1, and put them in switch 1a, would this work.... but the LAG would disappear from the Stack.... and when we remove all cables from Switch 2 to Switch 2a, would break.... Is the simplest option just to shutdown the DC and rip and remove. Does failing over the heads help me here, e.g. take over Head A, so all is running on Head B..... Or maybe it cannot be avoided but to shutdown all the VMware vSphere. The more I think about this, I still think the safest is to arrange downtime. Useful Comments ? Thanks Andrew

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters