Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Strategies & Market Trends : Gorilla and King Portfolio Candidates -- Ignore unavailable to you. Want to Upgrade?

To: DownSouth who wrote (25168)	5/22/2000 10:49:00 PM
From: buck	Read Replies (7) \| Respond to of 54805

ROI It's not much of a return on investment when existing RAIDs need to be put on the shipping dock for removal in order to be replaced by a filer. Existing RAIDs, existing tape drives, existing tape libraries, so on and so forth, in fact just about any SCSI device, can be attached to a SAN and shared amongst all servers on the SAN. You are just plain wrong about SAN being easier to administer That, of course, depends on what your staff of storage administrators are trained on and know best. I feel very comfortable saying that 90% of the storage adminstrators out there that implement storage policies in an enterprise have very little idea of how an IP network works, much less a NAS filer. And you can have no NAS without IP. Those guys know how to configure SCSI devices for penultimate performance, an option that is pretty much taken out of their hands by a filer, because of the OS in the middle. Vagaries of what protocol? The network protocol that provides the path to the data they are managing, and the OS in the middle under the covers. Data served by a NTAP filer through a LAN is faster than data served from an I/O channel like SCSI or FC. The reason being that data delays are not caused by the speed of ethernet, but by the delays of writing and reading that data through a general purpose OS using a general purpose file layout. Delays caused by LAN network contention are easily overcome with fatter pipes, or reduced contention over any given pipe. I would agree that this could potentially be true up to a certain data size, around 2 or 4K blocks of data. Moving large amounts of data, in the hundreds of gigabytes, causes this model to break down quickly. I also find it interesting that the NAS argument is to throw fatter pipes at the problem. The whole point for and end user is that this NAS stuff is a technology that exists on the same network you already have installed. Fatter pipes means a new network, and less contention means a seperate network. So much for the investment protection aspect. You gotta study NTAP's architecture better, sir. With clustered configs there certainly is an alternative path to the data if a filer goes down, with no mirroring whatsoever. And its transparent to the end user or application server. Clusters are still a rarity in F500 or G2000 production environments. There are plenty of science projects percolating along that use clustering. I've seen one end user in the last two years that use clustering in production, and it's a way-back office application. I couldn't agree more that clustering will remove this effect, but it is so narrowly implemented, it really doesn't matter today. The battle between NAS and SAN is over. They both won. That I agree with 100%. Again, IMHO, the right tool for the right job. . The battle now will be for the survival of FC as 10GB-Enet develops Given that it will this time two years from now before the standard for 10GbE is finished, I'll happily take whatever FC can give me TODAY to solve problems I have TODAY, if I'm running an enterprise. I don't think our business would be in trouble for looooong time. Surely you realize just how few people actually understand this discussion, even those whose living is in IT, much less investors...I can hear the NEXT buttons being clicked from here. And I can feel the arrows in my back from being such a gear-head and a show-off. I don't mean that in offensive manner to any readers, BTW. This is way under-the-covers stuff that has little to do with Gs and Ks, and for that I apologize. buck

To: DownSouth who wrote (25168)	5/23/2000 7:21:00 AM
From: alankeister	Read Replies (2) \| Respond to of 54805

Data served by a NTAP filer through a LAN is faster than data served from an I/O channel like SCSI or FC. The reason being that data delays are not caused by the speed of ethernet, but by the delays of writing and reading that data through a general purpose OS using a general purpose file layout. Delays caused by LAN network contention are easily overcome with fatter pipes, or reduced contention over any given pipe. I have used NetApp Filers at work and like them very much. However, your statement is misleading. They may be able to serve small amounts of data faster than local disk but with any volume, local disk is magnitudes faster. Unfortunately, it is not as easy as you claim to overcome network bandwith limitations with fatter pipes or by reducing contention. Last I heard, the Filers support only one network interface so there is a hard limit on transfer rates that can be exceeded by one busy client. Fast Ethernet and FDDI are the only tried and true fast networks available and you can get only 10 Megabytes/sec through them. - Alan