toasters

toasters@lists.teaparty.net

13515 discussions

Re: How does Netapps win and lose business? (cont.)
by Michael Salmon 11 Aug '99

11 Aug '99

+----- On Tue, 10 Aug 1999 12:24:31 CDT, Arvind K Aggarwal writes: | | > > One other thing that came to my mind is that Auspex does not support | > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS | > > or HTTP myself as I use Filers with NFS exclusively, but I am glad | > > that I have the option of turning on CIFS when my organization | > > decides to use CIFS directly from storage appliances. You may say | > > that the presence of the host processor on an Auspex enables one to | > > do a variety of things like run Samba, but I assure you that Auspex | > > is not optimized to perform any major file operations via its host | > > processor. Also, if you think that you can rdist something quickly | > > to an Auspex box you're in for a disappointment. Both NAC and | > > Auspex are built with a small set of file services (NFS, etc.) in | > > mind. If you don't go through these services in case of Auspex you | > > suffer severe performance penalties. With NetApp this is not a | > > problem as there is no way circumventing those services aside from | > > their proprietary volume copy mechanism which is very robust itself. | > | > Tom, when was the last time you looked at an Auspex? | > | > CIFS is supported. (I also only use NFS :) | > | | Really! Auspex was in our office (I work with Tom) last Friday and asked | us to use SAMBA. Auspex has implemented AT&T's ASU, they call it NeTservices. As such it is a couple of steps removed from M$ so you don't get the latest bugs. There are some restrictions to using NeTservices with regards to OS which I don't recall too well but I don't believe that any of our machines qualified due to the hardware being too old. The 4front machines do pretty well as CIFS servers. If Auspex had had the 4front ready earlier then it would probably have tipped the scales from 49/51 in Dell's favour to 51/49. /Michael

1 0

Re: How does Netapps win and lose business?
by sirbruce＠ix.netcom.com 10 Aug '99

10 Aug '99

On 08/10/99 15:01:55 you wrote: > > >On Tue, 10 Aug 1999, Stephen C. Losen wrote: > >> Actually, if you write N data blocks that correspond to the >> same parity block, you only do N+1 writes for the N blocks. > >That is certainly an optimization. In the most basic case you write one >block and update the parity block, which is two writes. One can also read >all the blocks that add up to the parity block and recheck, but I wonder >what that would do to performance. Given that Netapp's NVRAM allocates writes and then dumps them to disk periodically in stripes, this type of optimization would probably work well with them. Perhaps they do it already. :) Bruce

2 1

Re: How does Netapps win and lose business?
by alexei＠mindspring.net 10 Aug '99

10 Aug '99

Mike Horwath <drechsau(a)tiny.net> writes: > > > I ask because Auspex was just at my office touting their new NS2000 at > > > a price point that I haven't seen before. > > > > OK, here come the rants. > > Excellent, thanks! > For some interesting reading about the ns2000, check out deja.com and do a lookup (in past messages), specifically from Frank Durda. I found them interesting. Alex

1 0

Oracle performance on NetApp
by Itzik (Itzhak) Meirson DSc 10 Aug '99

10 Aug '99

One of our customers is looking into the possibility of using a toaster for the Oracle database. They expect a start point of about 100GB for the db with the potential growth to 1TB. I wonder if some one can share or point me to any performance numbers, success/disappointment stories when using a filer for Oracle database. Thanks, Itzik

1 0

RE: How does Netapps win and lose business? (cont.)
by Sam Schorr 10 Aug '99

10 Aug '99

