toasters

toasters@lists.teaparty.net

13520 discussions

FW: SV: Flaw with SATA disks - not suitable for deduplication environment
by Freeman, Larry 05 Jun '08

05 Jun '08

Hi Toasters, I found this post interesting so I polled some of our Engineering folks and this was the consensus opinion: This is not really a problem for any modern storage system. It is true that errors can develop over time - or even during the manufacture of disk drives. Every drive has built-in error correction codes that detect, and usually correct such a bit error. If the string of errors is too great to be handled by the ECC codes, the drive will report back that the sector is unreadable, at which point RAID algorithms will "fix" the error from the information stored on other sectors . Our RAID-DP means two drives can even have the same data in error, and we can still recover. Our SATA drives also use a checksum scheme for further protection - we utilize an additional portion of the drive as overhead to store checksums that move with the data through the system to insure what was written is returned to the application. In essence a third level of protection. This same type of protection against bits in error covers our FC drive systems. Mr Wendt is correct in indicating that dedupe (aka block sharing) could exacerbate any data corruption event. We take this seriously and believe that the extra steps NetApp has taken create one of the most reliable deduplication architectures in the industry. Regards, Larry Freeman NetApp From: "Karlsson Ulf Ibrahim :ULK" <ulk(a)forsmark.vattenfall.se> Date: June 5, 2008 4:42:22 AM PDT To: <toasters(a)mathworks.com> Subject: SV: Flaw with SATA disks - not suitable for deduplication environment NetApp's Raid-DP is the answer you're looking for. /Ulwur -----Ursprungligt meddelande----- Från: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] För Chong, Jenson Skickat: den 5 juni 2008 12:54 Till: toasters(a)mathworks.com Ämne: Flaw with SATA disks - not suitable for deduplication environment Hi, Anybody have insights on this article? Does our ONTAP "Lost Write Protection" address this issue? Regards, Jenson A bit of a flaw with SATA disk drives June 03, 2008 By Jerome Wendt Network World Asia High-capacity serial ATA (SATA) disk drives are now a mainstay in many storage systems and make it feasible for almost any company to obtain a storage system with terabytes of capacity at a reasonable cost. Yet these systems reveal a specific, known deficiency of SATA disk drives that demand companies exercise caution as to what environments they deploy these systems into. A minor flaw with SATA disk drives that high capacity storage systems expose is their bit error rate. Bit errors occur infrequently - about once for every 100 trillion bits. However RAID technology, which is normally used by storage systems to protect against data loss, does not detect if a specific bit on a SATA drive becomes unreadable. While this is normally not a problem on smaller systems, as storage systems add more capacity, the issue becomes more acute. On systems with more than 10TB of capacity the probability of a specific bit of data becoming unreadable is a distinct possibility. On systems with over 100TB, it becomes almost a certainty. So the question becomes: Does losing access to one bit of data really matter? Often, it doesn't unless one stores deduplicated data on these systems which is now the fastest growing trend in data storage. When data is deduplicated, the storage system's need to read every bit of data becomes paramount. The inability to access even a bit of data can result in multiple files becoming unreadable since they all may depend on a specific bit of data to complete their reconstruction. High capacity SATA-based storage systems are the answer to many companies' archiving and backup problems. But SATA bits can bite and using SATA drives to store large amounts of deduplicated data is not always the match made in heaven that vendors make them out to be. Jerome Wendt is the president and lead analyst at DCIG Inc. You may read his blogs at www.dciginc.com <http://www.dciginc.com/> .

1 0

RE: How to identify a hot disk
by Page, Jeremy 05 Jun '08

05 Jun '08

