Regardless of a specific application and configuration, I am looking for an architecture that will support nas. Setting all components equal, comparing apples to apples, you end up with either going through a server for each operation or accessing a disk directly and an architecture that lets you access the disk directly must be faster. If you could have fast disk channels, getting information from that disk must be faster than getting the information through the server. It is not completely true for all applications. You still need the server for co-ordination and then it is a trade off. But I believe that each storage vendor will need this capability to be competitive. Some applications that would need this capability are publisher consumers messaging model, backup, source control.
-----Original Message----- From: Josh McCormick [mailto:jmccorm@mail.wcg.net] Sent: Thursday, March 23, 2000 9:02 AM To: mkeller@mail.wcg.net Cc: toasters@mathworks.com Subject: Re: nas storage
Necessary to yell? I use what I received. I am required to stick with
it for a while yet.
You make a blanket statement without supporting
facts.
Here's what I'm wondering, Michael. When they are comparing the Netapp Filers to local storage, what exactly are they comparing?
* Are they comparing 100mbit NFS delivery to a SCSI variant? * Are they comparing their raid and caching to a(n anonymous) local disk solution? JBOD or something else? * Are they comparing their NFS filesystem implementation to UFS and/or VxFS?
Are the comparing the whole solution against something when it is claimed to be on par with local disks, and if so, what solutions are they comparing against?
Of course, it would be a surprise is the Netapp Filers were on par with local storage in all cases. What I want to know is, what are the edge cases? What are the filers particually better at, and what are they particularly worse at?
__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com