This is not correct. Auspex does support NFS, CIFS and HTTP in the same manner as Netapps - in fact, instead of emulating the protocols, they are incorporated into the Auspex O/S. I have no idea if this is better or not. -----Original Message----- From: Arvind K Aggarwal [mailto:aggarwla@cig.mot.com] Sent: Tuesday, August 10, 1999 10:25 AM To: tkaczma(a)gryf.net; drechsau(a)tiny.net Cc: toasters(a)mathworks.com Subject: Re: How does Netapps win and lose business? (cont.) > > One other thing that came to my mind is that Auspex does not support > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS > > or HTTP myself as I use Filers with NFS exclusively, but I am glad > > that I have the option of turning on CIFS when my organization > > decides to use CIFS directly from storage appliances. You may say > > that the presence of the host processor on an Auspex enables one to > > do a variety of things like run Samba, but I assure you that Auspex > > is not optimized to perform any major file operations via its host > > processor. Also, if you think that you can rdist something quickly > > to an Auspex box you're in for a disappointment. Both NAC and > > Auspex are built with a small set of file services (NFS, etc.) in > > mind. If you don't go through these services in case of Auspex you > > suffer severe performance penalties. With NetApp this is not a > > problem as there is no way circumventing those services aside from > > their proprietary volume copy mechanism which is very robust itself. > > Tom, when was the last time you looked at an Auspex? > > CIFS is supported. (I also only use NFS :) > Really! Auspex was in our office (I work with Tom) last Friday and asked us to use SAMBA. Arvind Aggarwal > -- > Mike Horwath Admin & Manager @ VISI.com WORK: drechsau(a)visi.com > IRC: Drechsau http://www.visi.com/ HOME: drechsau(a)geeks.org > The only Minnesota ISP with public statistics: http://noc.visi.com/ > Garbage In -- Gospel Out. - berkeley fortune(6)

2 1

Are we missing something? (was How does Netapps win and lose business?)
by Stephen C Woods 10 Aug '99

10 Aug '99

> > > > - Netapps are impossible to back up > > Not so. There are many ways to backup a filer. The fasted by far is > > direct attached SCSI though. If investing in large filers, one might > > consider the use of DLT for backups. Interestingly, there was brief discussion on toasters a few weeks ago about slow backups to a local SCSI tape, when the drive was made remote the backups went MUCH faster. It seems that the additional buffering provided by the network allowed the tape drive to stream better than when it was attached locally. > In a larger environment you probably don't want to backup each > fileserver separately with an attached DLT. And as NetApp doesn't > support a reasonable NDMP version which allows backup over the net the > only way to do a central backup is through NFS - not a very smart > solution. Hmmm, we've been using the native dump to a remote tape (DLT and 3590) using rmt protocol, we have found that we get good transfer rates (with 100Mbit and FDDI the drive streams nicely). We can restore the data using standard Unix restore (AIX and Solaris). In fact just to test our backups we routinely restore 2 Gig sections from dumps, we do other tests involving selecting a number of files at (pseudo)random and restoring them, then comparing them with the original data (first testing to see of the file has been modified since it was dumped). Clearly this is NOT backing up through NFS. We've been doing this for several years now, before we integrated it into our standard backup scheme (home grown, we backup filesystems from a wide range of unix systems) we had a set of scripts that were run by cron to back the filers up using knowledge of the sizes of the filesystems to ensure that any one piece would fit on a tape. Something to the effect of (our tapes are attached to stackers which load the next tape automaticly): rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys1 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys2 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys3 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys4 rsh <host> mt -f <device> rewoffl; rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys5 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys6 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys7 rsh <host> mt -f <device> rewoffl rsh filer3 dump <level>ufbB <host>:<device> 32 35000000 filesys8 rsh <host> mt -f <device> rewoffl Clearly this produces reasonable backup volumes and is quite straight forward. If your filesystems are larger than will fit on a single tape, you have to be a little more creative (using expect to fake interaction), or run the backup interactively. ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

(no subject)
by Tim McDonough 10 Aug '99

10 Aug '99

subscribe toasters

1 0

Re: How does Netapps win and lose business? (cont.)
by Arvind K Aggarwal 10 Aug '99

10 Aug '99

