toasters

toasters@lists.teaparty.net

13515 discussions

Start a nNew thread

Anybody running 5.0?
by Jaye Mathisen 18 Mar '98

18 Mar '98

NOW lists it in early release, but I haven't had the guts to try it yet.

1 0

DLT 4000(SUN) & F230
by Jimy Liu 18 Mar '98

18 Mar '98

Hi : Is anyone using Sun's DLT4000 with F230 ? Is there anything I need to notice ? Jimy

1 0

None
by yingchih＠mitac.com.tw 17 Mar '98

17 Mar '98

subscribe toasters

5 4

FP'98 + IIS 4.0 + NT4 + CIFS
by Brian Tao 13 Mar '98

13 Mar '98

Does anyone have some experience setting up an NT4/IIS 4.0 Web server with the FrontPage extensions, using a Netapp as the data store? According to Microsoft (and supported by our own tests), FrontPage will *not* work to a network share. In fact, many Microsoft server products will lose much of their functionality if they are not run on local disks. I'm pretty much convinced this is an NT issue and not a Netapp one (since we can't get FrontPage to work even when sharing a filesystem from another NT box). What are the alternatives? NFS on NT? We asked a Microsoft IIS engineer how MS handles the problem of distributed servers, and his response was "Oh, we just replicate all our data". :-/ -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

2 2

Re: FP'98 + IIS 4.0 + NT4 + CIFS
by Rajiv Khemani 13 Mar '98

13 Mar '98

> That's another approach we can take, but since IIS is the only >Microsoft component left in the equation, Microsoft probably won't >like that much (this hosting agreement is part of a larger deal >between our two companies). ;-) Brian, I know of a few filer customers who are using IIS with the filers using CIFS. No one is using the Frontpage 98 extensions to IIS, as they don't work over a network share. As Mike Patchen pointed out, Microsoft has promised to fix this in Frontpage 99. If this is really important to you, you should bring that up as a requirement to Microsoft. Andy Schulert <andyschu(a)microsoft.com> is the person to send your needs to. The people successfully using IIS with filers are currently using FTP - to allow users to upload web pages to their personal directories. With the filers, we also have created a special NT utility that "effectively" allows large # of directory quotas for this special situation. This is so you can do quotas for your web-hosting users. Using quotas on filers is apparently the only scalable quota solution available for NT today (according to people who use them). We can polish this utility for wider usage, if we see a lot of demand for web-hosting quotas. Regards, -Rajiv ---- Rajiv Khemani Group Marketing Manager Network Appliance, Inc. Direct: 408-367-3758 Fax: 408-367-3670 HTTP: http://www.netapp.com

1 0

Re: FP'98 + IIS 4.0 + NT4 + CIFS
by sirbruce＠ix.netcom.com 13 Mar '98

13 Mar '98

On 03/12/98 23:39:54 you wrote: > >On Thu, 12 Mar 1998 sirbruce(a)ix.netcom.com wrote: >> >> The alternative is pretty clear to me... don't use IIS/FrontPage if >> it requires you to redo your entire infrastructure or approach in >> order to support it. > > I don't think that's an option, unfortunately. The challenge is >to give customers what they need, rather than what they think they >want. They want NT. What they need is an easy way to manage the >content of their Web site and the e-mail of their employees, without >having the first clue about the Internet. I can sympathize. I'm sure everyone here does. We've ALL been there. :) And I'm not trying to start that tired old UNIX vs. NT argument. There are circumstances where NT is a fine solution. All I'm saying is that if the application isn't up to your needs, perhaps one should consider a different application. (And if that means a different platform, then you have reason to question NT in the first place.) >Writing our own software to >do that would take a lot longer than buying an off-the-shelf product. >Maybe we'll go with FrontPage with Apache on Solaris, or perhaps we'll >find that NFS on NT with the Netapp does the job for us. I wouldn't be surprised if IIS/FrontPage have the same troubles over NFS on NT, but I confess I don't know for certain as I've never tried it. Bruce

3 3

Re: FP'98 + IIS 4.0 + NT4 + CIFS
by sirbruce＠ix.netcom.com 13 Mar '98

13 Mar '98

