toasters

toasters@lists.teaparty.net

13515 discussions

RE: F740 cluster
by Sam Schorr 05 Apr '99

05 Apr '99

Jason, We do have 2 F740's clustered, the first one (our "original" filer) has 2 racks of 9 gig drives, while the newer cluster partner has 2 racks of 18gig drives. We do not use virtual interfaces, so I'm not sure what relevance our experience is. We did have quite an adventure, with many "downs", all on the first filer, although none turned out to be cluster related. We have not had any drive failures to date. We are on 5.2.1P2D6, primarily because we are an exclusive CIFS shop, and due to some networking problems, the filer would reboot itself (an problem with WAFL handling CIFS that sends commands out of sequence). Netapp worked hard and vigorously to retrofit a patch that is in 5.3.1 (and thus not released) into 5.2.1 (thus the D6). We did have some initial issue with the disk shelves on our 1st filer that required swapping them to get clustering to work. All clustering commands have worked as advertised, but as we only have one physical interface running at this time, I'm not sure it helps you. --srs -----Original Message----- From: Jason D. Kelleher [mailto:kelleher@susq.com] Sent: Monday, April 05, 1999 10:50 AM To: toasters(a)mathworks.com Subject: F740 cluster Anybody out there have an F740 cluster w/ 18GB drives running in production? If so, I have a couple of questions I'm hoping you can answer: 1) Have any problems loosing routes over a virtual interface? If you physically disconect all the links in a trunk it drops all routes which use that interface, even static routes w/ routed off. 2) Have you been able to takeover/giveback a virtual interface? Treating it like a "normal" interface doesn't seem to work and I haven't been able to find any special instructions for this. 3) Any unexplained panics? We had one running 5.2.1 in takeover mode -- didn't even drop core. Another attributed to a bad disk while we were running 5.2.1P1. We're now at 5.2.1P2 after several ndmpd hangs (didn't bring down the filer), seems to be stable. 4) How many disk failures did you see within the first 6 months of getting the filer? (looks like we're on 2 of 24 in 3 months and we haven't even used them all yet). 5) Do you have the name and address of the person in charge of the hold muzac for the support line? The 5 minute loop of garbage is really ramping up my aggression level and I'd prefer to take it out on the person responsible. I have a couple of open calls with support I'm waiting for status on, but I'm not calling them because if I have to listen to that damned muzac tape loop around one more time I'm going to kill someone. Since my office-mate is closest it would probably be him... and that would just leave me more work to do. (Moving bodies, digging holes, and handling all his projects...) Any help would be greatly appreciated. jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

1 0

Re: F740 cluster
by Jason D. Kelleher 05 Apr '99

05 Apr '99

In message <199904051837.LAA08270(a)sas-pc.netapp.com>, Scott Schoenthal write s: >> 2) Have you been able to takeover/giveback a virtual interface? >> Treating it like a "normal" interface doesn't seem to work >> and I haven't been able to find any special instructions >> for this. > >Virtual interface (vif, Etherchannel, link aggregation, your-name-here) >takeover/giveback is not supported in 5.2.x > >The 5.3 release supports virtual interface takeover/giveback. > >/sas Thanks, I'll write that little gem in my 5.2.1 manual... Did anyone consider putting this info in the System Administrator's Guide? the Cluster Conversion Guide, how 'bout somewhere on the NOW site? I try to be a good little user and RTFM, but if the FM doesn't have the info... :( jason

1 0

RE: IRCACHE Web Cache Bakeoff?
by sirbruce＠ix.netcom.com 05 Apr '99

05 Apr '99

On 04/05/99 20:07:01 you wrote: > > >Actually Netchache was doing very well but since no competition >was present the performance figures will not show if A or B >was the best. My own opinion is that Netapp will present the figures >but first do a thorough check to see if the competition will >have an opinon why they didn't enter and if they will kill the outcome. >Hence why didn't Inktomi, Cacheflow, etc enter? But some competition *was* present. The report was already released. http://bakeoff.ircache.net/ Bruce

1 0

RE: F740 cluster
by Smith, Gil 05 Apr '99

05 Apr '99

Hi Jason, I am just going to comment on a few of your items below: > 2) Have you been able to takeover/giveback a virtual > interface? > Treating it like a "normal" interface doesn't seem to work > and I haven't been able to find any special instructions > for this. I believe 5.3 includes support for this ala "pvif" which is policy based virtual interface (superset of vif). 5.3 should be out any day now and the details of the "pvif" will be documented in the usual places (*.pdf files available in the software library section of now.netapp.com for current holders of the software subscription service option). > I have a couple of open calls with support I'm waiting for status > on, but I'm not calling them because if I have to listen to that > damned muzac tape loop around one more time I'm going to kill > someone. Since my office-mate is closest it would probably be > him... and that would just leave me more work to do. (Moving > bodies, digging holes, and handling all his projects...) > > Any help would be greatly appreciated. I am truly sorry you have had to sit and listen to this music. It is certainly not the intention of anyone at Network Appliance that this happens. I have sent you some names via a separate email but will comment in general to this list. If you *ever* have a support gripe, concern, or feedback please call and ask to speak with the technical support shift manager. We value your business. Regards, Gil