> > One other thing that came to my mind is that Auspex does not support > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS > > or HTTP myself as I use Filers with NFS exclusively, but I am glad > > that I have the option of turning on CIFS when my organization > > decides to use CIFS directly from storage appliances. You may say > > that the presence of the host processor on an Auspex enables one to > > do a variety of things like run Samba, but I assure you that Auspex > > is not optimized to perform any major file operations via its host > > processor. Also, if you think that you can rdist something quickly > > to an Auspex box you're in for a disappointment. Both NAC and > > Auspex are built with a small set of file services (NFS, etc.) in > > mind. If you don't go through these services in case of Auspex you > > suffer severe performance penalties. With NetApp this is not a > > problem as there is no way circumventing those services aside from > > their proprietary volume copy mechanism which is very robust itself. > > Tom, when was the last time you looked at an Auspex? > > CIFS is supported. (I also only use NFS :) > Really! Auspex was in our office (I work with Tom) last Friday and asked us to use SAMBA. Arvind Aggarwal > -- > Mike Horwath Admin & Manager @ VISI.com WORK: drechsau(a)visi.com > IRC: Drechsau http://www.visi.com/ HOME: drechsau(a)geeks.org > The only Minnesota ISP with public statistics: http://noc.visi.com/ > Garbage In -- Gospel Out. - berkeley fortune(6)

1 0

Re: How does Netapps win and lose business?
by alexei＠mindspring.net 10 Aug '99

10 Aug '99

Jeffrey Skelton <jss(a)NET2PHONE.COM> writes: > - SAN is the future of storage Yes, but we are in the dark ages right now. Not all vendors support switched fibre channel, a must for any SAN to work as advertised. The lack of multiple vendors for fibre channel switches also makes for a hard sell right now. Some vendors are further ahead than others in this front. Compaq seems to have a nice, cohesive product. Their new HS{G,Z}80 raid array is slick. > - Netapps and NFS is a lock in to old technology Electricity is a lock in to an old technology. NFS and SMB(CIFS) are the way to share data on a network. Do you think all your clients will be part of the SAN? No way. The SAN is a method for large systems to have shared access to devices. NOTE: this does not mean shared access to the *data*. You need more smarts than SAN for that. Something like clustering would get it... The fact is that even when you have a SAN deployed, you will still need a common access method for the clients to hit the data. NFS/HTTP/CIFS or whatever your protocol du jour is. > - Netapps is JBOD Not quite. JBOD is a simplification. WAFL rocks and is what really lets the filers shine. > - that Eurologic is an unknown scrap vendor Vendor FUD. > - Netapps are impossible to back up Not really: vol copy works well. Sure, you cannot run Legato on the filer, so it makes backups more challenging, but NDMP is supposed to help. The JVM in the filer might prove to be useful in this area. > - RAID 4 is unreliable As compared with? Sure, it is not the same as hardware RAID 1+0, but it is also 1/2 the price (as far as number of disks required, etc). > - WAFL is slow Compared with? No way. UFS is a dog. AdvFS is a black box. Veritas is Sun only. XFS is not ported to other platforms (yet). WAFL is the way to get performance on these boxes. The white paper should shed some light on this. Seriously: the main drawback to any competing solution is the file system. Show me something else that has the ability to do snapshots, grow the filesystem on the fly, increase the ammount of files on the fly, do well with large directories and still be able to pump data out quickly. > - WAFL is impossible to recover when it becomes corrupt Given sufficient corruption, any filesystem is unrecoverable. I have seen some seriously bad situations and come out ok. > - wack takes all day to report that you're still in trouble Tough one. THis is true sometimes. If you do not run the right incantation of wack (version, etc), you could be faced with never-ending wacks. This is a pain. > - the cluster failover takes too long What do you call too long? > - the cluster failover is unreliable at best I cannot address this, as I have not used it in production. > - the Netapps performance is terribly slow Again, compared to what? Check the SPEC SFS numbers (what used to be LADDIS) at http://www.spec.org/ and see what the vendor numbers are. Sure, the f760 solution falls short of the 49k NFSops that an EMC Celera does, but it is also a small fraction of the price. Yes, you can hit a performance wall with the filers. My face has a brick wall imprint on it :( > - the software is big pile of patches that are impossible to keep > track of No. But NetApp could do better at alerting customers of bugs (especially evil bugs). If you do autosupport, the NetApp folks should be able to do some analysis of the data and make reccomendations (based on firmware revs, OS version, etc). > They've also given me references of companies that have > switched from Netapps to other solutions. I am sure there are plenty of companies that have done this. But this is more vendor FUD. The NetApp filers are great tools, but they are not a one-size-fits-all solution. Different needs call for different solutions, so sometimes people outgrow the filers (or the filers were never the right solution for the person to begin with). > - they lost data with Netapps. Why? Because they could not take > a backup with their enterprise backup software and then they > suffered a multiple disk failure from a set of disks with > problem firmware. This is more a problem of laziness. In my previous job, we backed up our filers with Alexandria. It worked well. It was not as fast as doing a raw dump to tape, but it worked. > - the Netapps filer was too slow for database use. I could Perhaps. > and throughput. How would you rate the Netapps for performance > for things like home directory storage? They would excel at this. The filers do very well in a high read to low write ratio environment. > - the clustering did not work. Paid for cluster and the failover > did not work as advertised. Some folks have misconceptions about what the cluster failover does. I think this is mainly NetApp's fault for not really being clear about what the product does (or setting proper expectations). Important details of the filer operation are buried in different locations. Clustering is not a simple thing to deploy. It may appear trivial, but it adds a layer of complexity which may not make all people comfortable. You need to make sure that the added reliability is worth the cost (not just money). > I'm not dumb enough to believe all of the claims that sales droids > make. But, I'd like to hear some opinions as to what makes you > buy Netapps, what keeps you on Netapps, and what will drive you > away from Netapps. I have used filers for close to 5 years now. The core competency of the company is the WAFL file system and the NFS code. These boxes are good at delivering data. Alex