On 03/12/98 15:22:50 you wrote: > > Does anyone have some experience setting up an NT4/IIS 4.0 Web >server with the FrontPage extensions, using a Netapp as the data >store? According to Microsoft (and supported by our own tests), >FrontPage will *not* work to a network share. In fact, many Microsoft >server products will lose much of their functionality if they are not >run on local disks. > > I'm pretty much convinced this is an NT issue and not a Netapp one >(since we can't get FrontPage to work even when sharing a filesystem >from another NT box). What are the alternatives? NFS on NT? We >asked a Microsoft IIS engineer how MS handles the problem of >distributed servers, and his response was "Oh, we just replicate all >our data". :-/ The alternative is pretty clear to me... don't use IIS/FrontPage if it requires you to redo your entire infrastructure or approach in order to support it. Bruce

3 3

postscript: ndmpcopy
by Alexei Rodriguez 11 Mar '98

11 Mar '98

Well, my migration of content between filers is complete and I have a few odd tidbits I thought I would share. - ndmpcopy is an interesting (but frustrating) program. It is great to be able to kick off a dump piped to a restore on a remote filer via ndmp. level0's work well. The time estimates are pretty accurate (I got 30GB in 7 hours) if a bit slow. The irritating aspect of it is that ndmpcopy "hangs" after the completion of the program (at least when the source filer is 4.2a and the destination filer is 4.3.1) and the /etc/dumpdates file is not updated. This makes incrementals impossible. - gnu find and cpio are your friend for incrementals. I did a level0 dump (with ndmpcopy) 2 days before my cut-over. The night of the cut-over, I did a find (with mtime -2) piped to cpio (-dump) onto the new location. It took under 1/2 an hour to do most everything. Had I parallelized the finds a bit more, it would have probably been around 15 minutes to complete. Having completed the migration, here is what the before/after stats are: before: f540/256MB ram/8MB NVRAM; 3000-4000 NFSops avg, 80-100% cpu util, 1 min cache after: f540/256MB ram/8MB NVRAM; 1500-2000 NFSops avg, l0-20% cpu util, 25 min cache f630/512MB ram/16MB NVRAM; 1800-2200 NFSops avg, 20-30% cpu util, 27 min cache The f540 contains tools, logs and home directories. The f640 contains web content. My users were immediately able to notice a significant speed improvement (we use alot of server side includes which lead to alot of IO) when dealing with certain areas of our websites. I would like to thank Beepy (from NetApp) for helping me in this endeavor. I hope might be of use to someone at some point. Alexei

1 0

Successfull NDMP Stories
by Timothy A. McCarthy 10 Mar '98

10 Mar '98

Hi ther everyone. I have a customer that *wants/needs* to use NDMP. I know for a fact that BudTool works. Has anyone else had successful attempts with other packages? like Veritos? or even OpenVision? thanks! -- Timothy A. McCarthy --> System Engineer, Eastern Region. Network Appliance http://www.netapp.com 301-230-5840 Office \ / Page Me at: 301-230-5852 Fax \/ 800-654-9619

1 0

VS: AIT vs. DLT7000
by Tronrud, Asle EDNO 09 Mar '98

09 Mar '98

