toasters

toasters@lists.teaparty.net

13515 discussions

Re: Sun Client Maximum Throughputs (again)
by mds＠gbnet.net 06 Jan '00

06 Jan '00

On Wed 7 Jan, 1930, Darrell Fuhriman <darrell(a)grumblesmurf.net> wrote: > Brian Tao <taob(a)risc.org> writes: > > > Do you find that with 2 x 400-MHz CPU's that you have enough > > cycles to stream 600 Mbps off the gigabit ethernet and sustain high > > throughput to your tape drives? > > Yep, plenty. :) Of course, in our testing we've found that Sun > does much better at this than other platforms, say DEC, which > just crapped itself entirely. :) <nosey> Heh. Have you been extra careful balancing your sbus/pci cards? What tape units do you use? What host adaptors too? Did you try IBM's, SGI's or HP's, out of sheer curiosity..? </nosey> > Darrell >-- End of excerpt from Darrell Fuhriman -- -Mark ... an Englishman in London ...

1 0

Re: Sun Client Maximum Throughputs (again)
by Darrell Fuhriman 06 Jan '00

06 Jan '00

mds(a)gbnet.net (mark) writes: > These two do what? > > ndd -set /dev/ge adv_pauseTX 0 > > ndd -set /dev/ge adv_pauseRX 0 Disable Link Level Flow Control. According to the docs, you shouldn't need to muck with them (TX defaults to 0, RX to 1) unless you're silly and aren't using your Gb card in the 66Mhz slot. I think the concept is of LLFC is silly when you're using only TCP like we are, hence the forcibly disabling. > Much bigger buffers than I got for 100Mb/s networks, makes sense. Have you > found these value by experiment or otherwise? > > ndd -set /dev/tcp tcp_recv_hiwat 262144 > > ndd -set /dev/tcp tcp_xmit_hiwat 262144 Honest truth is, I can't remember. I think it was a combination of chats with sun, and our own experimenting. > How come this is set so low? > > ndd -set /dev/tcp tcp_xmit_lowat 2048 That's actually the default on 2.6, maybe it's a hold over from earlier OS revs? > How do each of these three things affect things? > > ndd -set /dev/tcp tcp_wscale_always 1 This enables the wscale option. ;) Essentially it allows the window size to exceed the original TCP default of 64k. I suspect it also puts a minimum size of 64k on the window size as a side effect. > > ndd -set /dev/tcp tcp_tstamp_always 1 This places a (sender determined) timestamp in each packet, which is simply returned to it by the receiver in the ACK. The result of this is that you get more accurate RTT calculations. This means fewer unnecessary retransmits, and better congestion control in fat pipes. > > ndd -set /dev/tcp tcp_rexmit_interval_max 60000 I'm not sure why this is set to what it is (it's 1/4 of the default), we put it in at Sun's recommendation. Docs say: If you are running your Solaris 2.6 system with a large TCP window and you experience slowdowns during high network traffic, you should decrease the TCP default maximum retransmission timeout interval variable Which doesn't help much. :) Darrell

1 0

Re: Sun Client Maximum Throughputs (again)
by Darrell Fuhriman 06 Jan '00

06 Jan '00

Brian Tao <taob(a)risc.org> writes: > Do you find that with 2 x 400-MHz CPU's that you have enough > cycles to stream 600 Mbps off the gigabit ethernet and sustain high > throughput to your tape drives? Yep, plenty. :) Of course, in our testing we've found that Sun does much better at this than other platforms, say DEC, which just crapped itself entirely. :) Darrell

1 0

Can a C720 take a 4GB controller and shelf?
by Jaye Mathisen 06 Jan '00

06 Jan '00

I'm eyeballing swapping the FCAL drives on my new 720 with the 4GB shelves on my 630's and 540's, to get the higher cap drives on the 630. I don't think I can put FCAl on the 540, so it's a moot point. Just thinking about it. Have a spare 720, so I can always try it I guess.

1 0

Re: Sun Client Maximum Throughputs (again)
by Darrell Fuhriman 06 Jan '00

06 Jan '00