1 0

Re: How does Netapps win and lose business?
by sirbruce＠ix.netcom.com 10 Aug '99

10 Aug '99

On 08/09/99 20:07:17 you wrote: >I'm interested in hearing any stories on how Netapps wins or >loses your business. I'm currently shopping for storage and a >Netapps filer seems to fit the bill. I've talked to other >storage system vendors -- that big one, EMC (or is it Data >General), MTI, and some others. In my opinion, Netapp wins business by example, not by words. Anyone can talk down a product, but all you have to do is test drive a Netapp filer and test drive an EMC solution and see which works better for you for the price. >They all emphasize that: >- SAN is the future of storage NAS is also the future of storage. The two are not incompatible. However, traditional SAN relies on traditional general-purposes UNIX and NT servers as front-ends, and that is clearly *not* the future. >- Netapps and NFS is a lock in to old technology Gee, what do they propose to replace NFS with on the UNIX side? Do they expect you to go all NT? NT is old technology too. But even so, Netapp also does CIFS, so I can't see how NFS is holding them back. What else is old technology? The fibre channel disks? The alpha CPU? The gigabit ethernet cards? >- Netapps is JBOD That's silly. JBOD is the antithesis of RAID. And Netapp is clearly more than just disks. >- that Eurologic is an unknown scrap vendor Before Eurologic they used Digital. Did they call Digital an unknown scrap vendor too? >- Netapps are impossible to back up Hardly. People have been backing them up for years. Now, they can be *difficult* to back up the way you like, depending on your configuration, but Netapp is making great strides in improving this. I'd take the performance of a Netapp with the tradeoff of a little more work backing it up any day. >- RAID 4 is unreliable RAID 4 is just as reliable as RAID 5, with easier expansion and less of a performance penalty (when used with WAFL). >- WAFL is slow This is an odd complaint. How does one accurately test a filesystem's underlying performance without being skewed by the performance of the hardware it runs on? Still, if one can, the performance numbers that Netapp repeatedly puts up on SFS benchmarks seems to indiate that Netapp is able to do more with less. Perhaps their filesystem is slowing them down, but their software is just that much better than everyone elses? >- WAFL is impossible to recover when it becomes corrupt Not true. I've always been able to recover filers in the rare case they became corrupt. There are few exceptions; I'm sure Netapp could give you actual reliability numbers under NDA. >- wack takes all day to report that you're still in trouble So does fsck if you do it on a big filesystem. I'm not sure I understand this complaint. If you have reasonable sized filesystems wack can often fix any problems in them in a reasonable amount of time. >- the cluster failover takes too long >- the cluster failover is unreliable at best I can't really judge this, but it would seem competitive with other industry solutions from the documentation. >- the Netapps performance is terribly slow Uhhh, then why do they continually outperform all other competition on SFS benchmarks on response time, and provide more NFS ops per dollar or per hardware than other results? If the other vendors have a faster solution, they should post the results. They haven't... there are some *bigger* boxes that will give you more raw throughput, but cost more and use far more disk. You could put two filers in place of that one and get better performance at a lower price. >- the software is big pile of patches that are impossible to keep > track of Again, I don't understand the complaint. The same could be said for any piece of software. That doesn't mean it's true. I would agree that patches from, say, Sun, are easier to keep track of, because they come out infrequently and sometimes never at all. You often have to wait until the next big release to hope that your bug is fixed. Netapp, on the other hand, will usually turn around a patch release to fix whatever specific bug you find in a few days, if it's critical. So sometimes there are patches out there that you might not know about, but you can easily keep up to date on the latest tested release on now.netapp.com. You don't want to be risking an untested patch release unless you need it for a particular problem you're having, do you? >They've also given me references of companies that have >switched from Netapps to other solutions. And Netapp can give you references of comapnies that have switch to Netapps from other solutions. Why don't you call them? >In general three themes came from the references: >- they lost data with Netapps. Why? Because they could not take > a backup with their enterprise backup software and then they > suffered a multiple disk failure from a set of disks with > problem firmware. That sounds like a customer problem, not a Netapp one. They didn't get the proper enterprise backup software when they got their Netapps, and were too dumb to implement a different backup solution in the meantime. "I didn't do backups because it didn't work with this *one* piece of software"? What kind of excuse is that? I'll have to try that out on my manager next time and see what he says. As to the problem firmware, sounds like they should have upgraded it. None of this is any different from any other NAS/SAN solution. There are always risks with buggy code; that's what backups are for. > I've seen a lot of griping on this least lately about backups. > How much of a problem is the backup situation and does the > situation become a problem when it requires a patch for the > Netapps software that may introduce other instabilities? I'd say the problem is mild if you use supported software. The pool of supported software is growing every day. Regular backup and retore have been pretty stable for some time now. >- the Netapps filer was too slow for database use. I could > understand how some of the storage arrays directly attached > to a server could be faster. This isn't my application space, > so I'm not outright concerned with it. It's also wrong. Netapp is often faster than directly attached storage arrays, so long as you have a good network setup. Ask Netapp how they implement their databases in-house. > But, I have seen some of the recent messages on performance > and throughput. How would you rate the Netapps for performance > for things like home directory storage? 3-10 times better than anything else for the same price. Maybe twice as fast as anything else at a higher price. >- the clustering did not work. Paid for cluster and the failover > did not work as advertised. > > This concerns me, because I am willing to pay the extra money > for a cluster. As long as I'm shelling out, should I go to EMC > for reliability or hope that the Netapps failover can work? > I can get more Netapps for the money. I think Netapp's advatanges are worth it even if the failover doesn't work, unless you absolutely need 100% failover in your particular environment. If so, then I can't say if EMC is better or not, having not the experience with their failover. However, it may not matter, since their performance will be so bad at that price point no one will care about failover. >I'm not dumb enough to believe all of the claims that sales droids >make. But, I'd like to hear some opinions as to what makes you >buy Netapps, what keeps you on Netapps, and what will drive you >away from Netapps. Netapps are faster, simpler, and more reliable than any other competitor's solution for the same price. Period. They do require some tinkering and patching from time to time, if you are in a particularly demanding environment. And they do have to be backed up if you want 100% security against a rare double disk failure. Bruce

