toasters December 1998

toasters@lists.teaparty.net

32 participants
32 discussions

Re: 2 questions.
by guy＠netapp.com 29 Dec '98

29 Dec '98

> Ok..what is the maximum file size allowed in later versions. Thats what I > was looking for. 2^44 bytes (2^32 4K file system blocks). (I'm not sure what the maximum *filer* size is, but it may be less than that, in which case files of that size would have to be holey files.)

3 4

RE: Gb-ether and Extreme (Re: Routing Anomaly..fixed (and how))
by Shaw, Kevin 28 Dec '98

28 Dec '98

I direct connect a sun E6500 to a F760 using Gb ethernet. I have an Oracle data base on this filer... No problems. -----Original Message----- From: mds(a)gbnet.net [mailto:mds@gbnet.net] Sent: Monday, December 28, 1998 2:22 PM To: Bruce Walker Cc: sirbruce(a)ix.netcom.com; toasters(a)mathworks.com Subject: Re: Gb-ether and Extreme (Re: Routing Anomaly..fixed (and how)) On Thu 24 Dec, 1998, Bruce Walker <bmw(a)visgen.com> wrote: > mark writes: > > > > So, if I was hoping for high performance for a news spool on a filer [...] > > I'd use Gb-ether into an Extreme switch. > > Have you actually done this? I have a 720 with Gigabit ether No, I've never had my hands on such advanced networking kit, though I know of a site using them happily enough. The principle is sound...but theory doesn't necessarily matter a fig when your working to a deadline, for example. I'd be surprised if the problem was a complete show-stopper, and I too would love to know if anyone has good or bad experiences using NetApp's with Gb-ether they would like to share. >-- End of excerpt from Bruce Walker

1 0

Re: Gb-ether and Extreme (Re: Routing Anomaly..fixed (and how))
by mds＠gbnet.net 28 Dec '98

28 Dec '98

On Thu 24 Dec, 1998, Bruce Walker <bmw(a)visgen.com> wrote: > mark writes: > > > > So, if I was hoping for high performance for a news spool on a filer [...] > > I'd use Gb-ether into an Extreme switch. > > Have you actually done this? I have a 720 with Gigabit ether No, I've never had my hands on such advanced networking kit, though I know of a site using them happily enough. The principle is sound...but theory doesn't necessarily matter a fig when your working to a deadline, for example. I'd be surprised if the problem was a complete show-stopper, and I too would love to know if anyone has good or bad experiences using NetApp's with Gb-ether they would like to share. >-- End of excerpt from Bruce Walker

1 0

2 questions.
by Jaye Mathisen 27 Dec '98

27 Dec '98

Using 4.3.4 on a F540, 256MB RAM, 8MB NVRAM. I'm using the oh-so-secret method of using SQL server on a filer... Initial tests with small databases have been great. Big problem: I can't create a database device larger than 4GB's on the CIFS share. Anything up to 4 is fine, anything over, uh huh. Local drives can handle larger, but that's not where I want to be... 1) Any ideas on whats wrong here? 2) Anybody else using a filer under SQL server?

2 3

Re: 2 questions.
by guy＠netapp.com 27 Dec '98

27 Dec '98

> > If so, the problem is that we don't support files >4GB in releases prior > > to ONTAP 5.1. > --- > > And what about later versions (just because the question is so obviously > un-answered)? If we didn't support it in 5.1 or later versions, I would have said "the problem is that we don't support files >4GB" without adding "prior to ONTAP 5.1" - I assumed, apparently incorrectly, that it was obvious from the way I stated it....

1 0

Re: Routing Anomaly..fixed (and how)
by mds＠gbnet.net 24 Dec '98

24 Dec '98

On Wed 23 Dec, 1998, sirbruce(a)ix.netcom.com wrote: > The only other thing I haven't seen mentioned is number of disks. This can > be a limiting factor in performance, particularly towards the lower end. > Having more disks that you need will not make you appreciably faster, but > having too few will be very noticeable. Oh too true, especially as data on disks is becoming relatively less accessible in high-throughput applications. Brian Wong's book has a lucid explanation for why more spindles of lower capacity can make a hell of a lot more sense than fewer, bigger disks. > > In current filers, I don't know what the right ratio would be. I used to > use about 100-200ops/disk as a rule of thumb, but of course it depends on the > kid of ops. If you have an array of 21-28 disks, then I doubt that's the > limiting factor. If you only have 14, you might consider adding some more > to the filesystem and seeing if that improves your write throughput. Adding > more NVRAM is of course good if possible for your filer. I'd speculate that the new multiple RAID group feature in DOT5 also has an important performance dimension, besides the reliability aspects. For writes, and degraded reads, the fewer disks in a RAID group the higher the performance I'd expect in the RAID calculation. Now, assuming a volume has a number of RAID groups, I'd presume the WAFL filesystem will still consume blocks over all the RAID groups and make attempts to write whole stripes into each RAID group, thereby gaining the fullest bandwidth available to the platters, given the calculations that have to be done on the data. One interesting thing to note is how much the filer needs to read from disk while performing write-intensive work. If the filer isn't reading much from disk at all, then you're laying down fresh data stright from memory and the machine will be running at full tilt. If there's quite a lot of reading going on then the machine is having to work harder to lay the data down on the platters. This is more likely to happen when the volume is on the full side, has been running with some degree of churn for a while and contains relatively small files. Ie old data being removed to be replaced by new data - as in usenet news spools. So, if I was hoping for high performance for a news spool on a filer I'd be thinking of a 760 with many 9GB disks (the smallest available I believe) in an unclustered configuration. I'd also play with the RAID group sizes until I'd struck a rough balance between the costs, the performance and the resilience. I'd use Gb-ether into an Extreme switch. I'd toy with using the no-atime option, perhaps play with both NFS2 and NFS3 to see which gave best performance. And I'd use different hosts for spooling the news, and for serving the news...but that's application level stuff and far less easy to work on and comment on. >-- End of excerpt from sirbruce(a)ix.netcom.com

