toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

v-series lun ownership
by Svein Harang 18 Jun '14

18 Jun '14

Hi everybody, I came across a strange problem today, and all the well-meaning people on google and netapp community could not provide an answer as far as I could see. Nutshell: New environment, first v-series, fabric metro cluster. After assigning the disks wrongly the first time (missing -p <pool>) I’ve tried "disk assign <disk_id> -o unowned ” without luck, I did a "disk remove_ownership”. It worked, sort of. There is one LUN left, which both controllers claim that the other controller own. Since the controllers can’t unown luns they don’t own, I am finding myself in a bit of a pickle. Has anyone come across this situation before? -- Sincerely / Mvh Svein Harang <sh(a)basefarm.com> +47 4000 4200 Direct: +47 417 36 019

3 2

AUTO: Markus Schlegel ist außer Haus bis 22.06.2014 / Markus Schlegel is out of office until 22/6/2014
by Markus.Schlegel＠roto-frank.com 17 Jun '14

17 Jun '14

Guten Tag, ich bin ab 16.06.2014 nicht im Büro. Ich kehre zurück am 23.06.2014. Bitte beachten Sie den Feiertag am: 19.06.2014 Mit freundlichen Grüßen Markus Schlegel Dear Sir / Madam, I will be out of the office on 16/6/2014 and will return on 23/6/2014. Please take note of the public holiday on: 19/06/2014 Kind regards Markus Schlegel Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "v-series lun ownership" gesendet am 18/6/2014 0:13:34. Sie erhalten keine weiteren Benachrichtigungen, während diese Person abwesend ist. Roto Frank AG Wilhelm-Frank-Platz 1 . D-70771 Leinfelden-Echterdingen . Telefon +49 711 7598 0 Sitz der Gesellschaft: Leinfelden-Echterdingen . Amtsgericht: Stuttgart . HRB 222 698 . Ust-IdNr.: DE147843524 Aufsichtsrat: Dr. Michael Stahl (Vorsitzender) Vorstand: Dr. Eckhard Keill (Vorsitzender), Leonhard Braig, Christoph Hugenberg, Michael Stangier

1 0

wafltop / wafl scan status
by Will.Burchell＠skanska.co.uk 17 Jun '14

17 Jun '14

1 0

wafl scan status / Wafltop
by Will.Burchell＠skanska.co.uk 17 Jun '14

17 Jun '14