In Norway we agree with Mr. Alexei regarding support of the AIT streamer from SONY or Seagate (called Sidewinder for Seagate) on the filers. It is correct that the DLT7000 (on the brochure) has the possibilities of slightly more sustained transfer the the AIT, but in real life the AIT slightly outperforms the DLT 7000 - and in addition the AIT's are 60% cheaper! In Norway the pricing at the moment is approximately DLT7000 85000 NOK and the AIT 35000 NOK. Big shock people wanting the AIT's. The AIT's are using the most powerful compression algorithm in the market (ALDC developed by IBM). Compression ratio is in average 1:2.6, which gives in average approx. 65 GB on each media. DLT's and Mammoth in average 1.8 (Mr Gremban, TI below is reporting an average on appr. 1.7) The sustained transfer is increasing to the same 1:2.6 ratio (7.8 MB/sec) In addition the AIT has a Metal evaporation and Carbon coating on the media which makes the media even more robust (archival time on media guaranteed from SONY > 30 years) Memory In Cassette (MIC) on the AIT makes the funniest difference: Media Load Time 10 sec - DLT 45 sec. (4,5 times faster) Average File Access 23 sec - DLT 60/68 sec (3 times faster) Regarding transfer rate, whether the AIT or the DLT7000 has any problems recieving the data from the NetApp filers because of the following: Since most of the filers installed usually is containing thousands and millions of small files instead of a few big files - this (whether one likes it or not) leads to an significant decrease in backup throughput. This happens not only on NetApp filers, but on all kinds of machines serving files out there. The MB/min output number will anyway be lower than the number handled by the AIT and DLT. So AIT is 60% cheaper, has 3-5 times faster access/media load time and arhival time in the media is more than 30 years. This is what is interesting to the customer base. You could buy two AIT streamers instead and place them both locally on the NetApp's - maybe this will do something with the numbers, I am not sure. By the way, AIT-2 is coming in the autumn this year. 130GB capacity and transfer rate 12MB/s compressed. Please support the AIT's! Rgds Asle Tronrud _______________________________________________________ Asle Tronrud Sales Engineer Storage Berendsen Data Tel. +47 2208 8500 Div. av Berendsen Components AS Dir. +47 2208 8569 Konows gt. 8 Fax. +47 2208 8595 P.O.Box 9376, Groenland Mob. +47 9001 2906 N-0135 Oslo, Norway Email: aslet(a)berendsen.no http://www.berendsen.no _______________________________________________________ -----Opprinnelig melding----- Fra: Bjørnsen, Paal H. EDNO Sendt: 13. februar 1998 09:19 Til: Tronrud, Asle EDNO Emne: VS: AIT vs. DLT7000 -----Opprinnelig melding----- Fra: Steve Gremban [SMTP:gremban@msp.sc.ti.com] Sendt: 13. februar 1998 07:39 Til: toasters(a)mathworks.com Emne: AIT vs. DLT7000 Alexei, We are using DLT7000 (5-10 MB/sec depending on compression) drives which actually outperform the Sony AIT (3-7.8 MB/sec depending on compression). We are not quite seeing 2:1 compression, we get about 60GB compressed on each 35GB tape. -Steve Gremban gremban(a)ti.com ----------------------------------------------------------------------- Previous message follows: I would like to see AIT supported; we currently use DLT, but as our backup needs are approaching 300GB (well, as soon as I get my new filer), DLT is not cutting it (backup/restore times are too long). Also, the media is a huge problem (DLT's are not all too happy with a drop...). I suspect that these additional drives will be supported eventually. Alexei -----------------------------------------------------------------------

2 1

ndmpcopy?
by Alexei Rodriguez 04 Mar '98

04 Mar '98

Anybody used this? ftp://ftp.ndmp.org/ Just curious Alex

1 1

Re: ndmp copy?
by Mark D Simmons 02 Mar '98

02 Mar '98

NDMPCopy is a little bit creaky but allows you to control explicitly which directories get copied. It's very useful. When I say it's a bit creaky I mean I've observed some strange and uneven behaviours from it performance wise. It's never threatened our data though and so we still use it without qualms. We've also used the prototype technology Dave alluded to and that goes like the proverbial off a shovel! I think we were seeing 20+GB/hr between a F330 and an F520. It makes a full copy of a filer (ie we had to be careful to boot with the right OS floppy and such, one of the few times you have to care which CPU you're using) no more, no less. NDMPCopy has gone as fast as 2.5MB here, over FDDI, the prototype software boosted that to almost 5MB/s and we basically had a full filer copy in an hour and a half! Sorry this mail isn't very timely, but I hope it's useful to someone.

2 1

Back-up software.
by Finnerty, Patrick [GAL:8041:EXCH] 28 Feb '98

28 Feb '98

I would like to hear what solutions people have implemented for backing up their Filers. We have a Breece Hill Q2.15 tape library (1 DLT 4000 drive and 14 slots). We are planning to have a look at BudTool, but at £10k-£15k it seems pretty expensive for something that swaps your tapes in and out and dumps data to them. Pat. Patrick Finnerty, Nortel, Mervue Business Park, Galway Phone: +353-91733658 FAX: +353-91756050 Email: galpf01(a)nortel.ie

2 1

Re: Back-up software. [BudTool, Networker] [~long]
by Don Glascock 28 Feb '98

28 Feb '98