Thu Jun 5 10:06:02 EDT [gvr-array02: wafl.scan.layout.advise:info]: WAFL layout ratio for volume nfs2 is 4.01. A ratio of 1 is optimal. Based on your free space, 1.42 is expected. Would you say I need to do a reallocate? I'm not sure why this is so fragmented, this file system has never been more then 50% full, could A-SIS have something to do with it? Jeremy M. Page____________________ Systems Architect * email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274 ________________________________ From: Uddhav Regmi [mailto:uddhav.regmi@worldnet.att.net] Sent: Thursday, June 05, 2008 9:38 AM To: Page, Jeremy; toasters(a)mathworks.com Subject: RE: How to identify a hot disk hmmm very interesting.... looks like those are max out do wafl scan measure layout and see where you stand.... if needed do reallocate..... I have seen hundreds of cases where it helped a lot -uddhav From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Thursday, June 05, 2008 8:27 AM To: toasters(a)mathworks.com Subject: Re: How to identify a hot disk Not sure why but I have two disks that are maxed out while the rest are far lower utilization. What would cause this, the raid groups where created all at the same time, there are 10 disks per raid group and 3 groups in the aggragate. /aggr0/plex0/rg0: 1c.16 2 0.94 0.18 1.00 42250 0.49 12.18 1396 0.27 11.83 521 0.00 .... . 0.00 .... . 1c.32 6 2.56 0.49 1.00 104545 1.80 4.18 1323 0.27 11.83 634 0.00 .... . 0.00 .... . 1c.48 98 116.05 114.20 1.62 18481 1.53 4.24 1743 0.31 11.00 2649 0.00 .... . 0.00 .... . 1c.17 41 55.21 54.76 2.17 5697 0.27 20.17 1537 0.18 16.25 600 0.00 .... . 0.00 .... . 1c.33 49 72.07 71.62 1.84 4760 0.27 20.67 871 0.18 16.75 1239 0.00 .... . 0.00 .... . 1c.49 45 61.42 60.97 2.18 4047 0.22 23.00 913 0.22 14.40 931 0.00 .... . 0.00 .... . 1c.64 5 117.40 116.86 1.61 307 0.36 15.25 1336 0.18 18.00 319 0.00 .... . 0.00 .... . 1c.65 4 71.76 71.17 1.83 292 0.27 20.67 1298 0.31 10.43 370 0.00 .... . 0.00 .... . 1c.80 4 49.50 49.05 2.36 333 0.22 22.80 1333 0.22 14.60 712 0.00 .... . 0.00 .... . 1c.81 5 95.14 94.69 1.71 292 0.22 22.80 1325 0.22 14.60 548 0.00 .... . 0.00 .... . /aggr0/plex0/rg1: 1c.66 1 0.67 0.00 .... . 0.31 19.29 1311 0.36 10.50 238 0.00 .... . 0.00 .... . 1c.83 1 0.67 0.00 .... . 0.31 19.29 1415 0.36 10.50 190 0.00 .... . 0.00 .... . 1c.82 4 48.60 48.24 2.21 320 0.22 22.80 1553 0.13 21.33 234 0.00 .... . 0.00 .... . 1c.19 51 67.89 67.44 1.92 5315 0.22 22.80 1281 0.22 13.20 788 0.00 .... . 0.00 .... . 1c.18 55 72.75 72.34 1.90 4996 0.22 23.00 1122 0.18 16.00 1109 0.00 .... . 0.00 .... . 1c.35 30 36.10 35.52 2.67 3190 0.31 15.86 1802 0.27 11.33 588 0.00 .... . 0.00 .... . 1c.34 41 52.97 52.43 2.04 4207 0.31 16.29 1570 0.22 13.60 750 0.00 .... . 0.00 .... . 1c.51 100 119.82 119.46 1.57 25873 0.22 22.80 1588 0.13 21.33 2313 0.00 .... . 0.00 .... . 1c.50 59 72.03 71.44 1.83 7750 0.27 19.33 1233 0.31 10.86 1289 0.00 .... . 0.00 .... . 1c.67 4 94.60 94.15 1.68 279 0.18 24.50 1071 0.27 12.33 338 0.00 .... . 0.00 .... . /aggr0/plex0/rg2: 1c.85 1 0.94 0.00 .... . 0.54 12.00 1806 0.40 10.11 538 0.00 .... . 0.00 .... . 1c.84 1 0.94 0.00 .... . 0.54 12.00 1729 0.40 10.11 495 0.00 .... . 0.00 .... . 1c.21 47 67.40 66.90 1.86 4701 0.27 19.17 1452 0.22 14.20 845 0.00 .... . 0.00 .... . 1c.20 56 73.56 73.02 1.79 4866 0.18 25.50 1039 0.36 9.63 870 0.00 .... . 0.00 .... . 1c.37 51 68.79 68.21 1.76 6072 0.27 19.17 1174 0.31 11.43 988 0.00 .... . 0.00 .... . 1c.36 42 50.85 50.18 2.31 3807 0.40 12.78 1852 0.27 13.33 800 0.00 .... . 0.00 .... . 1c.53 59 75.85 75.18 1.86 5024 0.36 14.25 2237 0.31 10.43 493 0.00 .... . 0.00 .... . 1c.52 18 21.27 20.77 3.83 2205 0.27 19.17 1496 0.22 14.20 465 0.00 .... . 0.00 .... . 1c.69 5 71.76 71.00 1.96 296 0.40 12.78 2087 0.36 9.63 610 0.00 .... . 0.00 .... . 1c.68 5 71.58 71.13 1.84 352 0.22 23.60 1314 0.22 14.80 514 0.00 .... . 0.00 .... . This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