Hello I attach a wafltop output run for 10 minutes. We are experiencing a fair amount of CPU contention and latency. Does anyone have any input on the below? I also show a wafl scan status which shows there is a lot of activity. Is that normal? wafltop stop CPU Utilization Percent Application Total STRIPE VOL_LOG VOL_VBN VBN VOL AGGR_VBN AGGR SERIAL XCleaner ----------- -------- -------- -------- -------- -------- -------- -------- -------- -------- ------- aggrsata2:SV_L_LUN_VOL0199:other:_WAFL_BACKDOOR: 15 0 0 0 0 0 0 0 15 0 other:other:other:FREE_CACHE_REFILL: 8 5 0 3 0 0 0 0 0 0 aggrsata2:SV_L_LUN_VOL0199:scanner:_WAFL_BACKDOOR: 5 0 0 0 0 0 0 0 5 0 other:other:other:RAIDIO_READ_DONE: 5 4 0 1 0 0 0 0 0 0 aggrvm:L_NFS_VOL0178:nfsv3:WAFL_WRITE: 4 4 0 0 0 0 0 0 0 0 other:other:other:WAFL_WRITE_DONE: 4 4 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0176:nfsv3:WAFL_READ: 3 3 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_WRITE: 3 3 0 0 0 0 0 0 0 0 aggrsata1:L_LUN_VOL0198:iscsi:WAFL_READ: 3 3 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0176:nfsv3:WAFL_WRITE: 3 3 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0177:nfsv3:WAFL_WRITE: 3 3 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_READ: 2 2 0 0 0 0 0 0 0 0 aggrsata1:L_LUN_VOL0198:iscsi:WAFL_WRITE: 2 2 0 0 0 0 0 0 0 0 aggrsata2:SV_L_LUN_VOL0198:scanner:_WAFL_BACKDOOR: 2 0 0 0 0 0 0 0 2 0 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_READ: 2 2 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_WRITE: 2 2 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0161:nfsv3:WAFL_WRITE: 1 1 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0174:nfsv3:WAFL_WRITE: 1 1 0 0 0 0 0 0 0 0 aggrvm::walloc:WAFL_BLKFREE_PVOL_CO: 1 0 0 0 0 0 1 0 0 0 other:other:other:WAFFINITY_NVLOG_COMP: 1 1 0 0 0 0 0 0 0 0 CPU Time us Application Total STRIPE VOL_LOG VOL_VBN VBN VOL AGGR_VBN AGGR SERIAL XCleaner ----------- -------- -------- -------- -------- -------- -------- -------- -------- -------- ------- aggrsata2:L_LUN_VOL0199:file i/o:WAFL_LOOKUP: 46164 0 0 0 0 0 0 0 46164 0 aggr0:vol0:file i/o:WAFL_LOOKUP: 33469 0 0 0 0 0 0 0 33469 0 aggr0:vol0:file i/o:WAFL_READDIR: 31339 0 0 0 0 0 0 0 31339 0 aggrsata1::file i/o:WAFL_LOOKUP: 4725 0 0 0 0 0 0 0 4725 0 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_READ: 4479 4349 130 0 0 0 0 0 0 0 aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_GETATTR: 3639 3639 0 0 0 0 0 0 0 0 aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_READ: 2397 1635 0 0 0 0 0 0 762 0 aggrsata1:L_LUN_VOL0201:iscsi:WAFL_READ: 2252 2191 55 0 0 0 0 0 6 0 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_READDIR: 1650 1628 22 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0174:nfsv3:WAFL_READ: 1542 1514 28 0 0 0 0 0 0 0 aggrvm:P_NFS_WPF0160:nfsv3:WAFL_DOACCESS: 1525 1525 0 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0161:nfsv3:WAFL_READ: 1520 1497 23 0 0 0 0 0 0 0 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_READ: 1480 1441 39 0 0 0 0 0 0 0 aggrvm:L_NFS_VOL0158:nfsv3:WAFL_READ: 1378 1355 23 0 0 0 0 0 0 0 aggr0:vol0:spinvfs:WAFL_READ: 1296 1289 7 0 0 0 0 0 0 0 aggrsata2:L_LUN_VOL0199:file i/o:WAFL_READ: 1283 900 0 0 0 357 0 0 26 0 aggrvm:L_NFS_VOL0181:nfsv3:WAFL_READ: 1270 1263 7 0 0 0 0 0 0 0 aggrvm:L_LUN_VOL0152:iscsi:WAFL_READ: 1234 1213 21 0 0 0 0 0 0 0 aggr0:vol0:file i/o:WAFL_READ: 1198 1189 1 0 0 0 0 0 8 0 aggrsata2:SV_L_LUN_VOL0199:file i/o:WAFL_READ: 1195 791 0 0 0 0 0 0 404 0 Latency Application Latency ms ----------- ---------- aggrvm:L_NFS_VOL0180:nfsv3:WAFL_SETATTR: 936.000 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_READ: 13.501 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_READ: 10.962 aggrvm:P_NFS_WPF0160:nfsv3:WAFL_READ: 9.148 aggrvm:L_NFS_VOL0180:nfsv3:WAFL_READ: 8.713 aggrvm:L_NFS_VOL0181:nfsv3:WAFL_READ: 8.205 aggrsata1:L_LUN_VOL0198:iscsi:WAFL_READ: 8.082 aggrvm:L_NFS_VOL0161:nfsv3:WAFL_READ: 7.525 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_READDIR: 6.000 aggrvm:L_NFS_VOL0177:nfsv3:WAFL_READ: 5.825 aggrvm:L_NFS_VOL0180:nfsv3:WAFL_LOOKUP: 5.000 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_READDIR: 5.000 aggrvm:L_NFS_VOL0158:nfsv3:WAFL_READ: 4.926 aggrvm:L_NFS_VOL0178:nfsv3:WAFL_READ: 4.775 aggrvm:L_NFS_VOL0174:nfsv3:WAFL_GETATTR: 4.666 aggr0:vol0:spinvfs:WAFL_READ: 3.250 aggrsata1:L_LUN_VOL0201:iscsi:WAFL_READ: 3.111 aggrvm:P_NFS_WPF0160:nfsv3:WAFL_STATFS: 3.000 aggrsata1:L_LUN_VOL0200:iscsi:WAFL_WRITE: 2.435 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_READ: 2.289 Application System Latency ms ----------- ----------------- aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_WRITE: 21.786 aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_READ: 21.000 aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_GETATTR: 8.000 aggrsata1:L_LUN_VOL0198:file i/o:WAFL_READ: 4.454 aggrvm:L_NFS_VOL0158:file i/o:WAFL_WRITE: 4.000 aggrsata2:L_LUN_VOL0199:file i/o:WAFL_READ: 3.333 aggrvm:L_NFS_VOL0180:file i/o:WAFL_WRITE: 3.261 aggrsata1:L_LUN_VOL0198:file i/o:WAFL_VDISK_SETTYPE: 3.000 aggrvm:L_NFS_VOL0224:file i/o:WAFL_WRITE: 3.000 aggrvm:L_NFS_VOL0177:file i/o:WAFL_WRITE: 2.245 aggrvm:L_NFS_VOL0183:file i/o:WAFL_WRITE: 2.220 aggrvm:L_NFS_VOL0176:file i/o:WAFL_WRITE: 2.201 aggrvm:L_NFS_VOL0179:file i/o:WAFL_WRITE: 2.136 aggrvm:L_NFS_VOL0181:file i/o:WAFL_WRITE: 2.050 aggrsata2:SV_L_LUN_VOL0199:file i/o:WAFL_GETATTR: 1.750 aggrsata2:L_LUN_VOL0199:file i/o:WAFL_LOOKUP: 1.500 aggrsata2:L_LUN_VOL0199:file i/o:WAFL_VDISK_SETTYPE: 1.444 aggrsata1:L_LUN_VOL0198:file i/o:WAFL_STATFS: 1.000 aggrsata1::file i/o:WAFL_LOOKUP: 1.000 aggrvm:L_NFS_VOL0178:file i/o:WAFL_STATFS: 1.000 I/O utilization ---------MB Read---------- ---------MB Write--------- --------IOs Read---------- --------IOs Write--------- Application MB Total Standard PAM Hybrid Standard PAM Hybrid Standard PAM Hybrid Standard PAM Hybrid ----------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- aggrsata1:L_LUN_VOL0198:iscsi:WAFL_READ: 17124 15503 1621 0 0 0 0 412113 88557 0 0 0 0 other:other:other:FREE_CACHE_REFILL: 13732 0 0 0 0 13732 0 0 0 0 0 54917 0 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_READ: 10348 9956 392 0 0 0 0 483841 58184 0 0 0 0 aggrvm:L_NFS_VOL0176:nfsv3:WAFL_READ: 7954 6989 965 0 0 0 0 407363 124931 0 0 0 0 aggrsata1:L_LUN_VOL0198:snapmirror:WAFL_SNAP_DIFF: 7523 6052 1471 0 0 0 0 249428 54191 0 0 0 0 other:other:other:WAFFINITY_RA_STRIPE_: 7432 7339 93 0 0 0 0 159291 4544 0 0 0 0 aggrvm:L_NFS_VOL0176:nfsv3:WAFL_WRITE: 7288 384 152 0 6752 0 0 98462 38971 0 0 0 0 aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_WRITE: 6759 148 40 0 6571 0 0 37781 10251 0 0 0 0 aggrsata1:L_LUN_VOL0198:iscsi:WAFL_WRITE: 6726 65 112 0 6549 0 0 16507 28706 0 0 0 0 aggrvm:L_NFS_VOL0177:nfsv3:WAFL_WRITE: 5538 426 102 0 5010 0 0 109134 26076 0 0 0 0 aggrvm:L_NFS_VOL0178:nfsv3:WAFL_WRITE: 5444 442 171 0 4831 0 0 113018 43797 0 0 0 0 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_WRITE: 5298 419 125 0 4754 0 0 107294 32047 0 0 0 0 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_WRITE: 4153 381 92 0 3680 0 0 97639 23545 0 0 0 0 aggrvm:L_NFS_VOL0174:nfsv3:WAFL_WRITE: 3748 84 32 0 3632 0 0 21436 8233 0 0 0 0 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_READ: 3692 3482 210 0 0 0 0 90262 10488 0 0 0 0 aggrvm:L_NFS_VOL0180:nfsv3:WAFL_WRITE: 3367 205 85 0 3077 0 0 52391 21642 0 0 0 0 other:other:other:WAFL_WRITE_DONE: 3325 0 0 0 0 3325 0 0 0 0 0 13309 0 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_WRITE: 2738 25 15 0 2698 0 0 6364 3849 0 0 0 0 aggrsata1:L_LUN_VOL0198:snapmirror:WAFL_SNAP_READ: 2340 1838 502 0 0 0 0 356929 96469 0 0 0 0 aggrsata2:SV_L_LUN_VOL0199:other:_WAFL_BACKDOOR: 2265 12 2241 0 12 0 0 3029 536488 0 0 0 0 NVLog Utilization Application NVLog in KB/s ----------- ------------------ aggrsata2:SV_L_LUN_VOL0198:file i/o:WAFL_WRITE: 10036 aggrsata1:L_LUN_VOL0198:iscsi:WAFL_WRITE: 9692 aggrvm:L_NFS_VOL0176:nfsv3:WAFL_WRITE: 9452 aggrvm:L_NFS_VOL0177:nfsv3:WAFL_WRITE: 7462 aggrvm:L_NFS_VOL0183:nfsv3:WAFL_WRITE: 7159 aggrvm:L_NFS_VOL0178:nfsv3:WAFL_WRITE: 7140 aggrsata2:L_LUN_VOL0199:iscsi:WAFL_WRITE: 7083 aggrvm:L_NFS_VOL0174:nfsv3:WAFL_WRITE: 5422 aggrvm:L_NFS_VOL0179:nfsv3:WAFL_WRITE: 5358 aggrvm:L_NFS_VOL0180:nfsv3:WAFL_WRITE: 4222 aggrvm:L_NFS_VOL0182:nfsv3:WAFL_WRITE: 2698 aggrvm:L_NFS_VOL0161:nfsv3:WAFL_WRITE: 1944 aggrvm:L_NFS_VOL0181:nfsv3:WAFL_WRITE: 1647 aggrvm:P_NFS_WPF0160:nfsv3:WAFL_WRITE: 842 aggrvm:L_NFS_VOL0158:nfsv3:WAFL_WRITE: 351 aggrvm:L_NFS_VOL0176:file i/o:WAFL_WRITE: 70 aggrvm:L_NFS_VOL0177:file i/o:WAFL_WRITE: 53 aggrvm:L_NFS_VOL0183:file i/o:WAFL_WRITE: 50 aggrvm:L_NFS_VOL0179:file i/o:WAFL_WRITE: 42 aggrvm:L_NFS_VOL0180:file i/o:WAFL_WRITE: 31 Application NVLog_b2b in KB/s ----------- ---------------------- wafl scan status Volume vol0: Scan id Type of scan progress 11 active bitmap rearrangement fbn 3263 of 3971 w/ max_chain_len 3 Volume L_NFS_VOL0224: Scan id Type of scan progress 12 active bitmap rearrangement fbn 5565 of 6853 w/ max_chain_len 3 Volume L_LUN_VOL0152: Scan id Type of scan progress 13 active bitmap rearrangement fbn 1283 of 5577 w/ max_chain_len 3 35 container block reclamation block 147 of 5578 (fbn 147) Volume L_NFS_VOL0158: Scan id Type of scan progress 14 active bitmap rearrangement fbn 43778 of 45689 w/ max_chain_len 3 Volume P_NFS_VSW0159: Scan id Type of scan progress 15 active bitmap rearrangement fbn 23963 of 36551 w/ max_chain_len 3 Volume P_NFS_WPF0160: Scan id Type of scan progress 16 active bitmap rearrangement fbn 5242 of 36551 w/ max_chain_len 3 Volume L_NFS_VOL0161: Scan id Type of scan progress 17 active bitmap rearrangement fbn 44716 of 45689 w/ max_chain_len 3 3431 snap create summary update block 7992 of 45690 (fbn 29116) 3434 blocks used summary update block 4284 of 45690 (fbn 14381) Volume L_NFS_VOL0172: Scan id Type of scan progress 18 active bitmap rearrangement fbn 16466 of 27413 w/ max_chain_len 3 Volume L_NFS_VOL0174: Scan id Type of scan progress 19 active bitmap rearrangement fbn 22931 of 25129 w/ max_chain_len 3 Volume L_NFS_VOL0176: Scan id Type of scan progress 20 active bitmap rearrangement fbn 29215 of 54827 w/ max_chain_len 3 Volume L_NFS_VOL0177: Scan id Type of scan progress 21 active bitmap rearrangement fbn 32845 of 54827 w/ max_chain_len 3 Volume L_NFS_VOL0178: Scan id Type of scan progress 22 active bitmap rearrangement fbn 28871 of 54827 w/ max_chain_len 3 Volume L_NFS_VOL0179: Scan id Type of scan progress 23 active bitmap rearrangement fbn 12076 of 36551 w/ max_chain_len 3 Volume L_NFS_VOL0180: Scan id Type of scan progress 24 active bitmap rearrangement fbn 13106 of 36551 w/ max_chain_len 3 Volume L_NFS_VOL0181: Scan id Type of scan progress 25 active bitmap rearrangement fbn 12588 of 36551 w/ max_chain_len 3 Volume L_NFS_VOL0182: Scan id Type of scan progress 26 active bitmap rearrangement fbn 2419 of 4461 w/ max_chain_len 3 Volume L_NFS_VOL0183: Scan id Type of scan progress 27 active bitmap rearrangement fbn 63137 of 63965 w/ max_chain_len 3 Volume SV_L_NFS_VOL0178: Scan id Type of scan progress 28 active bitmap rearrangement fbn 39988 of 54827 w/ max_chain_len 3 Volume L_LUN_VOL0198: Scan id Type of scan progress 32 active bitmap rearrangement fbn 60526 of 68534 w/ max_chain_len 3 3443 snap create summary update block 4897 of 68535 (fbn 4437) Volume L_LUN_VOL0200: Scan id Type of scan progress 34 active bitmap rearrangement fbn 3607 of 54827 w/ max_chain_len 3 Volume L_LUN_VOL0201: Scan id Type of scan progress 52 active bitmap rearrangement fbn 12935 of 54827 w/ max_chain_len 3 Volume SV_L_NFS_VOL0161: Scan id Type of scan progress 53 active bitmap rearrangement fbn 44350 of 63965 w/ max_chain_len 3 Volume SV_L_NFS_VOL0177: Scan id Type of scan progress 56 active bitmap rearrangement fbn 7859 of 61680 w/ max_chain_len 3 Volume SV_L_NFS_VOL0181: Scan id Type of scan progress 57 active bitmap rearrangement fbn 1550 of 45689 w/ max_chain_len 3 Volume SV_L_NFS_VOL0202: Scan id Type of scan progress 60 active bitmap rearrangement fbn 13923 of 31982 w/ max_chain_len 3 Volume SV_L_NFS_VOL0180: Scan id Type of scan progress 62 active bitmap rearrangement fbn 35314 of 50258 w/ max_chain_len 3 Volume SV_L_NFS_VOL0172: Scan id Type of scan progress 63 active bitmap rearrangement fbn 763 of 2230 w/ max_chain_len 3 Volume L_NFS_VOL0202: Scan id Type of scan progress 65 active bitmap rearrangement fbn 9076 of 20560 w/ max_chain_len 3 Volume SV_L_NFS_VOL0158: Scan id Type of scan progress 66 active bitmap rearrangement fbn 33221 of 73103 w/ max_chain_len 3 Volume SV_L_LUN_VOL0198: Scan id Type of scan progress 68 active bitmap rearrangement fbn 200707 of 319142 w/ max_chain_len 3 3421 blocks used summary update block 120530 of 319143 (fbn 226694) 3422 snap create summary update block 126523 of 319143 (fbn 266270) Volume SV_L_LUN_VOL0199: Scan id Type of scan progress 70 active bitmap rearrangement fbn 244335 of 319142 w/ max_chain_len 3 3408 snap create summary update block 125303 of 319143 (fbn 220403) 3423 blocks used summary update block 120064 of 319143 (fbn 220612) Volume L_LUN_VOL0199: Scan id Type of scan progress 3325 active bitmap rearrangement fbn 32437 of 54827 w/ max_chain_len 3 3444 snap create summary update block 283 of 54828 (fbn 4437)