1 0

na_syslogd question
by Jay Soffian 10 Aug '99

10 Aug '99

syslogd automagically rotates the /etc/messages file weekly. If I setup the syslog.conf to log to other files, will those also be automagically rotated? If not, can I just rotate those files out from under syslogd and it will take notice and re-open the logs? I found lots of info about log rotation up on NOW. I didn't find the answer to this question in either the man pages or on NOW, but maybe I missed something. j. -- Jay Soffian <jay(a)cimedia.com> UNIX Systems Engineer 404.572.1941 Cox Interactive Media

3 2

RE: na_syslogd question
by Hackworth, Brian 09 Aug '99

09 Aug '99

: syslogd automagically rotates the /etc/messages file weekly. If I : setup the syslog.conf to log to other files, will those also be : automagically rotated? No. The magic works only for /etc/messages. : If not, can I just rotate those files out from : under syslogd and it will take notice and re-open the logs? Yes. The ONTAP syslog actually closes the messages files after writing each message, so moving the files around shouldn't mess things up. Hope this helps. - Brian

1 0

Re: SUMMARY: Off Subject: Net App Mailing List
by sirbruce＠ix.netcom.com 07 Aug '99

07 Aug '99

>The list is: toasters(a)mathworks.com. To subscribe: Sending email to >lists(a)mathworks.com with 'subscribe toasters' as the body of the email. > >Marc Summers has different suggestion: > >As long as you are considering file servers >I would seriously consider MDL corp. >They are the Mother of Network Appliance and have a similar >file server for about half the price, and it is rich with >features, and is more flexable than the Network Appliance filer. MDL Corp is not the mother of Network Appliance in this universe or any other alternate universe. Bruce