mds(a)gbnet.net (mark) writes: > What I'm thinking of is that AFAICR tcp_xmit_hiwat and tcp_recv_hiwat > are set to 8192 (bytes) and the equivalent *lowat's to 2048. This is We're using this on our 2x400 MHz E450's and we see ~60MB/s using switched gigabit. ndd -set /dev/ge adv_1000fdx_cap 1 ndd -set /dev/ge adv_1000hdx_cap 0 ndd -set /dev/ge adv_1000autoneg_cap 0 ndd -set /dev/ge adv_pauseTX 0 ndd -set /dev/ge adv_pauseRX 0 ndd -set /dev/tcp tcp_recv_hiwat 262144 ndd -set /dev/tcp tcp_xmit_hiwat 262144 ndd -set /dev/tcp tcp_xmit_lowat 2048 ndd -set /dev/tcp tcp_wscale_always 1 ndd -set /dev/tcp tcp_tstamp_always 1 ndd -set /dev/tcp tcp_rexmit_interval_max 60000 Note these are dedicated backup servers, so the very high tcp_X_hiwait may not be appropriate if you're not doing lots of bulk data transfer. The tcp_tstamp_always is a big win. Darrell

3 2

Re: Sun Client Maximum Throughputs (again)
by mds＠gbnet.net 06 Jan '00

06 Jan '00

On Wed 7 Jan, 1930, Darrell Fuhriman <darrell(a)grumblesmurf.net> wrote: > mds(a)gbnet.net (mark) writes: > > > What I'm thinking of is that AFAICR tcp_xmit_hiwat and tcp_recv_hiwat > > are set to 8192 (bytes) and the equivalent *lowat's to 2048. This is > > We're using this on our 2x400 MHz E450's and we see ~60MB/s using > switched gigabit. That's pretty respectable! Could you go through how some of these settings help - I'm not 100% clear on some of these meself: These three pin the duplicity of the line, fair enough. > ndd -set /dev/ge adv_1000fdx_cap 1 > ndd -set /dev/ge adv_1000hdx_cap 0 > ndd -set /dev/ge adv_1000autoneg_cap 0 These two do what? > ndd -set /dev/ge adv_pauseTX 0 > ndd -set /dev/ge adv_pauseRX 0 Much bigger buffers than I got for 100Mb/s networks, makes sense. Have you found these value by experiment or otherwise? > ndd -set /dev/tcp tcp_recv_hiwat 262144 > ndd -set /dev/tcp tcp_xmit_hiwat 262144 How come this is set so low? > ndd -set /dev/tcp tcp_xmit_lowat 2048 How do each of these three things affect things? > ndd -set /dev/tcp tcp_wscale_always 1 > ndd -set /dev/tcp tcp_tstamp_always 1 > ndd -set /dev/tcp tcp_rexmit_interval_max 60000 > > Note these are dedicated backup servers, so the very high > tcp_X_hiwait may not be appropriate if you're not doing lots of > bulk data transfer. > > The tcp_tstamp_always is a big win. Tantalising - I'd like to know more. > Darrell > >-- End of excerpt from Darrell Fuhriman -- -Mark ... an Englishman in London ...

1 0

Netapp w. multiple NIC in WINS ?
by Johan Gillquist 05 Jan '00

05 Jan '00

Hi, I have installed a quad ethernet NIC i my 720 and I wonder how it will present it self in the NT Domain. Does any one know how to be sure trafic goes to the correct interface ? How does WINS react on a NT/Netapp host with multiple NIC's ? My NT servers are on the same subnet as the "e1a" interface and NFS clients on the "e0". Regards /Johan

2 1

RE: Sun Client Maximum Throughputs (again)
by Fox, Adam 05 Jan '00

05 Jan '00

You've probably already checked this, but back from my Tech Support days, we always told folks to manually set speed and duplex on both sides. Speed is less of an issue because if the speed isn't matched, you'd be passing far less good data than what you are seeing, but duplex mis-matches can certainly cause very bad performance over 100Mb/s interfaces. The other big thing is retransmissions of 32K UDP requests. However, since these are cross-over cables I hope this isn't the issue. I have seen this on very busy switched networks that 32K UDP can really get slow due to nasty retransmission times. Hope this helps. -- Adam Fox > I didn't see any satisfactory answers to this the last time > around, but I'm doing a bit of benchmarking for a killer tape backup > server (streaming ~60MB/sec to tape). I have an older Sun E450 with 2 > x 250-MHz CPU's and a Quad Fast Ethernet NIC in one of the PCI slots. > > qfe0 is directly attached to an idle F740, and likewise for qfe1 > to another idle F740. Please tell me I should be able to see more > than an aggregate 10 MB/s doing dumps over rsh with that setup? I'm > shuffling the dump streams off to /dev/null so local disk speed is not > an issue. On another system, a 2 x 300-MHz E450 with two single-port > NIC's, I'm able to pull about 15 MB/s total. Does the Sun QFE just > suck, and I should stick to individual single-port NIC's? > > I want to lead up to a 4 x 450-MHz E420R with Gigabit Ethernet, > and hope I can achieve 50 MB/s or more from eight F740's. Has anyone > tried this configuration? > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >

1 0

Re: Sun Client Maximum Throughputs (again)
by mds＠gbnet.net 05 Jan '00

05 Jan '00

On Wed 7 Jan, 1930, Brian Tao <taob(a)risc.org> wrote: > On Tue, 29 Jun 1999, Brian Pawlowski wrote: > > > > I thought I could use a 2 x 400MHz Ultra Enterprise E250 > > with a new Sun GbE card in it as a killer client, and > > I find that with V3 32KB UDP packets, the sucker > > rolls over at > > > > ~30 MB/s > > > > with 2 CPUs pinned at 99% in system time. > > > > This *sucks*. > > I didn't see any satisfactory answers to this the last time Ditto. <snip> > NIC's, I'm able to pull about 15 MB/s total. Does the Sun QFE just > suck, and I should stick to individual single-port NIC's? Have you tweaked up the high water and low water marks for transmission and reception, out of interest? What I'm thinking of is that AFAICR tcp_xmit_hiwat and tcp_recv_hiwat are set to 8192 (bytes) and the equivalent *lowat's to 2048. This is predicated on 10Mb/s ethernet networks. Not 100Mb/s contentionless networks. This is true in Sol2.5.1, but I've not checked in other Solarises.. They can be checked with: ndd /dev/tcp tcp_xmit_hiwat ndd /dev/tcp tcp_recv_hiwat ndd /dev/tcp tcp_xmit_lowat They can be set higher with the machine up using: ndd -set /dev/tcp tcp_xmit_hiwat 32768 ndd -set /dev/tcp tcp_recv_hiwat 32768 ndd -set /dev/tcp tcp_xmit_lowat 24576 or with appropriate lines in /etc/system. UDP can also be checked and set the same way: ndd /dev/udp udp_xmit_hiwat ndd /dev/udp udp_recv_hiwat ndd /dev/udp udp_xmit_lowat ndd -set /dev/udp udp_xmit_hiwat 32768 ndd -set /dev/udp udp_recv_hiwat 32768 ndd -set /dev/udp udp_xmit_lowat 24576 I'm wondering if people seeking higher NFS performance might want to investigate these settings? (I'd be interested in seeing what people have their nfs:nfsv3_nra set to too 8) All this is straight from the Sun FDDI 5.0 manual, but we're talking 100Mb/s either way, and I've used these settings before. I'm not in a position to test whether they'll have any benefit - or whether Solarises >2.5.1 choose better defaults to start with. Perhaps you can check and set me straight either way? I'm guessing but I think there might be a little mileage in setting them higher still for Gb/s networks. But the faster CPU's and better NIC smarts will offset some buffering requirements in your proposed system. At least they *should*. 8) The FDDI manual goes on to talk about setting the socket options..but that's a whole other kettle of fish. Using netstat -k <interface> might yield interesting numbers, in particular norcvbuf and noxmtbuf which are the buffer allocation failure counts. In Sol2.6 and on, according to Cockfroft at least. If the above defaults are in place make a note of the interrupts and any info from vmstat 5, mpstat 5 and netstat -k that looks interesting as the settings stand doing a dump, *then* change them and rerun the test. I've got a bit of an axe to grind about the hme and qfe interfaces on Sun's.. and this would be v. interesting to me. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > >-- End of excerpt from Brian Tao -- -Mark ... an Englishman in London ...

1 0

Sun Client Maximum Throughputs
by beepy＠netapp.com 05 Jan '00

05 Jan '00

Do any of our customers out there have some measurements of Sun client throughput? I thought I could use a 2 x 400MHz Ultra Enterprise E250 with a new Sun GbE card in it as a killer client, and I find that with V3 32KB UDP packets, the sucker rolls over at ~30 MB/s with 2 CPUs pinned at 99% in system time. This *sucks*. In an experimental filer setup reading from memory (all cached data) the F760 CPU is at 20%. I am totally client bound. Has anyone sized Sun clients out there? Are the PCI clients dogs? Is the new GbE card from Sun a loser? Should I go grab a new Alteon card for the Sun? What is your killer high performance client? It seems a function of the Sun E250 - 100BaseT seems to scale only to 30 MB/s before running out of CPU... Broken-hearted in Amsterdam, beepy

9 13

Re: Budtool / backup sw Mailing-List??
by dnb＠ccs.neu.edu 05 Jan '00

05 Jan '00

Michael Coxe <mc(a)com21.com> writes: > Is there a mailing-list for this sort of discussion? > I'm looking for one, either Budtool specific or UNIX/NT > generic (@ enterprise level). > > If not, do others feel a need for one? We'd be very interested in one as well (and would be willing to host if it didn't exist already). Anyone else? Peace, dNb

4 5

W2000 and CIFS auth with unix passwd
by Stephen C. Losen 04 Jan '00

04 Jan '00

We are currently using unix passwd authentication for our CIFS logins. The filer is a NIS client. It works great because we use a single NIS passwd database for our unix boxes and the filer. The unix boxes all NFS mount the filer, so our users can access their home directory either via CIFS or via telnet to unix. The same password works for both methods. The whole reason we bought the filer was to provide this unified "home directory service." We are concerned about W2000 because no release we have tried works with this setup. We realize that clear text passwords must be enabled for this to work. There is even a registry entry for enabling this, but W2000 doesn't seem to pay any attention to it. We have over 25,000 accounts in our NIS database. We have no problems with W95, W98 or NT, so it seems dreadfully unfair to us that Microsoft would suddenly pull the plug on such an essential (to us) feature. I'm wondering if anyone else on this list knows anything about whether Microsoft plans to address this issue. Is anyone else out there using unix authentication for CIFS logins? How are you going to deal with W2000? I know we could work around this problem with a domain controller, etc., but that involves a lot of $$ for the NT box, NT account licenses, and maintaining a parallel user database. Or perhaps we can do it with Samba somehow. But our setup right now is so simple and painless. Admittedly it is less secure with clear text passwords, but we haven't turned off telnet, ftp, pop, imap, etc., yet and they use clear text passwords, too. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

y2k
by fubar＠mathworks.com 04 Jan '00

04 Jan '00

Some of you may be wondering why you're just now getting messages from Jan 1st and on. No, it's not sendmail's lovely queue processing. In fact, it was hypermail not being happy with they year 2000. Damn thing spun in a loop forever... Anyway, I've upgraded. As a result, I've had to completely rebuild the toasters archive. A quick glance and it looks happy. The search, on the other hand, I'm not so sure about... I'll have to play around a bit with that. If anyone notices any problems, please let me know. The archive is located at http://teaparty.mathworks.com:1999/toasters.html Kendall..

4 3

RE: CIFS delays.
by Sanborn, Ed 04 Jan '00

04 Jan '00

Actually I fixed the problem by sync'ing my duplex settings. They were mis-matched with the network port that the filer was connected to. -Ed Ed Sanborn (978) 691-6496 Manager of Computing Infrastructure Newbridge Networks Inc. 5 Corporate Drive Andover, MA. 01810 Fax (978) 687-4442 http://www.northchurch.net <http://www.northchurch.net/> -----Original Message----- From: Sanborn, Ed [mailto:esanborn@northchurch.net] Sent: Tuesday, January 04, 2000 3:03 PM To: 'toasters(a)mathworks.com' Subject: CIFS delays. Hi folks, I have an F720 running 5.2.2. I am experiencing significant delays with the CIFS protocol. NFS is fine. Any troubleshooting suggestions? -Ed Ed Sanborn (978) 691-6496 Manager of Computing Infrastructure Newbridge Networks Inc. 5 Corporate Drive Andover, MA. 01810 Fax (978) 687-4442 http://www.northchurch.net <http://www.northchurch.net/>

1 0

Re: Netapp w. multiple NIC in WINS ?
by Brian Rice 04 Jan '00

04 Jan '00

> I have installed a quad ethernet NIC i my 720 and I wonder how it will > present it self in the NT Domain. Does any one know how to be sure > trafic goes to the correct interface ? How does WINS react on a > NT/Netapp host with multiple NIC's ? My NT servers are on the same > subnet as the "e1a" interface and NFS clients on the "e0". I used to have multi-homed F630's running CIFS. The multi-homing was mostly a historical accident; the network environment was such that traffic's choice of interface didn't have performance implications. Anyway, the big problem was that NT 4 revisions prior to Service Pack 4 have a NetBIOS bug that's exposed when you try to play with a multi-homed server. Every so often, NT clients would get a "The network path cannot be found" error when they tried to access a share from a NetApp. When you did a net view from a DOS prompt, you'd get System error 53 has occurred. At the time, there was an NT patch; the fix nowadays would be to upgrade to a non-ancient service pack. Brian

1 0

Re: 9gig drives
by Patrick Day 04 Jan '00

04 Jan '00

I have an unpopulated 9Gb shelf with 1 power supply that was attached to a 740 that i we no longer need. if you are interested, let me know and i'll check on a price. --patrick day patrick.day.b(a)bayer.com mathworks owner-toasters <owner-toasters(a)mathworks.com> on 01/04/2000 10:51:53 AM To: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 cc: Subject: 9gig drives Does anyone have a source for Netapp 9 gig drives and disk trays for a f720. We are being told form our reseller they can only get 18gig drives now. Thats a problem for us since we just want a couple more to expand our current raidset. Not to build another raidset of larger drives. Or to format the 18gig drives to 9gig to use in the current raid set. -Cameron Slye

1 0

Re: Goodies (was wack)
by chris＠cecil.muscat.com 04 Jan '00

04 Jan '00

Nick Hilliard wrote: >Perhaps this is o/s revision dependent, but 4.x can have many millions of >objects. Bzzzzt. 256bytes RAM per object so on a C760 only 4M objects. We were hoping to cache pure html (which would never be more than a few K in size) and 200M documents was the minimum number of documents for things to be usefull to us. [sigh] -- Chris Good - Dialog Corp. The Westbrook Centre, Milton Rd, Cambridge UK Phone: 01223 715006 Mobile: 07801 788997 http://www.dialog.com

3 2

"Wac"-ing the WAFL?
by E Hunter 03 Jan '00

03 Jan '00

Greetings. I'm brand-spankin' new to this list, so please please please excuse me if I landed this question in the wrong space/time. I'm looking for infomation on NetApps because the company I'm working for is considering a 760 for our network. I have been told by someone who is only vaguely familiar with the NetApps that the filesystem has to be maintained in some way by running a _wac_ command, but I have been unable to find any information on such a command in a week of searching . Can anyone fill me in on the use of this _wac_ command , what it does, how often it needs to be done, and whehter or not the filer requires downtime to do it? Thanx. -- Eric Hunter System Administrator _______________________ eric(a)gigaton.com

22 35

Netcache object capacities (was Re: Goodies (was wack))
by jrg＠acm.org 02 Jan '00

02 Jan '00

On Fri 31 Dec, 1999, chris(a)cecil.muscat.com (Chris Good) wrote: >BTW who else thinks it sucks that you can only have a million or >so objects in a netcache. bang went another couple of sales when >we discovered that... I've not played with one in ages, but can that really be right? The Tech Specs sheet says that the C740 maxes at 990GB, (ok, probably because that's what the filer can do), so for an average 13kB object size that gives space for: 990*1024*1024/13 = approx 79 000 000 objects. Even for the C720 (4 disks)'s more reasonable max 27GB, that's around 2 million. The C720/486GB is 39 million or so. Surely you wouldn't have a system that would waste all that disk space? To look at it another way, 990GB of disk and only one million objects would mean the average file size could be as high 1MB. The aforementioned specs, and the rest of the docs, have nothing to say on the matter though. James.

2 1

RE: volcopy and snapmirror performance
by Walters, Mike 31 Dec '99

31 Dec '99

We did this transfer on a site to migrate around 150GB data between F630 to F760 - it went though at around 14-15MB/s (50+GB/hour) on a direct cross-over GbE connection. Although it's not a requirement, I would sugggest using the same versions of ONTAP - we hit a hardware problem on one filer which aborted the transfer, & there was a problem with aborted transfers when the filers were on 5.2.1 and 5.2.3 resp. - we upped them both to 5.2.3 & all was well ;-) Cheers Mike > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of kevin graham > Sent: 30 December 1999 11:54 > To: toasters(a)mathworks.com > Subject: volcopy and snapmirror performance > > > > We're looking at moving 287gb (~10.7m inodes) worth of data > from a 630 to > a clean volume on a 760. > > To schedule the downtime, I need to know if anyone has > ballpark figures > for calculating the tiem for a volcopy. The filers are well > connected > (gbit ether on both of them), and I can sacrafice big chunks of > performance to make this go in a timely manner. (the > 100mbit interfaces > are inactive as well, if those should just be strapped together) > > Later on, we're looking at trying to snapmirror 536gb > (~17.2m inodes) > spread pretty evenly across two volumes between two > locations. Are there > numbers available on the approximate overhead of the > snapmirror protocol > (delta bytes * overhead), and how often it would be > feasible to run it > (I'd prefer something in the neighborhood of 5-10 minutes). > > The best numbers I could find on NOW were "36GB/hr will > drive the cpu to > 100%" without any reference to the filer model, cache sizes > (the filer > does do read-aheads, right?), inode density, etc... > > thanks. > > ..kg.. > >