2 1

Persistant CIFS Share Across Logins
by Daniel Keisling 05 Jun '08

05 Jun '08

Greetings, I apologize for what could be a silly question, but I'm strictly in the storage/UNIX world. I've set up a CIFS share on my 3040 (v7.2.4) for a Windows 2003 server to mount so that an application can read and write data to it. The windows administrator says the share is not staying mapped because it is being disconnected when the user logs out. This particular application needs access to the share when no one is logged into the system. How does a Windows administrator keep a NetApp CIFS share mounted as as drive letter so that applications can use that share when no one is logged in? Many thanks, Daniel ______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.

8 7

Re: How to identify a hot disk
by Page, Jeremy 05 Jun '08

05 Jun '08

Not sure why but I have two disks that are maxed out while the rest are far lower utilization. What would cause this, the raid groups where created all at the same time, there are 10 disks per raid group and 3 groups in the aggragate. /aggr0/plex0/rg0: 1c.16 2 0.94 0.18 1.00 42250 0.49 12.18 1396 0.27 11.83 521 0.00 .... . 0.00 .... . 1c.32 6 2.56 0.49 1.00 104545 1.80 4.18 1323 0.27 11.83 634 0.00 .... . 0.00 .... . 1c.48 98 116.05 114.20 1.62 18481 1.53 4.24 1743 0.31 11.00 2649 0.00 .... . 0.00 .... . 1c.17 41 55.21 54.76 2.17 5697 0.27 20.17 1537 0.18 16.25 600 0.00 .... . 0.00 .... . 1c.33 49 72.07 71.62 1.84 4760 0.27 20.67 871 0.18 16.75 1239 0.00 .... . 0.00 .... . 1c.49 45 61.42 60.97 2.18 4047 0.22 23.00 913 0.22 14.40 931 0.00 .... . 0.00 .... . 1c.64 5 117.40 116.86 1.61 307 0.36 15.25 1336 0.18 18.00 319 0.00 .... . 0.00 .... . 1c.65 4 71.76 71.17 1.83 292 0.27 20.67 1298 0.31 10.43 370 0.00 .... . 0.00 .... . 1c.80 4 49.50 49.05 2.36 333 0.22 22.80 1333 0.22 14.60 712 0.00 .... . 0.00 .... . 1c.81 5 95.14 94.69 1.71 292 0.22 22.80 1325 0.22 14.60 548 0.00 .... . 0.00 .... . /aggr0/plex0/rg1: 1c.66 1 0.67 0.00 .... . 0.31 19.29 1311 0.36 10.50 238 0.00 .... . 0.00 .... . 1c.83 1 0.67 0.00 .... . 0.31 19.29 1415 0.36 10.50 190 0.00 .... . 0.00 .... . 1c.82 4 48.60 48.24 2.21 320 0.22 22.80 1553 0.13 21.33 234 0.00 .... . 0.00 .... . 1c.19 51 67.89 67.44 1.92 5315 0.22 22.80 1281 0.22 13.20 788 0.00 .... . 0.00 .... . 1c.18 55 72.75 72.34 1.90 4996 0.22 23.00 1122 0.18 16.00 1109 0.00 .... . 0.00 .... . 1c.35 30 36.10 35.52 2.67 3190 0.31 15.86 1802 0.27 11.33 588 0.00 .... . 0.00 .... . 1c.34 41 52.97 52.43 2.04 4207 0.31 16.29 1570 0.22 13.60 750 0.00 .... . 0.00 .... . 1c.51 100 119.82 119.46 1.57 25873 0.22 22.80 1588 0.13 21.33 2313 0.00 .... . 0.00 .... . 1c.50 59 72.03 71.44 1.83 7750 0.27 19.33 1233 0.31 10.86 1289 0.00 .... . 0.00 .... . 1c.67 4 94.60 94.15 1.68 279 0.18 24.50 1071 0.27 12.33 338 0.00 .... . 0.00 .... . /aggr0/plex0/rg2: 1c.85 1 0.94 0.00 .... . 0.54 12.00 1806 0.40 10.11 538 0.00 .... . 0.00 .... . 1c.84 1 0.94 0.00 .... . 0.54 12.00 1729 0.40 10.11 495 0.00 .... . 0.00 .... . 1c.21 47 67.40 66.90 1.86 4701 0.27 19.17 1452 0.22 14.20 845 0.00 .... . 0.00 .... . 1c.20 56 73.56 73.02 1.79 4866 0.18 25.50 1039 0.36 9.63 870 0.00 .... . 0.00 .... . 1c.37 51 68.79 68.21 1.76 6072 0.27 19.17 1174 0.31 11.43 988 0.00 .... . 0.00 .... . 1c.36 42 50.85 50.18 2.31 3807 0.40 12.78 1852 0.27 13.33 800 0.00 .... . 0.00 .... . 1c.53 59 75.85 75.18 1.86 5024 0.36 14.25 2237 0.31 10.43 493 0.00 .... . 0.00 .... . 1c.52 18 21.27 20.77 3.83 2205 0.27 19.17 1496 0.22 14.20 465 0.00 .... . 0.00 .... . 1c.69 5 71.76 71.00 1.96 296 0.40 12.78 2087 0.36 9.63 610 0.00 .... . 0.00 .... . 1c.68 5 71.58 71.13 1.84 352 0.22 23.60 1314 0.22 14.80 514 0.00 .... . 0.00 .... . This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

