toasters

toasters@lists.teaparty.net

13515 discussions

Re: Need help regarding quotas
by sirbruce＠ix.netcom.com 09 Apr '99

09 Apr '99

On 04/09/99 00:05:17 you wrote: >Our problem is that it displays too much. We automount each user's home >directory. Since we want to permit them to write into each others >directory we have quotas on the qtree housing users' directories. >Unfortunately that file system is mounted once for every user :(((((((((. >Running quota -v displays data related to every home directory mounted on >the box. Unfortunately, it appears that Sun does not support the >automounter ":" path option in Solaris 2.6 which would fix the problem. How about just mounting the filesystems noquota? The filer won't care. >We automount each users home directory because we want to have a >data location independent pathing, i.e. /home/tkaczma instead of >/home/filer2/tkaczma. This prevents a lot of headaches when users' >directories are moved for some reason, like due to disaster recovery or >some migration. You might consider using symlinks instead. Bruce

2 1

RE: Ridiculously easy question...
by Phillips, John 08 Apr '99

08 Apr '99

There is a Windows NT 4.0 Resource Kit utility named "autoexnt" can be used to ensure the redirector is started and the connection is made to the filer at boot up. You must have a copy of the Windows NT 4.0 Resource Kit, and the companion CD. Autoexnt is installed by simply copying autoexnt.exe and servmess.dll from the \ntreskit directory to the Systemroot\System32 directory. Create a batch file with the commands to map a drive to the Filer and save it as "autoexnt.bat" in the Systemroot\System32 directory. Type "instexnt install" at the command prompt to install the service. Use the /interactive switch if you want to see the commands executing in a command window during boot time ("instexnt install /interactive"). For example: D:\ntreskit.40>instexnt install /interactive CreateService AutoExNT SUCCESS with InterActive Flag turned ON. Finally, to configure the AutoExNT service to run when you start your computer (during boot) 1. Double-click Services in Control Panel. 2. In the Services list, click AutoExNT. 3. Click Startup and, in the Startup Type box, click Automatic. 4. Choose OK. Example autoexnt.bat: d:\winnt\system32\net start workstation d:\winnt\system32\net use t: \\toaster\home If you log in, the drive is already mapped and shows up in Windows Explorer. You cannot "disconnect" the drive mapping from within explorer which insulates it from user error a bit as well. Good luck! John Phillips Network Appliance > -----Original Message----- > From: Jaye Mathisen [mailto:mrcpu@internetcds.com] > Sent: Thursday, April 08, 1999 12:53 PM > To: toasters(a)mathworks.com > Subject: Ridiculously easy question... > > > > I'm just starting to use CIFS, and everything works fine, > except one minor > problem... > > I would like NT (4.0SP4, if it matters), to attach a drive on system > startup, rather than having to be logged in... > > For various reasons, I cannot use UNC paths in my > application, so I need > to map the drive when the system boots, with a username and > password... > > Is this possible? > > My filer is running 4.3.4, but I think I'm going to upgrade tonight to > 5.2.1... >

1 0

Ridiculously easy question...
by Jaye Mathisen 08 Apr '99

08 Apr '99

I'm just starting to use CIFS, and everything works fine, except one minor problem... I would like NT (4.0SP4, if it matters), to attach a drive on system startup, rather than having to be logged in... For various reasons, I cannot use UNC paths in my application, so I need to map the drive when the system boots, with a username and password... Is this possible? My filer is running 4.3.4, but I think I'm going to upgrade tonight to 5.2.1...

2 1

RE: Ridiculously easy question...
by Benn, Paul 08 Apr '99

08 Apr '99

Hello Jaye, This is possible with the AutoExNT service that comes with the NT resource kit. I have its use documented in an NT Backup paper that I recently published. You can find it at: http://www.netapp.com/technology/level3/3052.html#Sect2.3 Hope this helps. Regards, Paul Benn Network Appliance -----Original Message----- From: Jaye Mathisen [mailto:mrcpu@internetcds.com] Sent: Thursday, April 08, 1999 12:53 PM To: toasters(a)mathworks.com Subject: Ridiculously easy question... I'm just starting to use CIFS, and everything works fine, except one minor problem... I would like NT (4.0SP4, if it matters), to attach a drive on system startup, rather than having to be logged in... For various reasons, I cannot use UNC paths in my application, so I need to map the drive when the system boots, with a username and password... Is this possible? My filer is running 4.3.4, but I think I'm going to upgrade tonight to 5.2.1...

1 0

Re: Need help regarding quotas
by dnb＠ccs.neu.edu 08 Apr '99

08 Apr '99

Luke Mewburn <lukem(a)cs.rmit.edu.au> writes: > This is *damned* annoying. With 2500 students all hammering one > of my filers (a F330 in this case), we generally get /etc/messages.? Yep, we see the same thing here. Here's a trivial Perl script I run the end of the week autosupport mail through which boils the messages portion down to a more readable form. It certainly could be made to do more sophisticated tricks. Here's the output: ----------------- ==== Quota exceeded ==== achervin bdowling csaia frodo jack138 jeffno johan jsl santana stellato ==== Tree quota exceeded ==== proj ==== Unknown messages ==== Sun Mar 28 00:00:06 EST [asup_main]: System Notification mail sent Sun Mar 28 01:00:01 EST [raid_scrub_admin]: Beginning disk scrubbing... Sun Mar 28 02:36:03 EST [consumer]: Scrub found 0 parity inconsistencies Sun Mar 28 02:36:03 EST [consumer]: Scrub found 0 media errors Sun Mar 28 02:36:03 EST [consumer]: Disk scrubbing finished... Mon Mar 29 00:24:09 EST [tn_login_0]: Login from host: amber Mon Mar 29 19:23:03 EST [isp2100_main]: Disk 0a.18(0xfffffc0000be06f0): opcode=0x2a sector 0 not ready - Drive spinning up (2 4, 1) Mon Mar 29 19:24:00 EST [isp2100_main]: Disk 0a.18(0xfffffc0000be06f0): request failed after retry #20 Mon Mar 29 19:24:00 EST [raid_stripe_owner]: Write on data disk 0a.18 in volume proj, RAID group 0, failed; reverting to degraded mode. Mon Mar 29 19:24:04 EST [raid_stripe_owner]: Write on data disk 0a.18 in volume proj, RAID group 0, failed; entered degraded mode. Mon Mar 29 19:24:04 EST [raid_stripe_owner]: One disk is missing from volume proj, RAID group 0. A "hot spare" disk is available and the missing disk will be reconstructed on the spare disk. ------------- And here's the script: ----------- #!/usr/local/bin/perl # parse netapp autosupport mail and show it to us nicely use Text::Wrap; while (<>){ last if (index($_,"===== MESSAGES =====") > -1); } while($_ = <>){ next if /\[statd\]/; next if (index($_,"last message repeated") > -1); next if (index($_,"../common/ndmpd/comm.c") > -1); if (/uid\s(\d+).*exceeded on volume (.*)/){ $user = ((exists $users{$1}) ? $users{$1} : $users{$1}=getpwuid($1)); $volume = $2; $quotabloat{$user} = $volume if (!exists $quotabloat{$user}); next; } if (/tree quota exceeded on volume (.*)/){ $treebloat{$1}++ if (! exists $treebloat{$1}); next; } push (@unknown,$_); } close(<LOG>); print "\n==== Quota exceeded ====\n"; print wrap("","",join (" ",sort keys %quotabloat)),"\n"; print "\n==== Tree quota exceeded ====\n"; print wrap("","",join (" ",keys %treebloat)),"\n"; print "\n==== Unknown messages ====\n"; print @unknown; ----------------- Hope this is helpful. Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University

1 0

RE: Looks like InfoLibria got the last laugh at the cache bakeoff .
by Shaw, Kevin 07 Apr '99

07 Apr '99

Cor I have filers from the F330 to the F760. In the four years that I have been using the filers, I've NEVER had a production system go down! The filers are by far the best piece of hardware I have (I have a number of Sun Enterprise Systems) and I'm NOT taking anything away from Sun. Hey James! :) Right now id buy almost anything over NotUp. We've had more crashes with our new F720 the last 2 weeks than our previous Sun had in 2 years, and thats including fsck. Cor

1 0

vif with gigabit ether?
by rani＠easynet.fr 07 Apr '99

07 Apr '99

Hi, Is it possible to add gigabit ethernet interfaces to a virtual interface?? I've tried with Ontap 5.3 and it says: toaster1> vif add trunk1 e6 vif: e6 cannot be attached to a vif Does this mean that trunking works only with fast ethernet? Will 1000Fx cards be supported in a future release? Thanks, Rani

2 1

forward from bugtraq: "Netcache snmp behaviour"
by Bennett Todd 07 Apr '99

07 Apr '99

Didn't know if this had already made it around here, didn't remember seeing it in the toasters list. -Bennett

1 0

RE: Looks like InfoLibria got the last laugh at the cache bakeoff .
by jrg＠acm.org 07 Apr '99

07 Apr '99

On Wed 7 Apr, 1999, "Mohler, Jeff" <jeff.mohler(a)wilcom.com> wrote: >Of course, my management caught wind of this too..and lacking NetApp >information, I may not be able to change the tide for our backbone. indeed. I'd not heard of this product until I saw the bakeoff PR - but clearly their product must be worth at least a look. >> From: Jaye Mathisen [SMTP:mrcpu@internetcds.com] >> Sent: Wednesday, April 07, 1999 2:16 AM >> To: toasters(a)mathworks.com >> Subject: Looks like InfoLibria got the last laugh at the cache >> bakeoff. >> >> http://www.infolibria.com/press/040599.htm of course the company isn't quite so big, can't offer the same range of support (notice they are talking about building their 24/7 support, and I don't doubt that it will take longer for them to appear here in Europe), but they're clearly keen on making a name for themselves. (I'd want to see more technical information and/or see a unit for myself before deciding it was going to solve all my problems, though.) James.

6 6

RE: Looks like InfoLibria got the last laugh at the cache bakeoff .
by Mohler, Jeff 07 Apr '99

07 Apr '99

*heh* Cute. Of course, my management caught wind of this too..and lacking NetApp information, I may not be able to change the tide for our backbone. > -----Original Message----- > From: Jaye Mathisen [SMTP:mrcpu@internetcds.com] > Sent: Wednesday, April 07, 1999 2:16 AM > To: toasters(a)mathworks.com > Subject: Looks like InfoLibria got the last laugh at the cache > bakeoff. > > > > > http://www.infolibria.com/press/040599.htm > > > > Already had a netcache appliance, didn't buy one. Looks like time to give > infolibria a call, since they're saying a 5-9 month payback, and see if > they want to toss me a loaner for eval... > > >

1 0

Looks like InfoLibria got the last laugh at the cache bakeoff.
by Jaye Mathisen 07 Apr '99

07 Apr '99

http://www.infolibria.com/press/040599.htm Already had a netcache appliance, didn't buy one. Looks like time to give infolibria a call, since they're saying a 5-9 month payback, and see if they want to toss me a loaner for eval...

1 0

RE: F740 cluster
by Smith, Gil 06 Apr '99

06 Apr '99

> -----Original Message----- > From: beepy(a)netapp.com [mailto:beepy@netapp.com] > I was going to slip "The Downward Spiral" onto our corporate phone > system background music about four years ago - but far be it from > me to dictate my musical tastes on everyone else. Which is why most people (at least I did when I was a UNIX admin) prefer silence with maybe an auto attendant that will let you know the approx. wait time and how many people are ahead of you in the queue. At least then you can decide whether or not to remain on hold -- possibly offered the option to leave a message. --Gil

3 2

RE: IRCACHE Web Cache Bakeoff?
by Mohler, Jeff 06 Apr '99

06 Apr '99

> NetApp is pleased with its performance in the NLANR bake-off and are > sharing our results with customers and potential customers under NDA. > We have decided not to publicly release our results at this time > because of the late withdrawal from the bake-off by the other major > caching vendors (Cisco and Inktomi). Network Appliance does not want > to disclose detailed performance numbers to our competitors without > having access to their results. Based on past experience we believe > that competitors are likely to compare apples to oranges and > selectively quote our results as it suits their requirements. --- Let em cut their own throats. When someone learns that their stuff doesnt measure up...THEIR loss. It's distressing internally for me at Willams, and personally depressing to see the "Theyre not, so we're not" spin.

1 0

"df" on 5.3
by Graham C. Knight 06 Apr '99

06 Apr '99

Does anyone know why the "df" output on 5.3 was changed? It no longer lists the snap reserve usage. It does list the snapshot reserve if nosnapdir is "off" - but our default is "on". 5.1 and 5.2 listed it regardless of the option's state. This breaks all my snapshot monitoring scripts :-( Why does netapp fiddle with the output of commands like this? Graham

1 0

Re: Muzak (was F740 cluster)
by dnb＠ccs.neu.edu 06 Apr '99

06 Apr '99

"Skinner, Alistair" <alistair.skinner(a)netapp.com> writes: > We knew people were having trouble with Kenny G, so we changed > recently to a longer sample of different music. However, it sounds > like that isn't cutting it either, and so we are purchasing an audio > feed card for our Aspect phone system. This will allow us to have a > live feed instead of a loop. Great! Does this mean we get to hear David Hitz's Greatest Hitz? Peace, dNb P.S. Ok, sorry. It's been one of those degraded mode days.

2 1

RE: NAC SAN
by Chen, Ray 06 Apr '99

06 Apr '99

Well, I wouldn't go so far as to call it "the" clarification of Dave's position. It's certainly *my* position and my take on your question "why focus on the protocol?" I'll let Dave decide whether or not he wants to let it stand or chime in with something different. Sorry if I didn't make that obvious in the original message. Ray > -----Original Message----- > From: Adams, Christian [mailto:Adams_Christian@emc.com] > Sent: Monday, April 05, 1999 2:32 PM > To: 'Chen, Ray'; Adams, Christian; Hitz, Dave; willh(a)infi.net > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > Subject: RE: NAC SAN > > > Hey Ray Chen - > > Thanks for the clarification of Dave Hitz's position. > > /Christian Adams > EMC > > > -----Original Message----- > > From: Chen, Ray [SMTP:ray.chen@netapp.com] > > Sent: Sunday, April 04, 1999 10:19 AM > > To: 'Adams, Christian'; Hitz, Dave; willh(a)infi.net > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > Subject: RE: NAC SAN > > > > Um, because the distinctive characteristic of SAN is that > > clients can write directly to the storage devices bypassing > > any server? This is possible only if a storage-level (e.g. > > block-level) protocol like SCSI runs on the wire. (Actually, > > I'm lying here. There are two ways of enabling this. One is > > to use a really simple protocol like SCSI. The other is to > > implement an industry-standard clustered filesystem with the > > disk drives/storage devices as an intelligent component of > > said filesystem. A very complex protocol whose viability > > and practicality is an issue in its own right. The rest of this > > mail assumes a block-level SAN protocol.) > > > > As folks have pointed out, SAN has its advantages and disadvantages. > > It eliminates the backplane of server (unless you have a > RAID controller > > in front of the drives :-) from the I/O path, eliminating a possible > > I/O bottleneck. But there is no server to protect the integrity > > of the data and even if there is, the protocol is so low-level in > > a SAN, the server has no effective way of detecting when a client > > has gone insane (maliciously or not) and is scribbling gibberish > > on the drives. So trust becomes a definite issue. > > > > Personally, I see data sharing using SANS as making sense > > in small workgroup environments and what I call "machine room > > clusters" -- a SAN in a machine room supporting a dedicated > > cluster. Typically you'd do the latter because scaling via > > a cluster is cheaper (and more available) than scaling via MP. > > But both are situations where you are willing to trust all the > > machines in the cluster because they are all firmly controlled by > > the group whose storage/data is being shared. > > > > Ray Chen > > rcc(a)netapp.com > > > > > -----Original Message----- > > > From: Adams, Christian [mailto:Adams_Christian@emc.com] > > > Sent: Tuesday, March 30, 1999 10:14 AM > > > To: 'Dave Hitz'; willh(a)infi.net > > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > > Subject: RE: NAC SAN > > > > > > > > > Hey Dave Hitz - > > > > > > Why do you focus on existing protocols in your discussion? > > > This indicates > > > that the introduction of Fibrechanel with either > encapsulated SCSI or > > > Ethernet is the critical event in the creation of SAN or NAS. > > > Further in > > > your discussion, you draw a parallel to switches and routers > > > which indicate > > > that you may be thinking in terms of shared versus segmented > > > data flows. > > > And yet in all of your discussion, you do not address the > issues of > > > management, integration, or value. > > > > > > Loved your EMC bit, > > > /Christian Adams > > > EMC > > > > > > > -----Original Message----- > > > > From: Dave Hitz [SMTP:hitz@netapp.com] > > > > Sent: Saturday, March 27, 1999 1:41 PM > > > > To: willh(a)infi.net > > > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > > > Subject: Re: NAC SAN > > > > > > > > > Tom's statement below (to a [NetApp] SAN when we build > > > one) brings up a > > > > > familiar argument between myself and my boss. My boss > > > contends that > > > > > NetApp is NOT capable of migrating to a "real SAN." > > > > > > > > I've been delinquent in my duty of writing a NAS and > SAN paper. I'm > > > > about half way done. Whem I'm done, I'll post it here, > probably in > > > > early form, so that you guys can critique it for me. > > > > > > > > Very briefly, I believe that NAS and SAN are different > but related > > > > technologies, and that the definitions are as follows: > > > > > > > > NAS (Network Attached Storage) > > > > Storage accessed over TCP/IP, using > industry standard file > > > > sharing protocols like NFS, HTTP and > Windows Networking. > > > > > > > > SAN (Storage Area Network) > > > > Storage accessed over a Fibre Channel > switching fabric, > > > > using encapsulated SCSI. > > > > > > > > I also think that both NAS and SAN are useful, and that -- > > > in the long > > > > run -- both will be critical components in any large data > > > > infrastructure. I think there's a strong analogy to the TCP/IP > > > > networking world. Routers and switches are very similar in > > > some ways, > > > > yet subtly different in others. In the mid-eighties, > > > arguments raged > > > > about which was "better". (Back then switches were > called bridges.) > > > > Today we understand that any large network > infrastructure needs to > > > > include both. > > > > > > > > Some people would quibble with my definitions. Some would > > > argue that > > > > if you run NFS over TCP/IP over fibre channel, then that is > > > a SAN. I > > > > figure that we didn't invent new names for NFS over 100bT, > > > FDDI, ATM, > > > > or Gigabit -- what's so special about fibre channel? > > > Others argue that > > > > a SAN is any network dedicated entirely to storage traffic. > > > Does this > > > > mean a SAN turns to a NAS if you fire up a telnet on > it? A year ago > > > > these definitions were less settled, but today I think > these are the > > > > definitions that are emerging. > > > > > > > > With these definitions, the key difference is between > file system > > > > protocols and raw disk protocols. With NAS, the filesystem > > > runs on the > > > > storage system itself. (For NetApp, that's WAFL.) > With SAN, the > > > > filesystem runs on the hosts attached to the storage system. > > > > > > > > People familiar with EMC will recognize this model. With an EMC > > > > Symetrix, you get a big box of RAID protected disks, and > > > you can attach > > > > multiple hosts to that one box. Thus, I view SAN as > "open EMC". On > > > > the one hand, SAN could be viewed as a threat to EMC. But > > > on the other > > > > hand, EMC has a solid history of products -- software and > > > hardware -- > > > > based on this storage model, which means that they ought to > > > have a real > > > > head-start on SAN. I think the SAN vendors have a great > > > opportunity if > > > > they really can create "open EMC". After all, EMC is doing > > > $4 Billion > > > > a year in business with this model! > > > > > > > > In any case, I think NAS has some serious advantages over > > > SAN. One big > > > > issue with running the file system on the separate > hosts is that it > > > > makes true data sharing very difficult. The on-disk byte > > > formats are > > > > very different between UNIX and NT, and even between > > > different flavors > > > > of UNIX. Given the differences between UNIT and NT filesystem > > > > semantics, it's no surprise that the on-disk format is > > > different. With > > > > NAS, the filesystem is by the data, so it can convert > the on-disk > > > > format into an industry standard protocol appropriate to > > > the host that > > > > wants the data: NFS for UNIX, NT Shares for NT, and HTTP for web > > > > browsers. > > > > > > > > It is technically possible to build a "global file system" > > > that has a > > > > common on-disk format for multiple operating systems, > thus allowing > > > > NAS-like sharing for SAN. However, I'm skeptical of that > > > model. First > > > > of all, there are no such products today. And even > when they become > > > > available, sharing won't be based on industry standards. A > > > system will > > > > only be able to participate in sharing if it runs a > special SAN file > > > > system from a particular vendor. My believe is that the > > > lesson of 20 > > > > years of networking is that we build heterogeneous > environments by > > > > creating open standards and allowing everyone to support > > > them -- not by > > > > saying that anyone who wants to participate in sharing > must buy code > > > > from one particular company. > > > > > > > > Having said all this, though, NetApp does have plans to > leverage SAN > > > > technology. We have announced an OEM agreement with > > > Brocade. Here are > > > > the benefits we expect to achieve: > > > > > > > > - Attach to lots of disks. > > > > > > > > A fibre channel loop is limited to 127 drives, > but with a 16 > > > > port fibre channel switch, the limit goes to almost 2000 > > > > drives. With additional switches, you can > support an arbitrary > > > > number of drives. > > > > > > > > - Share tape drives between multiple servers. > > > > > > > > I believe that backup applications are the > killer application > > > > for SAN. When people buy expensive tape > jukeboxes, they want > > > > to be able to attach them to multiple servers. > With today's > > > > SCSI tapes that's a painful job. But with > fibre channel and > > > > fibre channel switches, it's easy to connect a > single tape to > > > > any number of hosts. > > > > > > > > - Disaster Tolerant Solutions > > > > > > > > Fibre channel switches can do WAN tunneling to provide > > > > connections to remote disks without any changes > to the server > > > > code. This makes it much easier to build > remote mirrors for > > > > data replication and disaster protection. > > > > > > > > In conclusion, I believe that NAS and SAN are both important > > > > technologies, and the any large data infrastructure in the > > > future will > > > > include both. I believe that NAS focuses on issues > associated with > > > > users, applications, and data sharing. I believe that SAN > > > focuses on > > > > issues associated with disk and tape devices, > connection to large > > > > numbers of them, and moving data back and forth between > > > them. In the > > > > long run, any large environment will have both sets of > > > issues, and will > > > > need both types of solutions. In the short run, NAS makes > > > good sense > > > > as a starting point, because it is here today and the > standards it > > > > relies on have been solid for over a decade. > > > > > > > > I'll go ahead an post the whole paper when I finish, but I still > > > > thought it might be useful to share my thoughts in this brief, > > > > half-baked form. > > > > > > > > Dave > > > >

2 1

F740 cluster
by Jason D. Kelleher 06 Apr '99

06 Apr '99

Anybody out there have an F740 cluster w/ 18GB drives running in production? If so, I have a couple of questions I'm hoping you can answer: 1) Have any problems loosing routes over a virtual interface? If you physically disconect all the links in a trunk it drops all routes which use that interface, even static routes w/ routed off. 2) Have you been able to takeover/giveback a virtual interface? Treating it like a "normal" interface doesn't seem to work and I haven't been able to find any special instructions for this. 3) Any unexplained panics? We had one running 5.2.1 in takeover mode -- didn't even drop core. Another attributed to a bad disk while we were running 5.2.1P1. We're now at 5.2.1P2 after several ndmpd hangs (didn't bring down the filer), seems to be stable. 4) How many disk failures did you see within the first 6 months of getting the filer? (looks like we're on 2 of 24 in 3 months and we haven't even used them all yet). 5) Do you have the name and address of the person in charge of the hold muzac for the support line? The 5 minute loop of garbage is really ramping up my aggression level and I'd prefer to take it out on the person responsible. I have a couple of open calls with support I'm waiting for status on, but I'm not calling them because if I have to listen to that damned muzac tape loop around one more time I'm going to kill someone. Since my office-mate is closest it would probably be him... and that would just leave me more work to do. (Moving bodies, digging holes, and handling all his projects...) Any help would be greatly appreciated. jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

4 4

Re: Muzak (was F740 cluster)
by sirbruce＠ix.netcom.com 06 Apr '99

06 Apr '99

>Great! Does this mean we get to hear David Hitz's Greatest Hitz? I suddenly have this weird image of Dave Hitz doing Christian Slater's part in _Pump Up The Volume_. Bruce

1 0

Re: IRCACHE Web Cache Bakeoff?
by sirbruce＠ix.netcom.com 06 Apr '99

06 Apr '99

On 04/05/99 15:46:32 you wrote: >NetApp is pleased with its performance in the NLANR bake-off and are >sharing our results with customers and potential customers under NDA. >We have decided not to publicly release our results at this time >because of the late withdrawal from the bake-off by the other major >caching vendors (Cisco and Inktomi). Network Appliance does not want >to disclose detailed performance numbers to our competitors without >having access to their results. Based on past experience we believe >that competitors are likely to compare apples to oranges and >selectively quote our results as it suits their requirements. If this is true, it's completely nonsensical. Other vendors *did* have their results published. Why should you care only about the couple that didn't? Furthermore, the same logic means you shouldn't be releasing any NFS or CIFS performance numbers either, since not all of your competitors do. (EMC, for example, still hasn't submitted new SFS97 results and continues to point to older benchmarks.) Yet this hasn't stopped you in the past. Is this a new policy, or one which you only want to apply to Polygraph? Bruce

1 0

snapshot doc
by dnb＠ccs.neu.edu 05 Apr '99

05 Apr '99

Howdy- Just so I feel like I've actually added some signal to today's discussion, I wanted to point folks at: http://www.ccs.neu.edu/groups/systems/howto/howto-snapshot.html This is a document I wrote when we first got our NetApp explaining snapshots to our user community and how they are used for online file recovery. Feel free to use it with local modifications if you ever need to publicize same. Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University

1 0

Re: IRCACHE Web Cache Bakeoff?
by David Drum 05 Apr '99

05 Apr '99

Hello everyone, I have received a completely satisfactory answer from my sales rep. about why NetApp pulled out of the bakeoff. Hopefully someone from NetApp will respond and quench the rumor mill. It would be inappropriate of me to forward the email I received. Regards, David david(a)mu.org

1 0

IRCACHE Web Cache Bakeoff?
by sirbruce＠ix.netcom.com 05 Apr '99

05 Apr '99

Can anyone at Netapp tell us what happened with the ircache web cache bakeoff? Netapp attended and then declined to have their results published. Many other companies backed out as well, such as Cacheflow and IBM. Rumor has it that netcache was outperformed; was the benchmark unrealistic or did Netapp withdraw for other reasons? Bruce

2 1

Re: F740 cluster
by dnb＠ccs.neu.edu 05 Apr '99

05 Apr '99

"Jason D. Kelleher" <kelleher(a)susq.com> writes: > 5) Do you have the name and address of the person in charge of > the hold muzac for the support line? The 5 minute loop of > garbage is really ramping up my aggression level and I'd > prefer to take it out on the person responsible. Hear, hear! I've said almost the exact same words at every support person I've ever spoken to (and some people higher). I even offered to purchase the music myself. In the end, I decided against hurting someone because I decided it would be too embarrassing to have to describe the situation to others in federal prison: "So what are you in for?" "Murder." "And you?" "Armed robbery." "What about you?" "Kenny G. It all started with this NetApp support call..." It's not like they wouldn't understand, but still. Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University

2 1

Muzak (was F740 cluster)
by Skinner, Alistair 05 Apr '99

05 Apr '99

Hi Jason, My name is Alistair Skinner. I run the global support center at Network Appliance, and was passed your comments concerning the "hold muzac". Thanks for the feedback, I would guess there are two issues: (1) why do we have to keep you on hold so long? We have put in place several initiatives around improving our staffing, scheduling, training, processes, and systems which we expect to improve service levels over time. In the last few months we have hired 10 more staff, defined a more rigorous initial training program, and worked to eliminate our backlog of cases. Although our average holdtime is now 3 minutes, we know there are quite a few instances where customer have had to wait much longer, so we will keep tuning our goals, scheduling, and processes to provide more consistent response. (2) if we do have to keep you on hold, can't we play something better? We knew people were having trouble with Kenny G, so we changed recently to a longer sample of different music. However, it sounds like that isn't cutting it either, and so we are purchasing an audio feed card for our Aspect phone system. This will allow us to have a live feed instead of a loop. Based on your feedback, I'll see what we can do about accelerating its delivery and installation. Alistair Alistair Skinner Network Appliance alistair.skinner(a)netapp.com 408-367-3869 -----Original Message----- From: Jason D. Kelleher [mailto:kelleher@susq.com] Sent: Monday, April 05, 1999 10:50 AM 5) Do you have the name and address of the person in charge of the hold muzac for the support line? The 5 minute loop of garbage is really ramping up my aggression level and I'd prefer to take it out on the person responsible.

1 0

RE: NAC SAN
by Adams, Christian 05 Apr '99

05 Apr '99

Hey Ray Chen - Thanks for the clarification of Dave Hitz's position. /Christian Adams EMC > -----Original Message----- > From: Chen, Ray [SMTP:ray.chen@netapp.com] > Sent: Sunday, April 04, 1999 10:19 AM > To: 'Adams, Christian'; Hitz, Dave; willh(a)infi.net > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > Subject: RE: NAC SAN > > Um, because the distinctive characteristic of SAN is that > clients can write directly to the storage devices bypassing > any server? This is possible only if a storage-level (e.g. > block-level) protocol like SCSI runs on the wire. (Actually, > I'm lying here. There are two ways of enabling this. One is > to use a really simple protocol like SCSI. The other is to > implement an industry-standard clustered filesystem with the > disk drives/storage devices as an intelligent component of > said filesystem. A very complex protocol whose viability > and practicality is an issue in its own right. The rest of this > mail assumes a block-level SAN protocol.) > > As folks have pointed out, SAN has its advantages and disadvantages. > It eliminates the backplane of server (unless you have a RAID controller > in front of the drives :-) from the I/O path, eliminating a possible > I/O bottleneck. But there is no server to protect the integrity > of the data and even if there is, the protocol is so low-level in > a SAN, the server has no effective way of detecting when a client > has gone insane (maliciously or not) and is scribbling gibberish > on the drives. So trust becomes a definite issue. > > Personally, I see data sharing using SANS as making sense > in small workgroup environments and what I call "machine room > clusters" -- a SAN in a machine room supporting a dedicated > cluster. Typically you'd do the latter because scaling via > a cluster is cheaper (and more available) than scaling via MP. > But both are situations where you are willing to trust all the > machines in the cluster because they are all firmly controlled by > the group whose storage/data is being shared. > > Ray Chen > rcc(a)netapp.com > > > -----Original Message----- > > From: Adams, Christian [mailto:Adams_Christian@emc.com] > > Sent: Tuesday, March 30, 1999 10:14 AM > > To: 'Dave Hitz'; willh(a)infi.net > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > Subject: RE: NAC SAN > > > > > > Hey Dave Hitz - > > > > Why do you focus on existing protocols in your discussion? > > This indicates > > that the introduction of Fibrechanel with either encapsulated SCSI or > > Ethernet is the critical event in the creation of SAN or NAS. > > Further in > > your discussion, you draw a parallel to switches and routers > > which indicate > > that you may be thinking in terms of shared versus segmented > > data flows. > > And yet in all of your discussion, you do not address the issues of > > management, integration, or value. > > > > Loved your EMC bit, > > /Christian Adams > > EMC > > > > > -----Original Message----- > > > From: Dave Hitz [SMTP:hitz@netapp.com] > > > Sent: Saturday, March 27, 1999 1:41 PM > > > To: willh(a)infi.net > > > Cc: toasters(a)mathworks.com; barsellt(a)infi.net > > > Subject: Re: NAC SAN > > > > > > > Tom's statement below (to a [NetApp] SAN when we build > > one) brings up a > > > > familiar argument between myself and my boss. My boss > > contends that > > > > NetApp is NOT capable of migrating to a "real SAN." > > > > > > I've been delinquent in my duty of writing a NAS and SAN paper. I'm > > > about half way done. Whem I'm done, I'll post it here, probably in > > > early form, so that you guys can critique it for me. > > > > > > Very briefly, I believe that NAS and SAN are different but related > > > technologies, and that the definitions are as follows: > > > > > > NAS (Network Attached Storage) > > > Storage accessed over TCP/IP, using industry standard file > > > sharing protocols like NFS, HTTP and Windows Networking. > > > > > > SAN (Storage Area Network) > > > Storage accessed over a Fibre Channel switching fabric, > > > using encapsulated SCSI. > > > > > > I also think that both NAS and SAN are useful, and that -- > > in the long > > > run -- both will be critical components in any large data > > > infrastructure. I think there's a strong analogy to the TCP/IP > > > networking world. Routers and switches are very similar in > > some ways, > > > yet subtly different in others. In the mid-eighties, > > arguments raged > > > about which was "better". (Back then switches were called bridges.) > > > Today we understand that any large network infrastructure needs to > > > include both. > > > > > > Some people would quibble with my definitions. Some would > > argue that > > > if you run NFS over TCP/IP over fibre channel, then that is > > a SAN. I > > > figure that we didn't invent new names for NFS over 100bT, > > FDDI, ATM, > > > or Gigabit -- what's so special about fibre channel? > > Others argue that > > > a SAN is any network dedicated entirely to storage traffic. > > Does this > > > mean a SAN turns to a NAS if you fire up a telnet on it? A year ago > > > these definitions were less settled, but today I think these are the > > > definitions that are emerging. > > > > > > With these definitions, the key difference is between file system > > > protocols and raw disk protocols. With NAS, the filesystem > > runs on the > > > storage system itself. (For NetApp, that's WAFL.) With SAN, the > > > filesystem runs on the hosts attached to the storage system. > > > > > > People familiar with EMC will recognize this model. With an EMC > > > Symetrix, you get a big box of RAID protected disks, and > > you can attach > > > multiple hosts to that one box. Thus, I view SAN as "open EMC". On > > > the one hand, SAN could be viewed as a threat to EMC. But > > on the other > > > hand, EMC has a solid history of products -- software and > > hardware -- > > > based on this storage model, which means that they ought to > > have a real > > > head-start on SAN. I think the SAN vendors have a great > > opportunity if > > > they really can create "open EMC". After all, EMC is doing > > $4 Billion > > > a year in business with this model! > > > > > > In any case, I think NAS has some serious advantages over > > SAN. One big > > > issue with running the file system on the separate hosts is that it > > > makes true data sharing very difficult. The on-disk byte > > formats are > > > very different between UNIX and NT, and even between > > different flavors > > > of UNIX. Given the differences between UNIT and NT filesystem > > > semantics, it's no surprise that the on-disk format is > > different. With > > > NAS, the filesystem is by the data, so it can convert the on-disk > > > format into an industry standard protocol appropriate to > > the host that > > > wants the data: NFS for UNIX, NT Shares for NT, and HTTP for web > > > browsers. > > > > > > It is technically possible to build a "global file system" > > that has a > > > common on-disk format for multiple operating systems, thus allowing > > > NAS-like sharing for SAN. However, I'm skeptical of that > > model. First > > > of all, there are no such products today. And even when they become > > > available, sharing won't be based on industry standards. A > > system will > > > only be able to participate in sharing if it runs a special SAN file > > > system from a particular vendor. My believe is that the > > lesson of 20 > > > years of networking is that we build heterogeneous environments by > > > creating open standards and allowing everyone to support > > them -- not by > > > saying that anyone who wants to participate in sharing must buy code > > > from one particular company. > > > > > > Having said all this, though, NetApp does have plans to leverage SAN > > > technology. We have announced an OEM agreement with > > Brocade. Here are > > > the benefits we expect to achieve: > > > > > > - Attach to lots of disks. > > > > > > A fibre channel loop is limited to 127 drives, but with a 16 > > > port fibre channel switch, the limit goes to almost 2000 > > > drives. With additional switches, you can support an arbitrary > > > number of drives. > > > > > > - Share tape drives between multiple servers. > > > > > > I believe that backup applications are the killer application > > > for SAN. When people buy expensive tape jukeboxes, they want > > > to be able to attach them to multiple servers. With today's > > > SCSI tapes that's a painful job. But with fibre channel and > > > fibre channel switches, it's easy to connect a single tape to > > > any number of hosts. > > > > > > - Disaster Tolerant Solutions > > > > > > Fibre channel switches can do WAN tunneling to provide > > > connections to remote disks without any changes to the server > > > code. This makes it much easier to build remote mirrors for > > > data replication and disaster protection. > > > > > > In conclusion, I believe that NAS and SAN are both important > > > technologies, and the any large data infrastructure in the > > future will > > > include both. I believe that NAS focuses on issues associated with > > > users, applications, and data sharing. I believe that SAN > > focuses on > > > issues associated with disk and tape devices, connection to large > > > numbers of them, and moving data back and forth between > > them. In the > > > long run, any large environment will have both sets of > > issues, and will > > > need both types of solutions. In the short run, NAS makes > > good sense > > > as a starting point, because it is here today and the standards it > > > relies on have been solid for over a decade. > > > > > > I'll go ahead an post the whole paper when I finish, but I still > > > thought it might be useful to share my thoughts in this brief, > > > half-baked form. > > > > > > Dave > >

1 0

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