2 1

RE: Goodies (was wack)
by Mohler, Jeff 31 Dec '99

31 Dec '99

Depends. If it's a round of golf or a T-shirt..its a safe bet, feel free to produce a P.O.. But if it's a leather jacket...hold out for the jacket, because between the jacket and the gold, you KNOW the salesguy _wants_ that round of golf. Isn't there a Dilbert about this..yet? :-----Original Message----- :From: Alan R. White [mailto:arw@tipper.demon.co.uk] :Sent: Thursday, December 30, 1999 12:44 PM :To: toasters(a)mathworks.com :Subject: Re: Goodies (was wack) : : :Wonder how many sales folk actually believe that there is a direct :relationship between giveaways and meeting their end of year targets? : :....or is it me thats being naive.....

1 0

toasters
by TomArlington 30 Dec '99

30 Dec '99

toasters

1 0

RE: "Wac"-ing the WAFL?
by Mohler, Jeff 30 Dec '99

30 Dec '99

Yes, but in the spirit of keeping the post simple for our new user, I didnt bring in complexities of how a F720 and lower work, or clustering. So yes, my post is somewhat inaccurate outside the scope of the reply itself. :-----Original Message----- :From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] :Sent: Thursday, December 30, 1999 8:51 AM :Cc: toasters(a)mathworks.com :Subject: RE: "Wac"-ing the WAFL? : : : :On Wed, 29 Dec 1999, Mohler, Jeff wrote: : :> When a series of writes comes into the box, it is buffered :*im making this :> simple*, and it flushed out to disk (on a 760) ever 10 :seconds, of when 16Mb of :> data is in the buffer (NVRAM). : :This is inaccurate, I believe in clustered machines with 32MB :NVRAM it is :8MB. I think the general rule is half of NVRAM dedicated to the :particular filer. : :Tom :