3 2

Re: Routing Anomaly..fixed (and how)
by sirbruce＠ix.netcom.com 24 Dec '98

24 Dec '98

The only other thing I haven't seen mentioned is number of disks. This can be a limiting factor in performance, particularly towards the lower end. Having more disks that you need will not make you appreciably faster, but having too few will be very noticeable. In current filers, I don't know what the right ratio would be. I used to use about 100-200ops/disk as a rule of thumb, but of course it depends on the kid of ops. If you have an array of 21-28 disks, then I doubt that's the limiting factor. If you only have 14, you might consider adding some more to the filesystem and seeing if that improves your write throughput. Adding more NVRAM is of course good if possible for your filer. I'd also do the standard systems reviews, making sure that your interfaces are running at the right speeds, that the routing on the filer is set up correctly (although for ethernet response packets I don't think those are routed - then again, that may have changed; it's complicated depending on the actual media type), and so on. Still, 20MB/sec with your network configuration doesn't sound bad to me. I'm not sure you'll be able to do too much better than that. If you want more, try slapping a gigabit ethernet card in the puppy. :) Bruce

1 0

Re: Routing Anomaly..fixed (and how)
by Keith Brown 23 Dec '98

23 Dec '98

>Yes, I have 32Mb of RAM, but at 50% or 10 seconds, the NVRAM flushes. I >only buffer 16Mb before it takes a data dump *grin* if I understand >correctly. You do understand correctly, but while the "flush" is occuring (actually, it's called a consistency point, or CP for short), the other 16 MB of NVRAM is still being put to good use journaling new file system modifications being made by clients. In other words, you and your filer are enjoying a full 32 MB of "benefit" from the NVRAM. In other words, it is *all* being used for something. There is no waste here! :-) >In a clustered environment, I just use that other half of NVRAM >to buffer to the other box instead of mirroring myself in case of a write >failure (power, etc). In an unclustered environment, you are using that "other half" of NVRAM now. When you cluster two systems together though, well... we have a white paper that tells you what happens much better than I can here: http://www.netapp.com/technology/level3/1004.html >Two clients, both on separate 100Mb interfaces, creating spool files for my >news services using 'dd if/dev/zero of=<filename> count=<x>'. Hmmm. Benchmarks don't get much more write intensive than this, do they. :-) So large sequential writes then. Fair enough. >When I was seeing about 1300 NFSops/Sec and 18-20MegaBytes of input traffic, >the CPU on the F760 would peg. Yes. Writing is a more CPU intensive function than reading. Lots of shunting things into NVRAM and performing of RAID calculations etc... None of that needs to be done on reads. Anyway, a *sustained* agregate of ~20 MBytes/Sec write performance sounds excellent to me. You only have ~25 MBytes/Sec worth of pipes coming into the filer (2 x 100Mbits/Sec), and the thing is stashing things away onto disks, with RAID, at 80% of the theoretical maximum rate at which data can arrive at its doorstep from the network. Nope... nothing to be ashamed of there I'm afraid. The F760 is a beast and a half! ;-) Keith

1 0

Re: Routing Anomaly..fixed (and how)
by Keith Brown 22 Dec '98

22 Dec '98

Jeff... I'm glad your routing anomilies got sorted out. Regarding your subsequent mail... >Also, Ive noticed a max input rate of about 20Mb/sec into the filter, then >the CPU tops out on my F760. > >I understand that the NVRAM can only process 16Mb at a time before the >system really gums up, but I did expect a little more input performance. > >Does anyone have any official or un-official comments on this? If your F760 is still of the unclustered variety (which I'm sure it is, as we haven't quite yet shipped the F700 series cluster release of Data ONTAP) then you will currently be enjoying the full 32 MB capacity of your NVRAM. In a clustered pair of filers however, each systems NVRAM is mirrored to the other, meaning that each filer's individual *effective* NVRAM capacity for the file system(s) that they are individually journaling is halved to 16 MB. They each still physically have 32 MB of NVRAM of course. On the performance front, I'm afraid you would need to better stipulate precisely what you mean by a "20 Mb/sec input rate" for me or anyone else at NetApp to be able to make a useful comment on whether it looks about right or not. How are you determining this number? Is this MBytes/Sec or MBits/Sec? How many clients are you using, and through what networks are they talking to the filer? What software are you running? What is that software really doing on the I/O front? How are the timings being made? Etc... Keith

4 3

ndmpcopy for linux?
by Gil Smith 22 Dec '98

22 Dec '98

Hi, Has anyone compiled and used the ndmpcopy utility on Linux? If so can you pass on any required changes directly to me. --Thanks, Gil

2 1

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 December 1998