> I would like to hear what solutions people have implemented for backing > up their Filers. A very good question. We recently bought a small filer, an F230 max'ed out on drives, with plans over the next two years to fill it to capacity. We migrated file service to it from a DEC Alpha running Digital Unix. This mechanism worked well, but was starting to feel slow, and we wanted to add cleaner file service to our growing NT user base. Samba looked useful, but a bit scary in terms of support. We've been running DEC's version of Networker on the Alpha, and considered NFS-mounting the filer's disk space, which would allow us to continue on in that path. But loading the network at night was somewhat unattractive, though not much of a problem in our shop. Attaching our EXB-210 8mm jukebox with two drives directly to the filer looked more interesting, and BudTool seemed to be the best choice at the time, because of its ability to speak NDMP to our tape jukebox. Also, we have had problems with Networker's media and file databases, and BudTool promises to eliminate this problem. After getting BudTool in house, we discovered that configuring this package to suit our wishes was not going to be easy: configuration files are located together in one subdirectory, but they must be edited by hand (whereas Networker provided full gui's for everything), and many are called ".whatever", which of course is designed to hide these configuration files from casual "ls"'ing. Hiding configuration files in a permission-protected directory makes little sense to me, and was somewhat of a pain. Further, it took us a while to figure out how to configure the software to speak to the jukebox, and once that was done, we found that the few full backups we attempted would hang somewhere along the way for hours, after which they would wake up and keep going. Our network configuration is relatively simple-minded and I would describe it as very robust; none of the other ~50 devices on our network seemed to experience any problems at the same time that Networker was upset about something. The backups that did run smoothly failed to fill our tapes: our drives are (I think) 8505XL's, which do take the 7Gb/14Gb-compressed 160m 8mm tapes, yet Networker called them "full" after putting at most 4.5Gbytes on them. By this time our interest in BudTool was waning. When we tried file restores, we found that the recovery tool could list all of the instances of a given file to choose from, but the recovery window could not tell you which of three or four tapes in a full backup a given file was stored. When we timed backing up via BudTool versus Networker's NFS backups, we found that NFS was slightly faster in our level-0 tests than BudTool which was driving the filer-attached jukebox via NDMP. We were also told that many of the configuration problems we were experiencing resulted from the fact that we did not have a barcode reader in our jukebox. We investigated getting a barcode reader, but found that we would have to abandon our tape-naming schemes to support one of the many different label standards. While we've always known a barcode reader would speed up tape identification even in use with Networker, it had never been a big issue with us in the past. The folks at BudTool report that the tapes-not-filling problem could probably be fixed by adjusting some blocking-factor parameters buried in some of the config files. Perhaps this would also have improved speed of the backups. Also, there are rumors that if backups speak NDMP-1 instead of NDMP-2, they are less-likely to hang. In either case, these solutions seemed indicative of future problems: we never worried about blocking factor issues with Networker, and issues about reliability across protocol versions is definitely an unwelcome topic with respect something like backups which require resillience and sturdiness. Our problems with Networker surround the fact that neither DEC nor Legato presented us with a "care and feeding" document for their software. After doing a fair amount of digging, we have developed procedures that are run by cron to keep the databases in order and in good shape, so we have decided for now to stick with Networker. While we continue to use the automounter on our Unix systems, we added manual mounts to another directory on our Alpha through which the backups are made, and we added an entry to /sbin/{init.d,rc3.d} to issue these mounts at boot time, lest we back up empty mount points. Next year we hope to switch to another media for backups, and plan to check out the Veritas product, which is said to speak NDMP by that time. We would also like to see how BudTool changes over time to become easier to configure and use. The Networker product as sold through DEC that we are running on Digital Unix 3.2c is not Legato's most recent release by any means, so we would be interested in seeing that next year as well, though we keep hearing fluctuating timetables regarding their ETA for NDMP. Don Glascock -- Donald S. Glascock Mailstop GU-1016 Special Purpose Processor Development Group Mayo Foundation Rochester, MN 55905 Glascock.Donald(a)Mayo.EDU +1.507.284.1850 +1.507.284.9171 (fax) http://www.mayo.edu/sppdg/sppdg_home_page.html "No matter where you go, there you are."

1 0

100BaseT Query - Experiences?
by beepy＠netapp.com 26 Feb '98

26 Feb '98

I was wondering if it was against the rules to ask this alias about their experience with 100BaseT and filers. 1. What switch do you use? 2. What clients do you use on 100BaseT? 3. What filer and how much disk and NVRAM? 4. If you have ever done performance tests against the filer, what type of tests are you running, and roughly what results are you seeing? 5. Are you running with autonegotiation on: (1) filer (2) clients (break out by vendor as necessary) If you disabled auto-negotiation, why? What were the symptoms? 6. Have you experimented with half and full duplex and matching end to end? 7. Has anyone engaged in or worked with a client vendor in client-side tuning? What was your experience? 8. How many are looking at moving in the future to installing on the filer: (1) ATM (2) Gigabit Ethernet (3) FDDI :-) I'll try to pitch in my experiences after some feedback. I hate affecting the experiment too much. Oh yeah, I almost forgot! subscribe toasters beepy

2 1

lists@mathworks.com
by Mike Bosch 24 Feb '98

24 Feb '98