1 0

High CPU VM misalignment confusion
by Will.Burchell＠skanska.co.uk 16 Jun '14

16 Jun '14

Hello. I am hoping you can guide me in the right direction We have been experiencing very high CPU load on a 7-mode HA pair of 3270 controllers run 8.1.3P2 We have worked with netapp support on these issues and they note our workload is very high on one controller (where we run our VMware setup from) We also have so called "bad practice" where we are running our exchange ISCSI LUNs on SATA with logs and dbs on the same aggregate (currently separating this out as I type) I have been told by support we have VMDK misalignment, however I spent a long time a few months ago resolving this firstly by using the VSC tool to confirm the problem and then fixing it with a combination of MBRALIGN and VMware converter as a V2V process The support guy tells me he seems misalignment when he runs nfsstat -d but MBRSCAN shows these are aligned. What is going on here? Trying to reduce our CPU and IO burden but getting conflicting information. Finally I think we should look to upgrade to 8.1.4P2 to remove some bugs? We would consider 8.2.x but I don't think we can as we run Exchange 2010 (using SME 6.x etc) Thanks in advance William

5 16

Fabrica metro cluster with ds14mk4 and ds2246
by Milazzo Giacomo 16 Jun '14

16 Jun '14

Hi everybody Can fc path coming fm atto bridges share the same iinitiators on the fas used also by the fc disk loop? Following an head swap fm 3160 to 8040 with 8.2.1 I've zoned a store zone with the fc port used by atto and the 4 initiators on 8040. Exactly as done with port coming from fc loops The fas starts to message a lot of timeouts and errors related to the sas disks then panic Of course the fc loops are on fc ports forced at 4 Gbps while the at to negotiate at 8. Can be this the.issue? Should I.have to.use a separate hba just for sas and another one for fc disk loops? Reading docs this don't seem a requisite. Regards Inviato da Samsung Mobile