1 0

.
by Daniel Serna 07 Aug '99

07 Aug '99

subscribe toasters

1 0

Ebay..
by Mohler, Jeff 06 Aug '99

06 Aug '99

Ya know, I bet you could sell a LOT of Filers down road with Ebay tomorrow... Six hours and the 'warm backup' isnt online yet. With my filers..and by hand, thats been a 10 minute procedure (including getting out of bed).

3 2

ok, I'm curious
by fubar＠mathworks.com 06 Aug '99

06 Aug '99

I go out to a last-day lunch for ~90 minutes. I get back and seemingly half the world has subscribed (or tried) to the toasters list. So I'm curious... where was it just announced ? :-) K.

4 3

SUMMARY: Off Subject: Net App Mailing List
by grdodson＠lexmark.com 06 Aug '99

06 Aug '99

The following went out on sun-managers today...... Graydon Dodson ----- Begin Included Message ----- From sun-managers-relay(a)sunmanagers.ececs.uc.edu Fri Aug 6 14:55:38 1999 Date: Thu, 5 Aug 1999 21:49:49 -0700 (PDT) From: Ping Wei <wei(a)sfo.erg.sri.com> Subject: SUMMARY: Off Subject: Net App Mailing List To: sun-managers(a)sunmanagers.ececs.uc.edu Hi, Thanks to Bernhard Weinelt mgx(a)spruce.lsd.ornl.gov Darren Dunham The list is: toasters(a)mathworks.com. To subscribe: Sending email to lists(a)mathworks.com with 'subscribe toasters' as the body of the email. Marc Summers has different suggestion: As long as you are considering file servers I would seriously consider MDL corp. They are the Mother of Network Appliance and have a similar file server for about half the price, and it is rich with features, and is more flexable than the Network Appliance filer. Check out www.mdlcorp.com I think you will be very pleased. ------------- Original Question ------------- Hi, Sorry this is off subject. I have seen couple of discussion about Network Appliance File Server. Does anybody know any mailing list regarding Net App Servers? Thanks. -- Ping Wei wei(a)erg.sri.com ------------- End ------------- ----- End Included Message -----

1 0

Re: Disk death rate by usage pattern
by sirbruce＠ix.netcom.com 06 Aug '99

06 Aug '99

On 08/06/99 14:44:03 you wrote: > >"Soren S. Jorvang" <soren(a)t.dk> writes: > >> For instance, I wouldn't be surprised if parity disks had different >> failure patterns than data disks. > > >Interesting, the disks I have seen the *least* ammount of failures >has been on the parity drive. Usually, any new generation of drives >has some issues that need to be shaken out, so the first few months >proove to have higher infant-mortality-rates for (new) drives. In my experience, parity drives were the most likely to fail, although the ratio of failures of parity:data may have been as slim as 3:2. Most failures were *not* correlated with load, mainly because Netapp load tests all the drives before selling them, and any such failures are usually seen within the first few days. So you're left with fairly normal disks that just decide to fail whenever in the middle of the night just to annoy you. :) The exception would be a greater chance of a failure during the intense load caused during disk reconstruction, but mainly that was due, I think, to a priori problems with the disk that went undetected. RAID scrubbing took care of that issue for the most part. This is just my experience. I'm sure Netapp has data on all of their parts and their relative failure rates; this would also address the earlier question about NIC failures. (BTW, I agree with the general consensus that the onboard NIC seems to be the most likely to fail among various models.) They might be willing to share it if you ask them (probably under NDA). Bruce