1 0

SV: Flaw with SATA disks - not suitable for deduplication environment
by Karlsson Ulf Ibrahim :ULK 05 Jun '08

05 Jun '08

NetApp's Raid-DP is the answer you're looking for. /Ulwur -----Ursprungligt meddelande----- Från: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] För Chong, Jenson Skickat: den 5 juni 2008 12:54 Till: toasters(a)mathworks.com Ämne: Flaw with SATA disks - not suitable for deduplication environment Hi, Anybody have insights on this article? Does our ONTAP "Lost Write Protection" address this issue? Regards, Jenson A bit of a flaw with SATA disk drives June 03, 2008 By Jerome Wendt Network World Asia High-capacity serial ATA (SATA) disk drives are now a mainstay in many storage systems and make it feasible for almost any company to obtain a storage system with terabytes of capacity at a reasonable cost. Yet these systems reveal a specific, known deficiency of SATA disk drives that demand companies exercise caution as to what environments they deploy these systems into. A minor flaw with SATA disk drives that high capacity storage systems expose is their bit error rate. Bit errors occur infrequently - about once for every 100 trillion bits. However RAID technology, which is normally used by storage systems to protect against data loss, does not detect if a specific bit on a SATA drive becomes unreadable. While this is normally not a problem on smaller systems, as storage systems add more capacity, the issue becomes more acute. On systems with more than 10TB of capacity the probability of a specific bit of data becoming unreadable is a distinct possibility. On systems with over 100TB, it becomes almost a certainty. So the question becomes: Does losing access to one bit of data really matter? Often, it doesn't unless one stores deduplicated data on these systems which is now the fastest growing trend in data storage. When data is deduplicated, the storage system's need to read every bit of data becomes paramount. The inability to access even a bit of data can result in multiple files becoming unreadable since they all may depend on a specific bit of data to complete their reconstruction. High capacity SATA-based storage systems are the answer to many companies' archiving and backup problems. But SATA bits can bite and using SATA drives to store large amounts of deduplicated data is not always the match made in heaven that vendors make them out to be. Jerome Wendt is the president and lead analyst at DCIG Inc. You may read his blogs at www.dciginc.com <http://www.dciginc.com/> .

1 0

Oracle RAC Deployment Guie/Help
by ifstat 05 Jun '08

05 Jun '08

