toasters

toasters@lists.teaparty.net

13520 discussions

RE: Toasters and WINS
by Nail, Larry 28 Mar '01

28 Mar '01

If you have downlevel clients (NT, 9x), you'll need still need WINS, however the W2K implementation is quite a bit more stable & less inclinded to corrupt than the NT version. -----Original Message----- From: Tim Longo [mailto:tlongo@avaya.com] Sent: Wednesday, March 28, 2001 2:27 PM To: toasters(a)mathworks.com Subject: Toasters and WINS We are migrating users to a Windows 2000 domain. Wondering if anyone has run a Netapp in a Win2k environment without WINS? We will probably try to add the domain, and domain crontroller entries to the toaster hosts file?

1 0

dump -L - ndmp w/ Legato
by jlbreyfo＠collins.rockwell.com 28 Mar '01

28 Mar '01

Hello folks, Does anyone know how (or know why I wouldn't want to) to use the -L option to the dump command when using Legato NDMP. The -L is supposed to do a backup via file system as opposed to inode table. This would seem to me to make restores (esp. of directories) alot quicker. I'm sure there would be a significant hit on the backups, but maybe tolerable. I haven't seen any mention in Legato or documentation of -L in NetApp docs. Thanks in advance. John Breyfogle

2 1

RE: File too large ?
by Charles Randall 28 Mar '01

28 Mar '01

Two things, 1. NFS v2 doesn't support files larger than 2 GB. Switch to NFS v3. Only very recently has the Linux NFS implementation supported NFS v3 (see below). 2. Can you work with files larger than 2 GB using the same tools on a local file system? If so, NFS v3 will help. If not, you'll have to find out how to "large file enable" your applications. On Solaris, look at the "largefile" and "lfcompile" manpages. For more info on the Linux NFS implementation, see this page http://nfs.sourceforge.net/ No offense intended to our resident Linux aficionados, but I cringed when I read most of it. Charles -----Original Message----- From: Hubbard, Dan [mailto:dhubbard@websense.com] Sent: Wednesday, March 28, 2001 12:10 PM To: toasters(a)mathworks.com Subject: File too large ? All; We are using a ONTAP v 6.0.1 and are NFS mounting Solaris and Redhat Linux boxes. We are in the process of creating some large text files and cannot either gunzip and/or create files greater than 2GB's. We have bumped up our maxfiles and set the options nfs.v2.df_2gb_lim ON without any luck. Our friends in tech support at Netapp told me that I must upgrade to 6.0.1r3 to fix this. Any input from the field ? Also, any input on issues with NFS and Redhat Linux kernel 2.2.14 (RH7.0) ? Thanks

1 0

Toasters and WINS
by Tim Longo 28 Mar '01

28 Mar '01

We are migrating users to a Windows 2000 domain. Wondering if anyone has run a Netapp in a Win2k environment without WINS? We will probably try to add the domain, and domain crontroller entries to the toaster hosts file?

1 0

W2k profile and Netapp
by Tim Longo 28 Mar '01

28 Mar '01

Greetings: Currently on my NT 4 domain, we map a user share on the netapp,(also the unix home), to a drive letter in the NT account profile. This is in the form of: Z: \\toaster\share We have noticed that with Windows 2000, they want this share to be mapped in the form of: Z: \\toaster\share\folder This makes migrating people from the old convention to the new convention quite a bit of work. Has anyone else encountered this, and how do you work around this problem? Needless to say, we are extremely angry with Microsoft. Thanks

1 0

File too large ?
by Hubbard, Dan 28 Mar '01

28 Mar '01

All; We are using a ONTAP v 6.0.1 and are NFS mounting Solaris and Redhat Linux boxes. We are in the process of creating some large text files and cannot either gunzip and/or create files greater than 2GB's. We have bumped up our maxfiles and set the options nfs.v2.df_2gb_lim ON without any luck. Our friends in tech support at Netapp told me that I must upgrade to 6.0.1r3 to fix this. Any input from the field ? Also, any input on issues with NFS and Redhat Linux kernel 2.2.14 (RH7.0) ? Thanks

1 0

ndmp backup
by neil lehrer 27 Mar '01

27 Mar '01

hi, i am testing ndmp backup solutions on my f760[part of a cluster] running 5.36r2, against a spectralogic treefrog. questions: 1. once backup started sysstat 1 showed cpu util at about 40% during mapping and initially 100% during dump for about 2-3 minutes and then much lower numbers since then. is the 100% util normal? nothing else is running, system is not prod yet. 2. can ait2 tapes be "bad" fresh out of the wrapper? the software would not handle 1 of the tapes, backup vendor said tape was probably bad. what is the ndmp response to a "bad" tape? 3. is the chip in the ait tapes used by ndmp backup? thanks

3 2

RE: NAS Wars
by Joe Luchtenberg 27 Mar '01

27 Mar '01

Mr. Benway goes into some detail regarding disk IO based on rotation speeds and access times: "...The component numbers work out to be 3ms average rotational delay (10,000 rpm), random mode access times of 5.2ms (read mode) or 6ms (write mode, more precise alignment required), and a minimum track-to-track seek time of .6ms (reads) or .9ms (writes). On a filer, where reads usually far outnumber the writes, use 5.2ms for the random mode calculation, and .6ms for the sequential. This will get you close enough. Hence, for random reads, the aggregate read access time is 8.2ms, yielding 122 IOPS (1,000ms / 8.2ms). For sequential mode, the aggregate read access time will be 3.6ms, yielding 278 IOPS (1,000ms / 3.9ms)." Earlier in the article he used these disk figures (122 and 278 IOPS) to ascertain potential total system disk IOPS for the configurations posted at the SPEC website by NetApp. System 1 (his nomenclature) had 16 data disks, and therefore 16x122 = 1952 IOPS for random reads or 16x278 = 4448 IOPS for sequential. System 4 had 34 data disks for 4148 and 9452 IOPS. Somehow, Mr. Benway makes the leap to use these data points as a basis for comparison between EMC and NetApp. Since the IP4700 configurations posted on the SPEC website by EMC have many more disks (90) than either NetApp config, he suggests the paucity of RAM available to the EMC IP4700 (1.5GB) accounts for the difference: "...So why does System 5 (the EMC IP4700) falter in comparison to {NetApp}? ...EMC has only half of the useable RAM as available to the F840. Hence, there isn't enough RAM (work space) on the EMC to take advantage of its expected higher disk throughput." The EMC cluster has 500% of the disk IOPS potential (90/18 = 5) but only 30% higher throughput (11,451/8820 = 1.3*; OPS/sec statistics from his Figure 1 excerpt of SPECsfs97 results) than a single filer, and he explains this away with memory? Should one assume that if the EMC IP 4700 had the same memory as the F840 (3GB) that it would serve data 500% faster than the NetApp?! *Note: Used Systems 1 and 5 for comparison to have a common protocol for the benchmark (UDP-3). Only after making this dubious claim that hardware primarily accounts for the performance differences does he suggest that software may have something to do with the performance disparity (in very vague terms): "...You would also have to know more about the EMC operating system and file system efficiency versus that of the NetApp in order to come to any further conclusions." BINGO! There's your answer, Mr. Benway. NetApp is a software company, not a hardware company. You referred to NetApp's whitepaper TR3002 in your article, but I think you would have done well to check TR3001 first (www.netapp.com/tech_library/3001.html). Particularly the sections on RAID and system performance/disk bottlenecks: "...the FFS (the Berkeley Fast File System) was designed to optimize writes for one file at a time. As a result, it typically writes blocks for different files to widely separated locations on disk... Since the Berkeley FFS doesn't understand the underlying RAID 4 layout, it tends to generate requests that are scattered over the data disks, causing the parity disk to seek excessively. WAFL writes blocks in a pattern designed to minimize seeks on the parity disk." This excerpt from TR3001 only addresses how file data is laid out on disks. It does not even touch on other disk seek activity required by other file systems. Most of us have probably seen the PowerPoint slide that depicts the drastic reduction of disk seeks required to retrieve or write data because of the way WAFL manages disk space when compared to other file systems, including the CrosStor file system implemented by EMC in their IP4700 ( ? please correct me if I'm wrong there). NetApp filer performance is driven by the software, and the hardware is designed to deliver that performance through best value off-the-shelf configurations (as Mr. Benway noted, it is not critical to have the fasted CPU available in the market today to deliver this performance). I readily admit that I am strongly biased toward NetApp, and I hope this doesn't seem to be EMC-bashing. If I have something wrong here, I would like to know. My customers count on me to stay ontop of the storage market to make appropriate recommendations to address their requirements. Right now with regard to performance NetApp has a unique advantage with Data ONTAP and WAFL, as I see it. Of course, performance is just one issue, and many times a minor one in determining what is the best storage solution for a given requirement. Just my $.02. Thanks for providing a forum for me to ramble. :-) Joe Joe Luchtenberg Dataline, Inc. 757.858.0600 757.285.1223 (cell) 757.858.0606 (fax) joe.luchtenberg(a)data-line.com www.data-line.com -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Friday, March 23, 2001 6:01 PM To: toasters(a)mathworks.com; emcnas(a)mathworks.com Subject: NAS Wars A recent article in Server/Workstation Expert, entitled "NAS Wars," might be of interest here: http://swexpert.com/CB/SE.C11.MAR.01.pdf I applaud Alan's efforts at applying a bit of math and a lot of common sense to such a sticky issue. This isn't meant to start a flame war, though something I read as a kid on a package of firecrackers comes to mind: "Light fuse, and run away fast!" ;) Personally, I would suggest reading the first three sentences of the conclusion first, and with that perspective, read the rest of the article. Read that way, the methods and assumptions and calculations and configurations make for good detective work, IMHO. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: NAS Wars
by Tom "Mad Dog" Yergeau 26 Mar '01

26 Mar '01

Don't you know if you're using an EMC box, you're only supposed to run home directories on a NAS box? I mean, if you want to run Oracle or Exchange, obviously you need a Symmetrix. Or at the bare minimum, the SAN half of the IP4700. Remember, EMC folks think everyone who runs a database on NAS is insane. But it would be interesting to see the results nevertheless. MD -----Original Message----- From: grey jolly [mailto:greyjolly@yahoo.com] Sent: Sunday, March 25, 2001 8:01 PM To: Bruce Sterling Woodcock; sg; Chris Thompson Cc: emcnas(a)mathworks.com; toasters(a)mathworks.com Subject: Re: NAS Wars I think the article brings out a good point. Why can't we get a simple one to one test of the two boxes withthe same amount of useable storage, and as similar a configuration overall as possible? That way we can really see the price and performance of each. Up to now all we have is hearsay and Marketing BS. I don't think we're comparing apples to apples yet. For example, I suggest we test five real world applications. 1) Test both in a home directory configuration 2) Test both running a common Oracle application 3) Test both running a Lotus Notes application 4) Test both running exchange 5) Test both simulating recovery form an Oracle outage and an Exchange outage and how long it takes to recover. Let the best box win : ).

1 0

NAS Wars
by Todd C. Merrill 26 Mar '01

26 Mar '01

A recent article in Server/Workstation Expert, entitled "NAS Wars," might be of interest here: http://swexpert.com/CB/SE.C11.MAR.01.pdf I applaud Alan's efforts at applying a bit of math and a lot of common sense to such a sticky issue. This isn't meant to start a flame war, though something I read as a kid on a package of firecrackers comes to mind: "Light fuse, and run away fast!" ;) Personally, I would suggest reading the first three sentences of the conclusion first, and with that perspective, read the rest of the article. Read that way, the methods and assumptions and calculations and configurations make for good detective work, IMHO. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

5 5

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