1 0

RE: IRCACHE Web Cache Bakeoff?
by Jonas Jonsson 05 Apr '99

05 Apr '99

Actually Netchache was doing very well but since no competition was present the performance figures will not show if A or B was the best. My own opinion is that Netapp will present the figures but first do a thorough check to see if the competition will have an opinon why they didn't enter and if they will kill the outcome. Hence why didn't Inktomi, Cacheflow, etc enter? /// Best regards, Jonas -----Original Message----- From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] Sent: den 5 april 1999 06:14 To: toasters(a)mathworks.com Subject: IRCACHE Web Cache Bakeoff? Can anyone at Netapp tell us what happened with the ircache web cache bakeoff? Netapp attended and then declined to have their results published. Many other companies backed out as well, such as Cacheflow and IBM. Rumor has it that netcache was outperformed; was the benchmark unrealistic or did Netapp withdraw for other reasons? Bruce

1 0

RE: IRCACHE Web Cache Bakeoff?
by Mohler, Jeff 05 Apr '99

05 Apr '99

Surely it feels like a failure, but we'll see. The 'spin' on the situation is not good. > -----Original Message----- > From: sirbruce(a)ix.netcom.com [SMTP:sirbruce@ix.netcom.com] > Sent: Sunday, April 04, 1999 11:14 PM > To: toasters(a)mathworks.com > Subject: IRCACHE Web Cache Bakeoff? > > Can anyone at Netapp tell us what happened with the > ircache web cache bakeoff? Netapp attended and then > declined to have their results published. Many other > companies backed out as well, such as Cacheflow and IBM. > Rumor has it that netcache was outperformed; was the > benchmark unrealistic or did Netapp withdraw for other > reasons? > > Bruce

1 0

RE: NAC SAN
by Chen, Ray 05 Apr '99

05 Apr '99