subscribe ---------------------------------------------------------------------------- ------ Mike Bosch Regional Manager Network Appliance Australia - New Zealand Phone: 61-41-728-7345 Email: mbosch(a)netapp.com ********************************************************************* FAST SIMPLE RELIABLE MULTI-PROTOCOL Forbes "200 Best Small Companies" PC Week "Ferrari of File Servers" ********************************************************************* ---------------------------------------------------------------------------- ------

5 4

Re: Snapshot behavior
by Daniel Quinlan 22 Feb '98

22 Feb '98

Arnie Thompson <arnie(a)netapp.com> writes: > When you delete files, the space formerly accounted for in the active file > system now gets accounted for in the .snapshot area. Snapshot space > consumed grows as you delete or modify files, and the more you change the > larger the snapshot area becomes; think of snapshots as measuring the > "delta" in a file system. It would really be great if there was a snapshot deletion daemon that could delete the oldest standard (hourly, nightly, and weekly snapshots only) snapshot(s) when the snapshot usage goes above a certain number. So, "snap" could do a "snap highwatermark" command or something like that in a similar manner to the "snap reserve" command. - Dan

2 1

Anyone using third party drives/shelves
by Marc Nicholas 21 Feb '98

21 Feb '98

Subject says it all: anyone doing it? Any success or horror stories? Any caveats? TIA. -marc -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" vox://416.979.9000 fax://416.979.8223 http://www.hippocampus.net

6 9

User list
by pwilson＠pdc.com 20 Feb '98

20 Feb '98

I would like to be included on the user list. _/_/_/_/ _/_/_/_/ _/_/ Paul J. Wilson _/ _/ _/ _/ _/ _/ Federal Rep _/_/_/ _/ _/ _/ 610-265-3300 x125 _/ _/ _/ _/ 610-265-2165 FAX _/ _/_/_/_/ _/_/_/ email: pwilson(a)pdc.com

1 0

Re: Snapshot behavior
by Arnie Thompson 20 Feb '98

20 Feb '98

Hi Mike, When you delete files, the space formerly accounted for in the active file system now gets accounted for in the .snapshot area. Snapshot space consumed grows as you delete or modify files, and the more you change the larger the snapshot area becomes; think of snapshots as measuring the "delta" in a file system. Eventually the Netapp will free up space as the snapshots expire. If you need the space back right now you can delete snapshots manually via console commands. Do a "snap list" at the console to obtain a list of snapshots, and you'll get an idea of which snapshots are taking up the most space. Generally you want to start deleting the oldest snapshots first. You can delete one or more snapshots by using the "snap delete <snapshot name>" command, which will return space to the active filesystem as long as your overall snapshot utilization exceeds 100% of the snapshot reserve. This sounds a little complicated, but do a "df" on the filer after each snapshot deletion and check out the effect on active and snapshot utilization percentages. Regards, Arnie At 08:54 AM 2/20/98 -0800, Mike Mueller wrote: >We are moving a large amount of files onto our NetApp but first we had to >delete a lot of files to make space for the new files. As the files are >being deleted, the .snapshot is growing and seemingly there will not be >enough space for the new files and the now bloated .snapshot. We're kind of >new at this but we so far have not been able to verify that the space >seemingly taken up by the bloated .snapshot will be released as needed to >make room for the new files. > >Will the NetApp release space from .snapshot to make room for new files, or >do we need to somehow manually get rid of the .snapshot? > >Sorry if this is a dumb question but the move is currently running and I'm >not sure that I'll be able to find the answer before the NetApp runs out of >space. > >Thanks, > >-- Mike > > > > >

1 0

Re: ndmp copy?
by Daniel Quinlan 20 Feb '98

20 Feb '98

Dave Hitz <hitz(a)netapp.com> writes: > The NetApp sales engineers have a tool that is much faster than NDMP > copy, and which -- I believe -- does maintain snapshots. You might > want to contact an SE. > > (Yes -- the tool I'm describing will be integrated back into our base > software. What the SE's have is an early proto-type.) Ummm, will it allow you to do partial copies (one directory hierarchy like ndmpcopy does) and copies from differently-sized filers? Dan

2 1

More about CIFS
by Alexei Rodriguez 20 Feb '98

20 Feb '98

There is an article (very timely) in the latest SysAdmin magazine by Bridget Allison (NetApp employee) titled: "integrating CIFS and NFS file sharing". >From it, here is the location for CIFS info: http://www.microsoft.com/intdev/cifs for those interested. Alexei