Hi We’ve being trying to deploy an Oracle RAC on Netapp, using Oracle Enterprise Linux, SnapDrive for Unix (iSCSI Protocol), ASM and SnapManager for Oracle, but cannot do so successfully, because we don’t have the knowledge or resources. We have being searching the netapp library and netapp site for documentation that discusses the procedure for achieving the above, but cannot find anything the meets the above, most guides discuss NFS, but since SMO doesn't support ASM or NFS we need to use either FCP or iSCSI and SMO requires SnapDrive for UNIX. Documents reviewed include the following: http://media.netapp.com/documents/ tr-3594.pdf tr-3555.pdf tr-3339.pdf tr-3536.pdf tr-3592.pdf tr-3495.pdf tr-3349.pdf tr-3408.pdf tr-3423.pdf tr-3527.pdf tr-3572.pdf iag_linux.pdf SnapDrive for Unix Installation and Administration Guide SMO Installation and Administration Guide Seems that various Netapp engineers that have being trying to help us with this are also struggling in finding documentation that is fitted to the above mentioned configuration. Can the toasters community do one better? thanks -- View this message in context: http://www.nabble.com/Oracle-RAC-Deployment-Guie-Help-tp17666620p17666620.h… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

How to identify a hot disk
by Page, Jeremy 04 Jun '08

04 Jun '08

So I am getting the following when running sysstat -u. As far as I know nothing should be hitting the array hard enough to drive disk utilization to 100%, much less hold it there. What can I do to further determine what's causing this? All of my storage is NFS based at this time. 29% 799 44261 1344 14900 54402 0 0 38 93% 46% F 77% 29% 896 43727 1938 14643 54488 0 0 38 93% 43% F 94% 28% 734 43831 1102 13251 54881 0 0 38 93% 44% F 77% CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 31% 876 53275 1354 12054 61719 0 0 39 93% 53% F 80% 13% 264 8377 369 15069 14423 0 0 39 92% 31% 2 94% 8% 107 674 33 13300 5331 0 0 39 92% 30% T 94% 7% 101 601 112 13263 1026 0 0 39 92% 7% T 100% 8% 100 626 55 15145 989 0 0 40 92% 6% T 85% 8% 76 520 76 13809 2049 0 0 40 92% 13% T 100% 8% 96 602 63 13637 893 0 0 40 92% 5% T 93% This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

4 4

RE: snapshot copy
by Christopher Mende 04 Jun '08

04 Jun '08

Have you played with Juniper or Riverbed WAN expander/accelerator devices? Have used them successfully with SM and high latency connections. Budget allowing ... But may be less PIA than manual scripting plus additional benefits they offer. Christopher -----Original Message----- From: John Stoffel <john.stoffel(a)taec.toshiba.com> Sent: Wednesday, June 04, 2008 15:07 To: Glenn Walker <ggwalker(a)mindspring.com> Cc: John Stoffel <john.stoffel(a)taec.toshiba.com>; lists(a)up-south.com <lists(a)up-south.com>; Blake Golliher <thelastman(a)gmail.com>; Fox, Adam <Adam.Fox(a)netapp.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Subject: RE: snapshot copy Glenn> You can always try adjusting the wsize of the snapmirror Glenn> connection over WAN. Could help... Nope, doesn't help. The default snapmirror tcp_window_size is already 2mb, which *should* be enough for my site, but doesn't do a damm thing to help. Again, if you have a WAN link with high latency and high bandwidth, snapmirror/snapvault both suck in my experience. Which is why I'm spending my time doing lrep's by hand to rebuild DR snapvaults. Friggin sucks...

2 1

Possible to deny all permission changes inside a CIFS share?
by Adam McDougall 04 Jun '08

04 Jun '08

I was wondering if in any way it would be possible to prevent all NTFS permission changes inside a CIFS share or volume, including by file owners. I'm not concerned about the admins, but we want to support a strict permission structure with writable directories according to inherited permissions, but not allow end users to subvert the permission scheme by changing permissions on files they own. Wondering if there is any way to do this, or even if there are plausible or solid reasons why it would not be possible at all. I know you can remove the 'Change Permissions' NTFS property, but file owners can change their own. Thanks for any input.

4 4

snmp, missing shelf overview
by Stefan Funke 04 Jun '08

04 Jun '08

I'm trying to monitor ambient temperatures from all our shelves using SNMP. I've found enclTempSensorsCurrentTemp in netapp.mib and it keeps all values I need BUT I don't see a map snmp.id=>shelfid. Did anyone ever found a mapping or knows how enclTempSensorsCurrentTemp is getting filled? Anyone from netapp reading here who can ask to add those informations to your mib in future releases? TIA, Stefan.

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