1 0

RE: "Wac"-ing the WAFL?
by Mohler, Jeff 30 Dec '99

30 Dec '99

:RAID 0. I know, I know, it sounds almost suicidal but as I :said speed is more :important in this instance than recovery. We'll be testing :this 760 against :an Auspex, which can be configured to use RAID 0, so I was :wondering if the :NetApps could also do this. --- Actually, the way RAID4 is used in conjunction with WAFL, really looks and feels like RAID0, just with a parity write at the end. WAFL removes the problem on a UFS type filesystem of having that single parity drive just thrash to tiny bits, taking the stripe performance with it. When a series of writes comes into the box, it is buffered *im making this simple*, and it flushed out to disk (on a 760) ever 10 seconds, of when 16Mb of data is in the buffer (NVRAM). A single stripe (or series of stripes) is then written in a _very_ optimized manner using the WAFL filesystem, and a single parity calculation/write is created per stripe. I direct you to a document Mr. Hitz wrote at http://www.netapp.com/tech_library/3001.html for more details. I have every confidence you will enjoy our performance in your testing.

3 2

volcopy and snapmirror performance
by kevin graham 30 Dec '99

30 Dec '99

We're looking at moving 287gb (~10.7m inodes) worth of data from a 630 to a clean volume on a 760. To schedule the downtime, I need to know if anyone has ballpark figures for calculating the tiem for a volcopy. The filers are well connected (gbit ether on both of them), and I can sacrafice big chunks of performance to make this go in a timely manner. (the 100mbit interfaces are inactive as well, if those should just be strapped together) Later on, we're looking at trying to snapmirror 536gb (~17.2m inodes) spread pretty evenly across two volumes between two locations. Are there numbers available on the approximate overhead of the snapmirror protocol (delta bytes * overhead), and how often it would be feasible to run it (I'd prefer something in the neighborhood of 5-10 minutes). The best numbers I could find on NOW were "36GB/hr will drive the cpu to 100%" without any reference to the filer model, cache sizes (the filer does do read-aheads, right?), inode density, etc... thanks. ..kg..

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