1 0

Gigabit ethernet
by Alexei Rodriguez 20 Feb '98

20 Feb '98

How many of you are testing or using gigabit on the filer? I have some friends that have been doing it, but only 66% success. The 1 person using the Alteon (or whatever the NetApp reccomended one is) got good results; but the density is lacking. Another person is using a Foundry switch between a filer (630) and a DEC alphastation. He is getting decent results. But the Foundry equipment is also less than dense (and will be expensive when they put the chassis systems out). Finally, another friend is using a Prominet Cajun switch (good density, excellent price) but cannot get the filer to "ring up" on the switch. Looks like it might be a Prominet issue. Has anyone tried other equipment? Cisco (beta tesing)? YAGO? Success stories? Horror stories? I need to go from FDDI to something faster (and less expensive). ATM is not it.. :) My plan is to put the filers on gigabit, as well as our backups machine and the heavy use clients (servers). The rest of the servers can use switched 100mbit. Thanks. Alexei

3 3

Re: Gigabit ethernet
by Johannes Erdfelt 20 Feb '98

20 Feb '98

On Thu, Feb 19, 1998, Alexei Rodriguez <alexei(a)cimedia.com> wrote: > > How many of you are testing or using gigabit on the filer? > I have some friends that have been doing it, but only 66% > success. > > The 1 person using the Alteon (or whatever the NetApp reccomended one is) > got good results; but the density is lacking. The Alteon NIC's (the ones NetApp sells and supports) work great with the Alteon switch (surprise!). I was supposed to have a meeting with a sales person this week but something came up and he had to cancel. They hinted at some sort of chassis solution in the future (as is everyone else). > Another person is using a Foundry switch between a filer (630) and > a DEC alphastation. He is getting decent results. But the > Foundry equipment is also less than dense (and will be expensive > when they put the chassis systems out). I wonder who that could be :) The chassis will indeed be expensive, but relative to the other chassis solutions will be very competetive as well as denser and featureful. I am anxiously awaiting it now. > Finally, another friend is using a Prominet Cajun switch > (good density, excellent price) but cannot get the filer to > "ring up" on the switch. Looks like it might be a Prominet > issue. It's probably a link negotiation problem. I haven't been able to get the Alteon NIC to negotiate with any switch. I dunno if Gigabit ethernet Link Negotiation is going to be as horrible as 10/100 Link Negotiation. Since my test NetApp isn't available to me right now, this is from memory: filer> rc_toggle_basic filer*> LinkNegotiation e10 0 filer*> rc_toggle_basic filer> That will turn it off the Link Negotiation and the NIC should immediately start working. We needed to do that to get it to talk to the Foundry switch. The actual command may be different, but "help" should get you all the way you need. > Has anyone tried other equipment? Cisco (beta tesing)? I'm trying to get a beta Cisco 7500 series NIC/blade to do testing with but it sounds like their not very far along (not even alpha). I cringe at the thought of doing gigabit ethernet on the Catalyst's 1.2gigabit backplane. > YAGO? Now that Yago is cabletron I don't think we'll see many yago made gigabit products. Cabletron has a 2 port blade for the SS 9000 (MMAC+) but haven't tried it either. Our Network Engineers refuse to even talk to them :) > Success stories? Horror stories? I know I've mentioned this before, but getting the gigabit working was one of the most painless things I've ever done. I've used NIC's from Alteon (on the netapp), Packet Engines (on the DEC) and Essential (on the DEC) and minus some small driver bugs have had VERY little problems. They all interoperated very well. > I need to go from FDDI to something faster (and less expensive). > ATM is not it.. :) NetApp's didn't do voice or video last I checked so why ATM? :) > My plan is to put the filers on gigabit, as well as our backups > machine and the heavy use clients (servers). The rest of the servers > can use switched 100mbit. I've never used Prominet's switch, but have heard some good feedback about them. Not as good as some other's, but good performance nonetheless. Depending on how many machines you have, getting a Foundry FastIron with a single or dual gig uplink may work well. Never use Extreme. Their products may be decent, but their sales people/sale engineers really rubbed me the wrong the way. Overall rude and deceitful. Plus, who wants purple switches? :) JE

2 1

ndmp copy?
by Alexei Rodriguez 19 Feb '98

19 Feb '98

I have heard of folks dumping an entire filer to another via ndmp copy. Next week I will be having to do something like that and was wondering what sort of speed I might expect (if this thing exists). Also, does it do snapshots as well? Alexei

2 1

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