Um, because the distinctive characteristic of SAN is that clients can write directly to the storage devices bypassing any server? This is possible only if a storage-level (e.g. block-level) protocol like SCSI runs on the wire. (Actually, I'm lying here. There are two ways of enabling this. One is to use a really simple protocol like SCSI. The other is to implement an industry-standard clustered filesystem with the disk drives/storage devices as an intelligent component of said filesystem. A very complex protocol whose viability and practicality is an issue in its own right. The rest of this mail assumes a block-level SAN protocol.) As folks have pointed out, SAN has its advantages and disadvantages. It eliminates the backplane of server (unless you have a RAID controller in front of the drives :-) from the I/O path, eliminating a possible I/O bottleneck. But there is no server to protect the integrity of the data and even if there is, the protocol is so low-level in a SAN, the server has no effective way of detecting when a client has gone insane (maliciously or not) and is scribbling gibberish on the drives. So trust becomes a definite issue. Personally, I see data sharing using SANS as making sense in small workgroup environments and what I call "machine room clusters" -- a SAN in a machine room supporting a dedicated cluster. Typically you'd do the latter because scaling via a cluster is cheaper (and more available) than scaling via MP. But both are situations where you are willing to trust all the machines in the cluster because they are all firmly controlled by the group whose storage/data is being shared. Ray Chen rcc(a)netapp.com > -----Original Message----- > From: Adams, Christian [mailto:Adams_Christian@emc.com] > Sent: Tuesday, March 30, 1999 10:14 AM > To: 'Dave Hitz'; willh(a)infi.net > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > Subject: RE: NAC SAN > > > Hey Dave Hitz - > > Why do you focus on existing protocols in your discussion? > This indicates > that the introduction of Fibrechanel with either encapsulated SCSI or > Ethernet is the critical event in the creation of SAN or NAS. > Further in > your discussion, you draw a parallel to switches and routers > which indicate > that you may be thinking in terms of shared versus segmented > data flows. > And yet in all of your discussion, you do not address the issues of > management, integration, or value. > > Loved your EMC bit, > /Christian Adams > EMC > > > -----Original Message----- > > From: Dave Hitz [SMTP:hitz@netapp.com] > > Sent: Saturday, March 27, 1999 1:41 PM > > To: willh(a)infi.net > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > Subject: Re: NAC SAN > > > > > Tom's statement below (to a [NetApp] SAN when we build > one) brings up a > > > familiar argument between myself and my boss. My boss > contends that > > > NetApp is NOT capable of migrating to a "real SAN." > > > > I've been delinquent in my duty of writing a NAS and SAN paper. I'm > > about half way done. Whem I'm done, I'll post it here, probably in > > early form, so that you guys can critique it for me. > > > > Very briefly, I believe that NAS and SAN are different but related > > technologies, and that the definitions are as follows: > > > > NAS (Network Attached Storage) > > Storage accessed over TCP/IP, using industry standard file > > sharing protocols like NFS, HTTP and Windows Networking. > > > > SAN (Storage Area Network) > > Storage accessed over a Fibre Channel switching fabric, > > using encapsulated SCSI. > > > > I also think that both NAS and SAN are useful, and that -- > in the long > > run -- both will be critical components in any large data > > infrastructure. I think there's a strong analogy to the TCP/IP > > networking world. Routers and switches are very similar in > some ways, > > yet subtly different in others. In the mid-eighties, > arguments raged > > about which was "better". (Back then switches were called bridges.) > > Today we understand that any large network infrastructure needs to > > include both. > > > > Some people would quibble with my definitions. Some would > argue that > > if you run NFS over TCP/IP over fibre channel, then that is > a SAN. I > > figure that we didn't invent new names for NFS over 100bT, > FDDI, ATM, > > or Gigabit -- what's so special about fibre channel? > Others argue that > > a SAN is any network dedicated entirely to storage traffic. > Does this > > mean a SAN turns to a NAS if you fire up a telnet on it? A year ago > > these definitions were less settled, but today I think these are the > > definitions that are emerging. > > > > With these definitions, the key difference is between file system > > protocols and raw disk protocols. With NAS, the filesystem > runs on the > > storage system itself. (For NetApp, that's WAFL.) With SAN, the > > filesystem runs on the hosts attached to the storage system. > > > > People familiar with EMC will recognize this model. With an EMC > > Symetrix, you get a big box of RAID protected disks, and > you can attach > > multiple hosts to that one box. Thus, I view SAN as "open EMC". On > > the one hand, SAN could be viewed as a threat to EMC. But > on the other > > hand, EMC has a solid history of products -- software and > hardware -- > > based on this storage model, which means that they ought to > have a real > > head-start on SAN. I think the SAN vendors have a great > opportunity if > > they really can create "open EMC". After all, EMC is doing > $4 Billion > > a year in business with this model! > > > > In any case, I think NAS has some serious advantages over > SAN. One big > > issue with running the file system on the separate hosts is that it > > makes true data sharing very difficult. The on-disk byte > formats are > > very different between UNIX and NT, and even between > different flavors > > of UNIX. Given the differences between UNIT and NT filesystem > > semantics, it's no surprise that the on-disk format is > different. With > > NAS, the filesystem is by the data, so it can convert the on-disk > > format into an industry standard protocol appropriate to > the host that > > wants the data: NFS for UNIX, NT Shares for NT, and HTTP for web > > browsers. > > > > It is technically possible to build a "global file system" > that has a > > common on-disk format for multiple operating systems, thus allowing > > NAS-like sharing for SAN. However, I'm skeptical of that > model. First > > of all, there are no such products today. And even when they become > > available, sharing won't be based on industry standards. A > system will > > only be able to participate in sharing if it runs a special SAN file > > system from a particular vendor. My believe is that the > lesson of 20 > > years of networking is that we build heterogeneous environments by > > creating open standards and allowing everyone to support > them -- not by > > saying that anyone who wants to participate in sharing must buy code > > from one particular company. > > > > Having said all this, though, NetApp does have plans to leverage SAN > > technology. We have announced an OEM agreement with > Brocade. Here are > > the benefits we expect to achieve: > > > > - Attach to lots of disks. > > > > A fibre channel loop is limited to 127 drives, but with a 16 > > port fibre channel switch, the limit goes to almost 2000 > > drives. With additional switches, you can support an arbitrary > > number of drives. > > > > - Share tape drives between multiple servers. > > > > I believe that backup applications are the killer application > > for SAN. When people buy expensive tape jukeboxes, they want > > to be able to attach them to multiple servers. With today's > > SCSI tapes that's a painful job. But with fibre channel and > > fibre channel switches, it's easy to connect a single tape to > > any number of hosts. > > > > - Disaster Tolerant Solutions > > > > Fibre channel switches can do WAN tunneling to provide > > connections to remote disks without any changes to the server > > code. This makes it much easier to build remote mirrors for > > data replication and disaster protection. > > > > In conclusion, I believe that NAS and SAN are both important > > technologies, and the any large data infrastructure in the > future will > > include both. I believe that NAS focuses on issues associated with > > users, applications, and data sharing. I believe that SAN > focuses on > > issues associated with disk and tape devices, connection to large > > numbers of them, and moving data back and forth between > them. In the > > long run, any large environment will have both sets of > issues, and will > > need both types of solutions. In the short run, NAS makes > good sense > > as a starting point, because it is here today and the standards it > > relies on have been solid for over a decade. > > > > I'll go ahead an post the whole paper when I finish, but I still > > thought it might be useful to share my thoughts in this brief, > > half-baked form. > > > > Dave >

2 1

NFS invitation
by tkaczma＠gryf.net 05 Apr '99

05 Apr '99

I believe someone invited us to a NFS v4 discussion sometime back. However, somehow the message hit the bit bucket on my machine. Could someone forward me a copy of that letter or direct me to a site mentioned inside? I would really like to see ACLs in NFS v4. I think this is one of few advantages that CIFS, AFS, and others have over NFS. Tom

2 1

RE: Slow sequential disk reads on F740
by Brian Meek 04 Apr '99

04 Apr '99

Setting options nfs.udp.xfersize 32768 helped a lot, now were seeing ~25 MB/sec transfers to and from the filer. Why isn't this the default? Brian -----Original Message----- From: Smith, Gil [mailto:gil.smith@netapp.com] Sent: Friday, April 02, 1999 1:38 PM To: toasters(a)mathworks.com Subject: FW: Slow sequential disk reads on F740 -----Original Message----- From: Smith, Gil Sent: Friday, April 02, 1999 4:18 PM To: 'toaster(a)mathworks.com' Subject: RE: Slow sequential disk reads on F740 Hi, You might want to try, filer> options nfs.udp.xfersize 32768 which is a hidden option (doesn't show up when you type options with no arguments). This might be especially usefull in Gigabit Ethernet environments. Regards, Gil -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Thursday, April 01, 1999 5:02 PM To: Brian Meek Cc: toasters(a)mathworks.com Subject: RE: Slow sequential disk reads on F740 On Thu, 1 Apr 1999, Brian Meek wrote: > > I'm not sure this is related, but if you do a nfsstat -m on the client, does > it show the rsize to be 8192 or 32768? Interesting... I was forcing rsize and wsize to 32768 on the mount command line just to be pedantic, but this is what I'm seeing (output edited for brevity): # mount -o vers=3,proto=udp,rsize=32768,wsize=32768 e2.j:/ /j # mount /j on e2.j:/ vers=3/proto=udp/rsize=32768/wsize=32768/remote on Thu Apr 1 16:51:27 1999 # nfsstat -m /j from e2.j:/ Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,acl,rsize=8192,wsize=8192,re tran s=5 > When reading data from our NetApps using our E450's we don't see > anywhere near the same performance as when we read data from our > E450's with our E450's using NFS3 over udp. I've always attributed > this to the client code forcing an rsize of 8192 when connecting to > the filler, and allowing a rsize of 32768 when connecting to > anything else (Sun, Dec, SGI). Has anyone else seen this? It sounds like the NFS server dictates the parameters. I can connect with 32K rsize/wsize using UDP transport between Solaris servers, but only 8K between a Sun and an Netapp, and 16K between a Sun and a FreeBSD machine acting as the server. TCP transport allows me to use 32K block sizes in any server. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

3 2

RE: Slow sequential disk reads on F740
by Brian Meek 03 Apr '99

03 Apr '99

I'm not sure this is related, but if you do a nfsstat -m on the client, does it show the rsize to be 8192 or 32768? When reading data from our NetApps using our E450's we don't see anywhere near the same performance as when we read data from our E450's with our E450's using NFS3 over udp. I've always attributed this to the client code forcing an rsize of 8192 when connecting to the filler, and allowing a rsize of 32768 when connecting to anything else (Sun, Dec, SGI). Has anyone else seen this? The difference grew even more noticeable when we moved the traffic from a dedicated 100 Mb FX crossover to a 1000 Mb FX switched environment. Prior to switch, numbers like yours for Sun from NetApps reads, ~11 MB/Sec sun from Sun reads, after the switch Sun from NetApp ~18MB/sec, Sun from Sun ~50 MB/sec. The NetApp server is a 740 with 6 shelves, and the Sun's are E450's 4/400 MHz with an A5200 array, 1+0 configuration. -----Original Message----- From: Val Bercovici (NetApp) [mailto:valb@netapp.com] Sent: Thursday, April 01, 1999 9:41 AM To: Brian Tao Cc: toasters(a)mathworks.com; sirbruce(a)ix.netcom.com Subject: RE: Slow sequential disk reads on F740 > What sort of guidelines do people follow when deciding on the > minra setting? At one end of the spectrum, you have broadcast video > streaming servers that deal exclusively with long, sequential reads. > At the other end, you have something like an INN server storing > articles in individual files. Are there any tools to help decide > which setting is best, or do you just "eyeball" it and try both > settings and see which one seems better? My simple rule is minra=on for crazy apps like INN what have tons of small totally random I/O's and minra=off for almost anything else. Basically, if you think caching will help you in any way you want minra off. > A single drive should be able to sustain 8MB/sec or higher just on > its own... a stripe of five drives should hit at least 40MB/sec. > sysstat on that filer does in fact report 38 to 43MB/sec disk reads > during a "vol scrub". Actually, the 9GB SCSI drives I believe you're using are only rated for a max (not sustained) external transfer rate of 5MB/sec, so the numbers you're seeing really make sense to me. FYI, the max external transfer (not sustained) rate for our 18GB FC-AL drives is a much nicer 12.5MB/sec so you would probably see better (although not necessarily double <g>) sequential performance with those.... -Val. ============================================== Val Bercovici Office: (613)724-8674 Systems Engineer Pager: (800)566-1751 Network Appliance valb(a)netapp.com Ottawa, Canada FAST,SIMPLE,RELIABLE ==============================================

3 3

RE: Slow sequential disk reads on F740
by Smith, Gil 03 Apr '99

03 Apr '99

I dunno for sure. Might just be for safety sake in case we install into an error prone network environment. With an Ethernet MTU of 1500, 8192 bytes takes 6 IP fragments for delivery. If any single fragment is dropped along the way for any reason then the entire 8192 NFS block has to be retransmitted. If you use an NFS xfer size of 32768 bytes then it takes *22* IP fragments to deliver the payload. If any of those fragments is lost along the way it is much more overhead on the server, client, and network to handle the retransmission. Maybe even more importantly there is a substantial "quiet time" imposed by NFS in the face of timeouts and retransmissions that will impact througput considerably. Most recently installed networks and cabling are pretty error free (but you have to keep an eye on them in a consistent fashion like checking the oil in your car). Any non zero values in "ierr" and "oerr" from the output of netstat -i should, in my opinion, should be investigated. There is a very good (but old) paper written by one of the original designers of Ethernet (Rich Siefert) which has a description of NFS over UDP and Ethernet. Good reading, http://wwwhost.ots.utexas.edu/ethernet/pdf/techrept13.pdf The main page is very good, http://wwwhost.ots.utexas.edu/ethernet/ and Charles Spurgeon's Ethernet book is even better. --Gil -----Original Message----- From: Brian Meek [mailto:bmeek@flycast.com] Sent: Friday, April 02, 1999 6:25 PM To: toasters(a)mathworks.com Subject: RE: Slow sequential disk reads on F740 Setting options nfs.udp.xfersize 32768 helped a lot, now were seeing ~25 MB/sec transfers to and from the filer. Why isn't this the default? Brian -----Original Message----- From: Smith, Gil [mailto:gil.smith@netapp.com] Sent: Friday, April 02, 1999 1:38 PM To: toasters(a)mathworks.com Subject: FW: Slow sequential disk reads on F740 -----Original Message----- From: Smith, Gil Sent: Friday, April 02, 1999 4:18 PM To: 'toaster(a)mathworks.com' Subject: RE: Slow sequential disk reads on F740 Hi, You might want to try, filer> options nfs.udp.xfersize 32768 which is a hidden option (doesn't show up when you type options with no arguments). This might be especially usefull in Gigabit Ethernet environments. Regards, Gil -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Thursday, April 01, 1999 5:02 PM To: Brian Meek Cc: toasters(a)mathworks.com Subject: RE: Slow sequential disk reads on F740 On Thu, 1 Apr 1999, Brian Meek wrote: > > I'm not sure this is related, but if you do a nfsstat -m on the client, does > it show the rsize to be 8192 or 32768? Interesting... I was forcing rsize and wsize to 32768 on the mount command line just to be pedantic, but this is what I'm seeing (output edited for brevity): # mount -o vers=3,proto=udp,rsize=32768,wsize=32768 e2.j:/ /j # mount /j on e2.j:/ vers=3/proto=udp/rsize=32768/wsize=32768/remote on Thu Apr 1 16:51:27 1999 # nfsstat -m /j from e2.j:/ Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,acl,rsize=8192,wsize=8192,re tran s=5 > When reading data from our NetApps using our E450's we don't see > anywhere near the same performance as when we read data from our > E450's with our E450's using NFS3 over udp. I've always attributed > this to the client code forcing an rsize of 8192 when connecting to > the filler, and allowing a rsize of 32768 when connecting to > anything else (Sun, Dec, SGI). Has anyone else seen this? It sounds like the NFS server dictates the parameters. I can connect with 32K rsize/wsize using UDP transport between Solaris servers, but only 8K between a Sun and an Netapp, and 16K between a Sun and a FreeBSD machine acting as the server. TCP transport allows me to use 32K block sizes in any server. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

FW: Slow sequential disk reads on F740
by Smith, Gil 02 Apr '99

02 Apr '99

-----Original Message----- From: Smith, Gil Sent: Friday, April 02, 1999 4:18 PM To: 'toaster(a)mathworks.com' Subject: RE: Slow sequential disk reads on F740 Hi, You might want to try, filer> options nfs.udp.xfersize 32768 which is a hidden option (doesn't show up when you type options with no arguments). This might be especially usefull in Gigabit Ethernet environments. Regards, Gil -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Thursday, April 01, 1999 5:02 PM To: Brian Meek Cc: toasters(a)mathworks.com Subject: RE: Slow sequential disk reads on F740 On Thu, 1 Apr 1999, Brian Meek wrote: > > I'm not sure this is related, but if you do a nfsstat -m on the client, does > it show the rsize to be 8192 or 32768? Interesting... I was forcing rsize and wsize to 32768 on the mount command line just to be pedantic, but this is what I'm seeing (output edited for brevity): # mount -o vers=3,proto=udp,rsize=32768,wsize=32768 e2.j:/ /j # mount /j on e2.j:/ vers=3/proto=udp/rsize=32768/wsize=32768/remote on Thu Apr 1 16:51:27 1999 # nfsstat -m /j from e2.j:/ Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,acl,rsize=8192,wsize=8192,retran s=5 > When reading data from our NetApps using our E450's we don't see > anywhere near the same performance as when we read data from our > E450's with our E450's using NFS3 over udp. I've always attributed > this to the client code forcing an rsize of 8192 when connecting to > the filler, and allowing a rsize of 32768 when connecting to > anything else (Sun, Dec, SGI). Has anyone else seen this? It sounds like the NFS server dictates the parameters. I can connect with 32K rsize/wsize using UDP transport between Solaris servers, but only 8K between a Sun and an Netapp, and 16K between a Sun and a FreeBSD machine acting as the server. TCP transport allows me to use 32K block sizes in any server. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Slow sequential disk reads on F740
by Brian Tao 02 Apr '99

02 Apr '99

64MB file on an F740 running 5.1.2, minra=on on that RAID volume. The filesystem is mounted via NFSv3 and UDP transport. Network connection is fast Ethernet via crossover cable. First run is from a Sun E450 reading in the file with dd and 32K block size. Second run is from another E450 (same network config, different NIC on the F740) reading in the same file. Reading a file from disk seems to be exceptionally slow. Reading the same file from cache is faster, but still not close to what I'd expect over an otherwise quiet 100 Mbps link. Is there something I need to tune? CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 19% 455 0 0 92 3890 3639 0 0 0 7 18% 437 0 0 90 3732 3507 0 0 0 7 18% 436 0 0 89 3720 3480 0 0 0 7 16% 364 0 0 74 3109 2922 0 0 0 7 18% 426 0 0 86 3638 3411 0 0 0 7 18% 435 0 0 88 3712 3480 0 0 0 7 [...] CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 12% 560 0 0 122 4708 0 0 0 0 2 19% 1029 0 0 224 8780 0 0 0 0 2 19% 993 0 0 217 8472 0 0 0 0 2 19% 1017 0 0 222 8677 0 0 0 0 2 20% 1025 0 0 224 8746 0 0 0 0 2 19% 1017 0 0 222 8677 0 0 0 0 2 [...] -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

5 9

RE: Server Manager
by Hawley, Rob 02 Apr '99

02 Apr '99

First I assume you are using Domain Authentication. If not, then that is why it does not work. A better way is to use User Manager. Connect to the filer with an account that is a member of the filer's domain Domain Admins group. You can then edit the local Administrators group using User Manager. Remember if you change a group membership that it does not take effect until the user reconnects. Instead of knocking all of cifs down, you can terminate an individual PC. You can tell the group membership of a particular user using cifs sessions -s. You need to be a member of the local administrators or power users group. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > mailto: hawleyr(a)netapp.com <mailto:hawleyr@netapp.com> US Mail: Network Appliance Inc. > Phone: 408-367-3254 2770 San Tomas Expressway > FAX: 408-367-3451 Santa Clara, CA 95051 -----Original Message----- From: Oliver Krause [mailto:okrause@netapp.com] Sent: Tuesday, March 30, 1999 1:03 PM To: 'Bernard Westwood'; toasters(a)mathworks.com Subject: RE: Server Manager Hi, first ensure that your user is a domain admin. If you are in the group "Domain Admins" but you are not DOMAIN\Administrator the edit the file /etc/usermap.cfg in the root volume and map your user to root. Then cifs terminate/restart and it should be possible to access the filers for your user. Oliver > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Bernard Westwood > Sent: Dienstag, 30. März 1999 22:33 > To: toasters(a)mathworks.com > Subject: Server Manager > > > When accessing Server Manager on a NT Server running 4.0 and > NetApp Data > OnTap 5.2.1 does anyone know why "Access Denied" comes up > when any of the > NetApp servers are selected? > > >

1 0

RE: Slow sequential disk reads on F740
by sirbruce＠ix.netcom.com 02 Apr '99

02 Apr '99

On 04/01/99 22:14:49 you wrote: > > >On Thu, 1 Apr 1999, Val Bercovici (NetApp) wrote: > >> 5 data disks or 5 disks including parity (meaning 4 data disks)? Either >> way, that's well below our sweet spot of 14 9GB disks per raid group. > >Wow, I'm discovering my psychic abilities. 14 is exactly the raid group I >chose on our filers. Can you share some data on how NAC arrived at this >number. In our case it just happened that we wanted to have two volumes >as separate as we could make them and we happened to have 4 shelves in >each filer. I think it's derived empirically, although you can make some rough calculations yourself and see when you have a typical "mix" of NFS operations (reads, writers, lookups, getattrs, etc.) it's hard to get more than 100-200 NFS ops per disk, with the filer being in the upper end of that range. Of course as disk drives improve this should as well. Unless you want to set off a very small filesystem that's only going to get limited access, you probably want more disks than that. In other terms of raid group size, I think 14 became an ideal spot because it was a good compromise between low overhead (the more data disks per parity disk you have, the less disk you waste), acceptable raid reconstruction times in case of disk failure (the fewer disks you have, the quicker the reconstruction), and ease of use (it's conventient to think of disks in groups of 7 and 14). Bruce

1 0

RE: Slow sequential disk reads on F740
by sirbruce＠ix.netcom.com 01 Apr '99

01 Apr '99

On 04/01/99 00:34:34 you wrote: > >Hi Brian, > >> 64MB file on an F740 running 5.1.2, minra=on on that RAID volume. >> The filesystem is mounted via NFSv3 and UDP transport. Network >> connection is fast Ethernet via crossover cable. > >What are results with minra=off? Wouldn't that be a better setting for >large sequential files? That was my first reaction as well. >> First run is from a Sun E450 reading in the file with dd and 32K >> block size. Second run is from another E450 (same network config, >> different NIC on the F740) reading in the same file. Reading a file >> from disk seems to be exceptionally slow. > >I agree, this seems slow. How many disks in that volume/raid group in >question? Could that file somehow be very fragmented? And this was my second. Try creating the file "fresh" (via copy) and then reading it (later, after you're sure it's no longer in cache) and seeing the results. Also, I suspect having fewer than 7 drives could be a limiting factor. >> Reading the same file from cache is faster, but still not close to >> what I'd expect over an otherwise quiet 100 Mbps link. > >Can't agree with you here. You're getting roughly 8.4 MB/s over link >capable of about 10-12.5 MB/s max. Not optimal, but not bad either... And this was my third. The in-cache response doesn't seem to be out of line given other possible variables. Bruce

3 3

Upgrade F330 to Data ONTAP 5.2.1
by Pierre Maubert 01 Apr '99

01 Apr '99

All, I plan to upgrade 6 F330 to 5.2.1, in order to be y2000 compliant. According to the documentation in need first to upgrade the firmware to 1.9_i . Current version of firmware are: 1.6_i or older. Current version of OS are: 4.0.1c, 4.3.4, 4.3.5. Is anybody aware of problems , or traps i need to take care with this new version. Thanks, -- Regards, Pierre . +------------------------------------------------------+ | Pierre Maubert, Sys_Admin Texas Instruments France | | email:p-maubert@ti.com | | msgid:PIMO Pager: 0606498982 | | Tel: +33 49322.2681 Fax: +33 49202.4669 | +------------------------------------------------------+

2 2

Re: Upgrade F330 to Data ONTAP 5.2.1
by Jason D. Kelleher 01 Apr '99

01 Apr '99

In message <370326E9.55BB03B3(a)ti.com>, Pierre Maubert writes: >All, > >I plan to upgrade 6 F330 to 5.2.1, in order to be y2000 compliant. >According to the documentation in need first to upgrade the firmware >to 1.9_i . >Current version of firmware are: 1.6_i or older. >Current version of OS are: 4.0.1c, 4.3.4, 4.3.5. > >Is anybody aware of problems , or traps i need to take care with >this new version. > >Thanks, > >-- >Regards, >Pierre . You might want to take a look at the (rather long) list of bugs fixed in 5.2.1P2 to see if any of them concern you. And I was told a 5.3 release is comming out shortly. Tech Support is very helpfull if you call and ask them about possible issues/problems with an upgrade. The firmware upgrade is trivial. I also beleive the minimum memory requirements increased in version 5.x. Good luck, jason

1 0

Re: Anybody using the NetCache software? (fwd)
by Luke Gain 01 Apr '99

01 Apr '99

> > As to performance; the software is pretty good. > Benchmarks that HP performed show that NetCache-HPUX > runs about 8X faster than Squid on FreeBsd. > Wow...that tells us alot(NOT)...How about NetCache vs Squid on the SAME box/os. -Luke

3 2

Diagrams..Visio et-al...
by Mohler, Jeff 31 Mar '99

31 Mar '99

Anyone know of a simple figure I can toss into Visio to represent a F760 (or any other filer for that matter).

3 2

RE: NAC SAN
by mds＠gbnet.net 30 Mar '99

30 Mar '99

On Tue 30 Mar, 1999, "Adams, Christian" <Adams_Christian(a)emc.com> wrote: > Hey Dave Hitz - > <tongue-in-cheek> Hey Christian Adams. Is there an EMC-specific mailing list we can all join and be obnoxious on? Please? </tongue-in-cheek> Otherwise please alter how you frame your contributions so they're less irritating to read. I find that you're coming across with a very arrogant tone which, I'm sorry to say, precludes my giving you, or your company, much credence. The same comes across in EMC marketing and interviews in the press so perhaps it's one of those go-get-'em, can-do, East coast culture things. It's one of the reasons I enjoy talking to NetApp folk - they're almost always willing to listen rather than butting in, and almost always very considered in their replies and statements. > > Loved your EMC bit, > /Christian Adams > EMC > >-- End of excerpt from "Adams, Christian"

2 1

RE: Server Manager
by Muhlestein, Mark 30 Mar '99

30 Mar '99

Oliver is right that you have to be an administrator, but there is no need to be "root" for server manager. You have to be in the filer's BUILTIN\Administrator group. By default, the "Domain Admins" group for the domain the filer is installed into is the only member of BUILTIN\Administrators. You can add others as needed using user manager and specifying "\\filer" as the domain to work on. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Oliver Krause [mailto:okrause@netapp.com] Sent: Tuesday, March 30, 1999 1:03 PM To: 'Bernard Westwood'; toasters(a)mathworks.com Subject: RE: Server Manager Hi, first ensure that your user is a domain admin. If you are in the group "Domain Admins" but you are not DOMAIN\Administrator the edit the file /etc/usermap.cfg in the root volume and map your user to root. Then cifs terminate/restart and it should be possible to access the filers for your user. Oliver > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Bernard Westwood > Sent: Dienstag, 30. März 1999 22:33 > To: toasters(a)mathworks.com > Subject: Server Manager > > > When accessing Server Manager on a NT Server running 4.0 and > NetApp Data > OnTap 5.2.1 does anyone know why "Access Denied" comes up > when any of the > NetApp servers are selected? > > >

1 0

Server Manager
by Bernard Westwood 30 Mar '99

30 Mar '99

When accessing Server Manager on a NT Server running 4.0 and NetApp Data OnTap 5.2.1 does anyone know why "Access Denied" comes up when any of the NetApp servers are selected?

2 1

RE: NAC SAN
by Sam Schorr 30 Mar '99

30 Mar '99

Yes, I realize there are tremendous hurdles. It will also take a vendor who builds their own solution ala Network Appliance, or even Sun. They would have to marry it to specific OS/hardware (Sun could "easily" do this, while Netapp would have to sell the internal fibre or SCSI card to go in the server as well as the disk arrays). All that aside, there would be no point if the current network technologies make it unnecessary to separate the two very different traffic requirements. I believe, though, that such an offering would hold tremendous value to large sites, particularly as virtual sites on the internet increase (many servers/services appearing as one). -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Monday, March 29, 1999 5:55 PM To: 'toasters(a)mathworks.com' Subject: RE: NAC SAN On Mon, 29 Mar 1999, Sam Schorr wrote: > Why not a box with a special OS (ala WAFL) that runs on what servers > recognize as a fibre hub, intercepts the SCSI calls from all attached > servers, and does all the nifty stuff needed to make the SAN(?) look like > locally attached storage? Advantage? Separate file I/O from TCP session > traffic but still allow file sharing in some form or another. I thought about this, but if you really want to take it to the extreme, then the switch has to know exactly how it is used. Imagine any "erver" box that uses mirroring or striping. Unless you know exactly how data is placed you won't be able to recognize how the filesystem looks. Then there is caching. Usually systems don't worry about cache coherency on locally attached storage. The assume (fairly correctly too) that they are the only ones using the storage. Tom

2 1

Re: sm_recover messages?
by mds＠gbnet.net 30 Mar '99

30 Mar '99

Yeah. mv the files aside, delete them or truncate them to 0 bytes with cat </dev/null > [file] Don't, whatever you do, put spurious characters in them, you'll crash your filer. Bugs have been logged for both the problem and the sm file crashes and fixes are in the pipe. Can you tell we suffer(ed) from both these problems? 8) The problem arises when clients with open mounts (and probably locks on files) quietly go away, followed by the filer itself rebooting and trying to fond those now-dead clients. It never gives up unless you butcher the sm/* files, carefully! Hope that helps.

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