1 0

Re: Disk death rate by usage pattern
by alexei＠mindspring.net 06 Aug '99

06 Aug '99

"Soren S. Jorvang" <soren(a)t.dk> writes: > For instance, I wouldn't be surprised if parity disks had different > failure patterns than data disks. Interesting, the disks I have seen the *least* ammount of failures has been on the parity drive. Usually, any new generation of drives has some issues that need to be shaken out, so the first few months proove to have higher infant-mortality-rates for (new) drives. YMMV. Alex

1 0

Disk death rate by usage pattern
by Soren S. Jorvang 06 Aug '99

06 Aug '99

Hi, I was idly wondering if you (the NetApp guys) have statistics on which disk usage patterns in filers are most likely to cause disks to die or fail otherwise. For instance, I wouldn't be surprised if parity disks had different failure patterns than data disks. -- Soren

1 0

None
by Gilles TOURPE 06 Aug '99

06 Aug '99

subscribe toasters ------------------------------------------------------------ Gilles TOURPE - System and Network Administrator APS BNP ARBITRAGE - Salle des marches ACTIONS - PARIS - France Phone : (33)-1-40-14-24-03 e-mail : gilles(a)bnpcn.com

1 0

(no subject)
by Matt Reynolds 06 Aug '99

06 Aug '99

subscribe toasters

1 0

subtle changes cause problems
by Graham C. Knight 06 Aug '99

06 Aug '99

A "df" on a 5.2.1P2D14 system shows: Filesystem kbytes used avail capacity Mounted on vol0 396529396 302447476 94081920 76% /vol/vol0/ snap reserve 69975772 66004776 3970996 94% /vol/vol0/.. nosnap 15813736 8979244 6834492 57% /vol/nosnap/ snap reserve 0 0 0 ---% /vol/nosnap/.. On a 5.2.3 system it shows: /vol/vol0/ 549255588 211150080 338105508 38% /vol/vol0/ /vol/nosnap/ 78241536 67460044 10781492 86% /vol/nosnap/ The "snap reserve" line has disappeared. That makes my SNMP query of the percentage of snap space being used return a bogus number (which happens to be 100% which sets off various alarms) :-( Is there any way to get the snap reserve lines back *without* turning nosnapdir off? Or is there a better way to get the nunmber via SNMP? I'm using mib numbers that appear to use the same output that the "df" command uses ie: Target[ast-h-dcf01.snapshot]: 1.3.6.1.4.1.789.1.5.4.1.6.2&1.3.6.1.4.1.789.1.5.4.1.6.2:public@ast-h-dcf01 Thanks, Graham

1 0

None
by Hiu-Man Cheung 06 Aug '99

06 Aug '99

subscribe toasters

1 0

Re: disk_fw_update
by Michael Salmon 06 Aug '99

06 Aug '99

+----- On Thu, 05 Aug 1999 13:06:37 PDT, kevin graham writes: | | I was reading the docs prior to upgrading to 5.2.3, and I realized that I get | to upgrade everything, os, filer fw, and disk fw.. | | The thing that occured to me as unfortunate was from na_disk_fw_update(1): | | This command makes disks inaccessible for up to 2 minutes, so network | sessions using the filer should be closed down before running it. We have noticed that the ATM driver also shuts down when disk_fw_update is run in 5.3. Again it isn't a big deal as you shouldn't need to run the command often but it doesn't make me feel warm inside. On a related note, I note that disk_fw_update can be run from telnet and rsh in 5.3. My understanding was that disk_fw_update wasn't a security problem because it could only be run from the console. /Michael

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