3 6

snapmirror, flexclone and inconsistent volumes
by David Byte 13 Jun '14

13 Jun '14

Well, this is a fun one. I do some work for a shop from time to time that has a filer that is no longer under a maintenance contract. The other day, one of the guys saw condensation on the light fixtures and turned off the A/C for the room and left for the day. Needless to say, bad juju and a triple disk RAID failure.. So here we are today, I've managed to get the RAID back online (disk unfail, WAFL_check/wafliron) and have purchased some extra drives to replace the now non-existent spares pool. Here's the challenge. The primary data volumes were replicated off site on a nightly basis with snapmirror. There is a flexclone of one of the volumes where important data had been updated (don't ask) that had not been replicated. I have all the volumes online, but get errors on the console about inconsistencies when reading from all of them (there were severe media errors.) What I want to know... Is there some way to use snapmirror to bring the backing volumes back to a consistent state (including the snapshot backing the flexclone) and hopefully save their flexclone volume as well? Thoughts?'

1 0

Need Help - 100% ANY CPU
by Kalra, Manish 11 Jun '14

11 Jun '14

Hey Guys, I had an issue with one of my 7-mode filers (ONTAP 8.1.2) where all of the CPUs were 100% and there was no indication of any volume doing more IOs. It took down everything on the filer and DBs crashed. During the issue the output of wafltop show -v cpu: aggr_sas02_64:prod_volume1:nfsv3:WAFL_READDIR: consuming 300% CPU When we checked on the hosts mounting this volume we found out that there was one volume "deploy01" which was migrated to new c-mode filer but the mount was not fixed on those 3 hosts. So the NFS stack on those 3 servers was hung. The question now we have is: 1. Why would NFS stale on 3 hosts took down the filer? 2. Is there a BUG around this situation which someone has experienced before? Any help/clues would be greatly appreciated. Manish

1 0

Oracle Volumes and Compression
by Peta Thames 11 Jun '14

11 Jun '14

Hi, I've read that compression works well on volumes hosting Oracle DB data, but I haven't seen it in use anywhere in the wild yet. Is anyone using compression, and if so, what have been your experiences? Cheers, Peta

2 1

AW: FCP Ports operational down
by Alexander Griesser 09 Jun '14

09 Jun '14

I've done that several times so far and unfortunately it doesn't help... Any other ideas? If at least nothing obvious seems to be wrong, I think I'll open a support case on that issue. Alexander Griesser System-Administrator ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-320 Telefax: +43-5-0556-500 E-Mail: ag(a)anexia.at<mailto:ag@anexia.at> Web: http://www.anexia.at<http://www.anexia.at/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 Von: S Oda [mailto:soda@socal.rr.com] Gesendet: Montag, 09. Juni 2014 18:05 An: Alexander Griesser Betreff: Re: FCP Ports operational down Try stopping and starting the FCP service. On 6/9/14, 6:35 AM, Alexander Griesser wrote: Hi there, I'm having a hard time currently connecting my new FAS8020 to our existing fabric - the FCP ports just won't get online and I'm not sure where exactly the problem is and how to debug that since I'm more the NAS guy not having much practical experience with FCP configurations, so here's the deal for all of you who are wanting to help. FAS8020 Clustered Data Ontap 8.2.1 Brocade DS4900B Brocade Switchport: > portcfgshow 0 Area Number: 0 Speed Level: AUTO(HW) Fill Word: 0(Idle-Idle) AL_PA Offset 13: OFF Trunk Port ON Long Distance OFF VC Link Init OFF Locked L_Port OFF Locked G_Port OFF Disabled E_Port OFF Locked E_Port OFF ISL R_RDY Mode OFF RSCN Suppressed OFF Persistent Disable OFF LOS TOV enable OFF NPIV capability ON QOS E_Port OFF Port Auto Disable: OFF Mirror Port OFF F_Port Buffers OFF Fault Delay: 0(R_A_TOV) NPIV PP Limit: 126 > portshow 0 portIndex: 0 portName: portHealth: OFFLINE Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x1 PRESENT U_PORT LocalSwcFlags: 0x0 portType: 10.0 POD Port: Port is licensed portState: 2 Offline Protocol: FC portPhys: 4 No_Light portScn: 0 port generation number: 0 state transition count: 0 portId: 010000 portIfId: 4302100d portWwn: 20:00:00:05:1e:5b:f9:a3 portWwn of device(s) connected: Distance: normal portSpeed: N4Gbps LE domain: 0 FC Fastwrite: OFF Interrupts: 2 Link_failure: 0 Frjt: 0 Unknown: 0 Loss_of_sync: 0 Fbsy: 0 Lli: 2 Loss_of_sig: 2 Proc_rqrd: 5 Protocol_err: 0 Timed_out: 0 Invalid_word: 0 Rx_flushed: 0 Invalid_crc: 0 Tx_unavail: 0 Delim_err: 0 Free_buffer: 0 Address_err: 0 Overrun: 0 Lr_in: 0 Suspended: 0 Lr_out: 0 Parity_err: 0 Ols_in: 0 2_parity_err: 0 Ols_out: 0 CMI_bus_err: 0 Port part of other ADs: No FCP Adater on NetApp: Node: jetfire Adapter: 1b Description: Fibre Channel Target Adapter 1b (QLogic 8324 (8362), rev. 2, 16G) Physical Protocol: fibre-channel Maximum Speed: 16 Status: link not connected Substatus: ADAPTER UP Host Port Address: 0 Firmware Revision: 6.10.0 Data Link Rate (Gbit): 0 Fabric Established: false Connection Established: loop Mediatype: ptp Configured Speed: 4 Configured State: up Switch Port: : AFAIK, the 16Gbit/s adapter should be backwards compatible to 4Gbit/s, our switch only has 4Gbit/s but it supports NPIV which seems to be a requirement for running Clustered Data Ontap via FC. So, I have no idea what information I should provide upfront for someone who's wanting to help me through get through that, but I'm more than happy to send more info when requested. Thanks, Alexander Griesser System-Administrator ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-320 Telefax: +43-5-0556-500 E-Mail: ag(a)anexia.at<mailto:ag@anexia.at> Web: http://www.anexia.at<http://www.anexia.at/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 _______________________________________________ Toasters mailing list Toasters(a)teaparty.net<mailto:Toasters@teaparty.net> http://www.teaparty.net/mailman/listinfo/toasters

1 0

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