toasters

toasters@lists.teaparty.net

13515 discussions

Re: NAC SAN
by mds＠gbnet.net 30 Mar '99

30 Mar '99

On Tue 30 Mar, 1999, James Lowe <jlowe(a)iguard.com> wrote: > mark wrote: > (note spelling of Fibre - someone let an English chappy > > into the protocol definition committee) > > nope...french I always stand ready to be corrected. However, from http://www.fcloop.org/FC/FAQs/fcfaq1.htm Q: Why does Fibre Channel spell fiber as fibre? Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added to its feature set some years ago, an ISO (International Standards Organization) task force decided not to rename the technology. The committee decided to change the spelling of Fiber, to the French spelling Fibre, to reduce the association as a fiber optics only medium, while maintaining the name recognition of the Fibre Channel technology. I think the McGraw hill book says that it was the persuasion of an Englishman that lead to that choice being made. This is so wonderfully nitpicky! If someone can provide the committee names we can be absolutely sure. 8) > > : ) > >-- End of excerpt from James Lowe

1 0

sm_recover messages?
by Anthony Fiarito 30 Mar '99

30 Mar '99

We are getting a bunch of: Tue Mar 30 17:59:13 GMT [sm_recover]: no address for host <host.somedomain.com> messages on a few of our filers. Anyone know of a (safe) way to get rid of them? The hostname and IP do not exist in /etc/hosts or /etc/exports. Would removing /etc/sm/* get rid of these messages? Thanks, -alf --- Anthony Fiarito Critical Path

2 1

RE: NAC SAN
by Adams, Christian 30 Mar '99

30 Mar '99

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

Re: NAC SAN
by mds＠gbnet.net 30 Mar '99

30 Mar '99

On Fri 26 Mar, 1999, Will Harper <willh(a)infi.net> wrote: > I also contend that SAN does NOT NECESSARILY imply FiberChannel. In fact, > I see near-time SAN technology taking the route of 1000BaseT, because > studies indicate that more (normal, read "small") data I/O's can be moved, > much more cheaply, over Gigabit than over 100-base FiberChannel. This made me confused - Gb-ether (on fiber) is based on the lower levels of the Fibre Channel (note spelling of Fibre - someone let an English chappy into the protocol definition committee). So to say what was said is to miss a small, but important, technical detail. > >-- End of excerpt from Will Harper

2 1

NAC SAN
by Will Harper 30 Mar '99

30 Mar '99

Tom's statement below (to a NAC 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." He bases this statement on his definition of SAN as "direct-attached storage (as in a direct SCSI connection) via a network of FiberChannel switches - but with the capability of also supporting NFS, CIFS, and HTTP mounts." For instance, in a capability matrix of several vendors, which we recently compiled, he responds "yes" to the question of future SAN migration to an EMC, and to an EMC lookalike, Network Computers. To the same question, he responds "no" to the question of future SAN migration to a NetApp 740 cluster. My position is -- when I see a SAN, I'll tell you what it is, but right now it's just an acronym for "Still Ain't None." I also contend that ALL of the storage vendors will implement SAN technology, if and when the technology gets fully defined and if and when the market demands it. In the meantime, I believe that NetApp is closer to being able to implement a SAN, than EMC and all of it's clones. I also contend that SAN does NOT NECESSARILY imply FiberChannel. In fact, I see near-time SAN technology taking the route of 1000BaseT, because studies indicate that more (normal, read "small") data I/O's can be moved, much more cheaply, over Gigabit than over 100-base FiberChannel. I expect in the future (when and if FiberChannel prices come down, and 1000-base, or 10,000-base FiberChannel is standard), it may become the defacto standard, but, for now, SCSI is the limiting factor on moving data, not the media speed. Are there any experts out there who can shed some light on the subject? Will Harper, MCSE -----Original Message----- From: tkaczma(a)gryf.net [SMTP:tkaczma@gryf.net] Sent: Friday, March 26, 1999 1:30 AM To: NetApp Toasters (E-mail) Subject: Re: NDMP backup speeds On Thu, 25 Mar 1999, Jason D. Kelleher wrote: > That sounds slow. We're readying an F740 for production and our > tests show ~3MB/s (~11GB/hr) over a 110mb full-duplex connection to > a Sun "backup server" with a DLT4000 jukebox. Wow, I'm glad we back up to a locally attached tape library. I'd be even more glad to attach a bigger library to a NAC SAN when we build one. Tom

5 4

RE: FW: Shelves, disks, et al
by Chen, Ray 30 Mar '99

30 Mar '99

The truly sad thing is that you are correct in that most people won't buy Michael's argument but that Michael is correct when he tries to communicate how much work goes into disk drive qualification and how painful the problems can be if you try and put in joe-random-disk drive, even the same model from the same vendor, and get unlucky. Heck, *I* didn't buy the argument until I spent a few years at another company where I exposed to some of what happens in drive qualification and saw what could go wrong in the lab and in the field. To be safe, you really need the same vendor, same drive, and exact same firmware and that's typically very hard to get unless you buy from the system vendor instead of the drive vendor. Even then, that's not a guarantee that you won't get bit, your odds are just better. Ray > -----Original Message----- > From: Jim Davis [mailto:jdavis@CS.Arizona.EDU] > Sent: Thursday, March 11, 1999 10:16 AM > To: toasters(a)mathworks.com > Subject: Re: FW: Shelves, disks, et al > > > On Thu, 11 Mar 1999, Alvarado, Michael wrote: > > > 1. Extensive screening and thorough integration is the difference. > > 2. Special driver software. > > 3. Must meet exacting specifications. > > I think you're going to have a tough time convincing everyone that > slapping a Netapp label on the front of a Seagate drive > somehow makes it > worth the Netapp markup, burnin or no. > > In fact when we bought our first filer we transferred a bunch > of existing > 4gb Seagates bought from Another Vendor to it, *with* the > blessing of tech > support. Is it the right model? they said. Is it one of the > following > firmware revisions? they said. Then go for it, they said. > And the drives > worked just fine. *Technical* restrictions for support, like model > numbers and firmware revisions, sound perfectly reasonable to me. > > Our then salesguy even put them on our support contract. Our current > salesguy won't, but I have a hard time believing that > reflects anything > other than profit maximization. > > And that's not something I begrude Netapp per se. They have a great > product that I've generally been delighted with, and I wish > them all the > financial success the free market can drop in their laps. > But let's be > realistic about what's driving buy-only-our-drives support mandates. >

5 5

Mixed Q-trees and empty directories
by h.g.p.coenen＠philips.com 30 Mar '99

30 Mar '99

Hello We configured a Network Appliance filer with a mixed Q-tree At the root of the Q-tree we created a bundle of directories Some of those directories are empty. Over night those empty directories disappear ! Note only the empty directories at the root of the mixed Q-tree disappear! Does anyone who what is happening ? Regards Henk Coenen

1 0

RE: NAC SAN
by Sam Schorr 30 Mar '99

30 Mar '99

However, the bold or marketleading spot would go to the first to develop such even if it requires the development of a special fibre card and driver that even may be OS specific at first. Standards are set many times by whoever gets there first and grabs market share. For me it means a truly scalable, high performance file network on par and separate from session taffic networks. Just a lust I guess. -----Original Message----- From: Dave Hitz [mailto:hitz@netapp.com] Sent: Monday, March 29, 1999 10:16 AM To: sschorr(a)homestead.com Cc: hitz(a)netapp.com; toasters(a)mathworks.com Subject: Re: NAC SAN > Why not a box with a special OS (ala WAFL) that runs on what servers > recognize as a fibre hub, intercepts the SCSI calls from all attached > servers, and does all the nifty stuff needed to make the SAN(?) look like > locally attached storage? Advantage? Separate file I/O from TCP session > traffic but still allow file sharing in some form or another. SCSI is a raw disk block protocol. SCSI requests are very simple. They say things like "read block twelve-million and two" from disk, or "write block so-and-so to disk." There is no way in SCSI to express file level ideas like "create a file named foo" or "read the first block in a file name bar". If you make the data look like locally attached storage, then all the different hosts will access it using their own local filesystems, so the different hosts will each use a different format, and the data on disk cannot be shared. If you want the data to be shared, then you have to find some industry standard filesystem sharing techniques that everyone has implemented. Today the only such standards are the NAS standards (like NFS, HTTP, Windows Networking). There are a variety of theoretically possible solutions that we could develop, possibly involving new file sharing protocols that could run over SCSI, or "global file systems" that everyone agrees to run on their system. But there are lots of tricky issues to resolve, and the standards work has barely begun, so even in the best possible case, it'd be many years before we could get a true heterogeneous data sharing solution. Dave

3 2

RE: NAC SAN
by Sam Schorr 30 Mar '99

30 Mar '99

Why not a box with a special OS (ala WAFL) that runs on what servers recognize as a fibre hub, intercepts the SCSI calls from all attached servers, and does all the nifty stuff needed to make the SAN(?) look like locally attached storage? Advantage? Separate file I/O from TCP session traffic but still allow file sharing in some form or another. -----Original Message----- From: Dave Hitz [mailto: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

3 3

Anybody using the NetCache software?
by Jaye Mathisen 28 Mar '99

28 Mar '99

As opposed to the appliance? Was thinking about trying it. (Of course, if a LInux version was available, that would be even cooler. :)). I had a C630 in, but wasn't impressed enough to buy it. My squid stuff works OK, but just checking around.

3 3

RE: MAC Name Volumes
by Benn, Paul 28 Mar '99

28 Mar '99

This can't be done. The best way for Macintosh users to access a filer (or any NT box) is to use a product from Thursby Software called Dave. Here's a link to their web site: http://www.thursby.com Regards, Paul -----Original Message----- From: Jim Sanford [mailto:JSanford@rsinc.com] Sent: Friday, March 26, 1999 2:21 PM To: 'Toasters' Subject: MAC Name Volumes Hello everyone, I am trying to setup MAC Naming Services on a NTFS volume on our NetApp. Not sure how this works and if it can be done. The objective is allow our MAC users access for file storage and retrieval on this volume. Anyone have any ideas ??? Thanks, ********************************* Jim Sanford IS Department Research Systems, Inc. *********************************

3 2

Migration to NetApp 740 from AlphaServer 2100
by Joanna Gaski 28 Mar '99

28 Mar '99

I have several concerns about the migration process from an AlphaServer 2100 (Digital UNIX 4.0D) to a NetApp 740. If anyone has specific information / suggestions about any of these issues, you can mail me individually, or the list if it abides by list policy. 1) Filesystem layout We have about 5000 user home directories and several (maybe 10) other logical areas that we will be migrating. Total disk space used initially will be small, about 35G. My guess is that it would be best to keep user directories as a logically separated area (from, say, Alpha binaries) because of differences in default quotas and snapshot and backup policies. Does this sound reasonable, or could it be best to lump them together? 2) Large directory constraints Also, for the user areas, what are the practical constraints on the number of files in a directory? I am most used to AdvFS, under which large directories can be slow to open and read, if a user tries to do something like tab completion on a filename in a directory of 1000 entries. Will I see the same kind of behavior with WAFL, and if so, does anyone have a good suggestion on breaking up the user space? We were thinking of using directory structure organization (nothing at logical partition level) for this. 3) Quotas How sophisticated are the quota manipulation tools? Are there utilities for changing whole sets of quotas, or do admins just use homemade scripts for this? (And if so, does anyone have a pointer to a useful script set?) Also, any suggestions on the best way to migrate AdvFS quotas on user directories? I can foresee the C or scripting part of the AdvFS side of this, but I have no idea what tools we even have to work with on the WAFL side. 4) Backups I am used to vdump and amanda, which don't split single backup sets across multiple tapes. Do the native filer backup utilities handle that? And are backups on a per logical partition basis? 5) Snapshot policies These are defined on a per logical or per physical partition basis? We will be getting the filer documentation before the filer, so that should answer my questions about snapshot policies, backup and quota utilities. But any additional info on these, pointers to public scripts, and insight on the file organization issues is appreciated. Also, references to other info sources are appreciated. Thanks.

4 4

RE: NAC SAN
by Adams, Christian 27 Mar '99

27 Mar '99

Hey Will Harper - The discussion of SAN - or ESN as EMC likes to call it - IMO should address the issues of management. The EMC offerings do include both NAS and direct SCSI connections, but more importantly there is software bundled with the Fibrechannel switches and with the disk arrays which support such functions as dynamic reallocation of drives and bandwidth. The intention of all this additional technology is to give you choices on how you deploy and re-deploy your storage rather than enforcing a traditional static model. And just in case you missed the recent EMC announcement, the file server product supports the Alteon Gigabit Ethernet NIC. But I do agree with you that the term SAN is being used freely without much precision. /Christian Adams EMC > -----Original Message----- > From: Will Harper [SMTP:willh@infi.net] > Sent: Friday, March 26, 1999 6:47 AM > To: NetApp Toasters (E-mail) > Cc: Tri N. Barsell [Barsellt(a)Infi.Net] (E-mail) > Subject: NAC SAN > > Tom's statement below (to a NAC 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." > > He bases this statement on his definition of SAN as "direct-attached > storage (as in a direct SCSI connection) via a network of FiberChannel > switches - but with the capability of also supporting NFS, CIFS, and HTTP > mounts." > > For instance, in a capability matrix of several vendors, which we recently > > compiled, he responds "yes" to the question of future SAN migration to an > EMC, and to an EMC lookalike, Network Computers. To the same question, he > > responds "no" to the question of future SAN migration to a NetApp 740 > cluster. > > My position is -- when I see a SAN, I'll tell you what it is, but right > now > it's just an acronym for "Still Ain't None." I also contend that ALL of > the storage vendors will implement SAN technology, if and when the > technology gets fully defined and if and when the market demands it. In > the meantime, I believe that NetApp is closer to being able to implement a > > SAN, than EMC and all of it's clones. > > I also contend that SAN does NOT NECESSARILY imply FiberChannel. In fact, > > I see near-time SAN technology taking the route of 1000BaseT, because > studies indicate that more (normal, read "small") data I/O's can be moved, > > much more cheaply, over Gigabit than over 100-base FiberChannel. > > I expect in the future (when and if FiberChannel prices come down, and > 1000-base, or 10,000-base FiberChannel is standard), it may become the > defacto standard, but, for now, SCSI is the limiting factor on moving > data, > not the media speed. > > Are there any experts out there who can shed some light on the subject? > > Will Harper, MCSE > > -----Original Message----- > From: tkaczma(a)gryf.net [SMTP:tkaczma@gryf.net] > Sent: Friday, March 26, 1999 1:30 AM > To: NetApp Toasters (E-mail) > Subject: Re: NDMP backup speeds > > > On Thu, 25 Mar 1999, Jason D. Kelleher wrote: > > > That sounds slow. We're readying an F740 for production and our > > tests show ~3MB/s (~11GB/hr) over a 110mb full-duplex connection to > > a Sun "backup server" with a DLT4000 jukebox. > > Wow, I'm glad we back up to a locally attached tape library. I'd be even > more glad to attach a bigger library to a NAC SAN when we build one. > > Tom

1 0

RE: NDMP backup speeds
by Kelly Wyatt 27 Mar '99

27 Mar '99

The top comment was mine. That figure was the average speed we are getting backing up our filers (10 760's, 300-600Gb each. We are backing up each volume separately). So, the number I used (15, but I think we actually average around 17.5), was for one tape stream. So, since we have two tape streams, we actually achieve twice that per hour. Note that our times vary from 12gb/hour to 23gb/hour, depending on the filer. We believe this to be due to the nature of the data on the various filers. Looking forward to seeing what we can accomplish with two tape drives/four tape streams. By the way, we are using NetBackup with NDMP to a StorageTek 9710 with DLT7000 drives and are using the compressed tape devices. Kelly -- Kelly Wyatt Systems Programmer SAS Institute Inc. Kelly.Wyatt(a)SAS.com <mailto:Kelly.Wyatt@SAS.com> www.sas.com -----Original Message----- From: Will Harper [mailto:willh@infi.net] Sent: Thursday, March 25, 1999 9:16 AM To: NetApp Toasters (E-mail) Subject: NDMP backup speeds Can I have the users' opinions? The top statement was from an unnamed NetApp 740 filer user. The bottom part is NetApp's rebuttal. I see this as two questions. (1) can a 740 support two tape adapters? and (2) who is right(er) about NDMP backup speeds on a 740, with one tape drive adapter? ------------------------------------------------------------------------ ------------------------------- [USER] > With a (potentially) 1.4Tb filer, can it be backed up with two drives > reasonable amount of time???? At 15gb/hr (conservative with > NDMP), that's > lots of hours to back em up..." ------------------------------------------------------------------------ ------------------------------ [NetApp] Two tape adapter support was certified (tested) only on the F760 and the F630. It was a matter of testing resources with our latest release. Dump speeds run at up to 25 GB/hr with 1 dump and up to 45 GB/hr with two dumps to two tape drives on a single tape adapter.

1 0

Used machines
by scw＠seas.ucla.edu 27 Mar '99

27 Mar '99

We currently have 2 machines (F220 W/14X4Gb, F330 W/21x4GB) that MAY become surplus to our requirements. Is there are market in used toasters (we'll sweep out the crumbs)? If so are there any guesses as to what we can expect to get for these machines? ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

RE: MAC Name Volumes
by Benn, Paul 26 Mar '99

26 Mar '99

Yes, NT Server does ship with Services for Macintosh. The problem with it is, it does not support mapped ("mounted") drive letters. -----Original Message----- From: Will Harper [mailto:willh@infi.net] Sent: Friday, March 26, 1999 3:30 PM To: 'Jim Sanford' Cc: NetApp Toasters (E-mail) Subject: RE: MAC Name Volumes Can you use an NT server to provide file and print service for the Macs? NT sees Mac as a native client. The NetApp box should see the NT server's file area as just one more standard NTFS mount. -----Original Message----- From: Jim Sanford [SMTP:JSanford@rsinc.com] Sent: Friday, March 26, 1999 5:21 PM To: 'Toasters' Subject: MAC Name Volumes Hello everyone, I am trying to setup MAC Naming Services on a NTFS volume on our NetApp. Not sure how this works and if it can be done. The objective is allow our MAC users access for file storage and retrieval on this volume. Anyone have any ideas ??? Thanks, ********************************* Jim Sanford IS Department Research Systems, Inc. *********************************

1 0

RE: MAC Name Volumes
by Will Harper 26 Mar '99

26 Mar '99

Can you use an NT server to provide file and print service for the Macs? NT sees Mac as a native client. The NetApp box should see the NT server's file area as just one more standard NTFS mount. -----Original Message----- From: Jim Sanford [SMTP:JSanford@rsinc.com] Sent: Friday, March 26, 1999 5:21 PM To: 'Toasters' Subject: MAC Name Volumes Hello everyone, I am trying to setup MAC Naming Services on a NTFS volume on our NetApp. Not sure how this works and if it can be done. The objective is allow our MAC users access for file storage and retrieval on this volume. Anyone have any ideas ??? Thanks, ********************************* Jim Sanford IS Department Research Systems, Inc. *********************************

1 0

MAC Name Volumes
by Jim Sanford 26 Mar '99

26 Mar '99

Hello everyone, I am trying to setup MAC Naming Services on a NTFS volume on our NetApp. Not sure how this works and if it can be done. The objective is allow our MAC users access for file storage and retrieval on this volume. Anyone have any ideas ??? Thanks, ********************************* Jim Sanford IS Department Research Systems, Inc. *********************************

1 0

RE: Logical Volumes or Partitions
by Val Bercovici (NetApp) 26 Mar '99

26 Mar '99

One quick correction re: > > Maximum number of logical volumes, or partitions > > Max number of *physical* volumes is 23. I consider qtrees to be > *logical* volumes or partitions and if you make each qtree a > share then you can have a max of 14,400 on a F740. > The maximum number of qtrees is 254 (per volume I think). The maximum number of CIFS shares is 14,400 per F740. -Val. ============================================== Val Bercovici Office: (613)724-8674 Systems Engineer Pager: (800)566-1751 Network Appliance valb(a)netapp.com Ottawa, Canada FAST,SIMPLE,RELIABLE ==============================================

3 5

NDMP backup speeds
by Will Harper 26 Mar '99

26 Mar '99

Can I have the users' opinions? The top statement was from an unnamed NetApp 740 filer user. The bottom part is NetApp's rebuttal. I see this as two questions. (1) can a 740 support two tape adapters? and (2) who is right(er) about NDMP backup speeds on a 740, with one tape drive adapter? ------------------------------------------------------------------------ ------------------------------- [USER] > With a (potentially) 1.4Tb filer, can it be backed up with two drives > reasonable amount of time???? At 15gb/hr (conservative with > NDMP), that's > lots of hours to back em up..." ------------------------------------------------------------------------ ------------------------------ [NetApp] Two tape adapter support was certified (tested) only on the F760 and the F630. It was a matter of testing resources with our latest release. Dump speeds run at up to 25 GB/hr with 1 dump and up to 45 GB/hr with two dumps to two tape drives on a single tape adapter.

5 5

RE: Migration to NetApp 740 from AlphaServer 2100
by Smith, Gil 25 Mar '99

25 Mar '99

this paper, on our external WWW, describes what WAFL does regarding directory hashing, http://www.netapp.com/technology/level3/3006.html -----Original Message----- From: Strange, Steve [mailto:steve.strange@netapp.com] Sent: Thursday, March 25, 1999 4:31 PM To: 'Joanna Gaski'; toasters(a)mathworks.com Subject: RE: Migration to NetApp 740 from AlphaServer 2100 If you're used to AdvFS' performance with large directories, I think you'll be quite happy with WAFL in that regard. Last I knew, I don't think AdvFS did any directory hashing at all, so having 10K or more files in a single directory was not much fun. Steve -----Original Message----- From: Joanna Gaski [mailto:jgaski@WPI.EDU] Sent: Thursday, March 25, 1999 9:14 AM To: toasters(a)mathworks.com Subject: Migration to NetApp 740 from AlphaServer 2100 2) Large directory constraints Also, for the user areas, what are the practical constraints on the number of files in a directory? I am most used to AdvFS, under which large directories can be slow to open and read, if a user tries to do something like tab completion on a filename in a directory of 1000 entries. Will I see the same kind of behavior with WAFL, and if so, does anyone have a good suggestion on breaking up the user space? We were thinking of using directory structure organization (nothing at logical partition level) for this.

1 0

RE: Migration to NetApp 740 from AlphaServer 2100
by Strange, Steve 25 Mar '99

25 Mar '99

If you're used to AdvFS' performance with large directories, I think you'll be quite happy with WAFL in that regard. Last I knew, I don't think AdvFS did any directory hashing at all, so having 10K or more files in a single directory was not much fun. Steve -----Original Message----- From: Joanna Gaski [mailto:jgaski@WPI.EDU] Sent: Thursday, March 25, 1999 9:14 AM To: toasters(a)mathworks.com Subject: Migration to NetApp 740 from AlphaServer 2100 2) Large directory constraints Also, for the user areas, what are the practical constraints on the number of files in a directory? I am most used to AdvFS, under which large directories can be slow to open and read, if a user tries to do something like tab completion on a filename in a directory of 1000 entries. Will I see the same kind of behavior with WAFL, and if so, does anyone have a good suggestion on breaking up the user space? We were thinking of using directory structure organization (nothing at logical partition level) for this.

1 0

RE: NDMP backup speeds
by Smith, Gil 25 Mar '99

25 Mar '99

Hi, Not sure but... You may not have the 8MB DLT7000. An early revision only had 4MB I believe which didn't provide the throughput expected so the device was rev'd by Quantum and given 8MB. Check with your tape vendor. -----Original Message----- From: mgx(a)spruce.lsd.ornl.gov [mailto:mgx@spruce.lsd.ornl.gov] Sent: Thursday, March 25, 1999 2:18 PM To: Jason D. Kelleher Cc: mgx(a)spruce.lsd.ornl.gov; Will Harper; NetApp Toasters E-mail" Subject: Re: NDMP backup speeds i'd love to see 35-45GB/hour. the netapps are on a 100MB full-duplex lan. we're using budtool 4.5/ndmp and the tapedevice is nrst0a (70GB/compressed). this is what the netapp thinks about the tape drive/scsi adapter: slot 2: SCSI Host Adapter 2 (QLogic ISP 1040B) Firmware Version 2.26 Clock Rate 60MHz. 4: QUANTUM DLT7000 1E48 <------------------------ In-Band Enclosure Services 0 Swap Events, 0 Enclosure Events where is my problem i wonder? -- michael On Thu, Mar 25, Jason D. Kelleher wrote: > In message <19990325105303.A7088(a)avatar.lsd.ornl.gov>, mgx(a)spruce.lsd.ornl.g > ov writes: > >fwiw, i'm backing up my two F520's via ndmp to a DLT7000 and i'm averaging > >about 11.7GB/hour. > > > >-- michael > > That sounds slow. We're readying an F740 for production and our > tests show ~3MB/s (~11GB/hr) over a 110mb full-duplex connection to > a Sun "backup server" with a DLT4000 jukebox. That's theoretical > max on a DLT4000 and still plenty of room on the network. Haven't > tried multiple concurrent dumps yet, so I'm not sure how well that > would scale. You should see about triple the throughput to a > single DLT7000. > > jason > >

1 0

Logical Volumes or Partitions
by Will Harper 25 Mar '99

25 Mar '99

Can anybody tell me what the following max/mins are, with a default 740: Maximum number of logical volumes, or partitions Maximum size of a logical volume or partition Maximum PRACTICAL size of a logical volume or partition Minimum size of a logical volume or partition Minimum PRACTICAL size of a volume or partition A URL pointer would also be helpful if anybody has one. Thanks Will Harper, MCSE InfiNet, Norfolk, VA

2 1

New 'raid add' replacement
by Dane Jasper 25 Mar '99

25 Mar '99

We just had a minor panic as our filer filled - the 'raid add' command is gone. For your reference, if you've moved to the new OS, here's the replacement command: vol add vol0 1 This presumes you have one volume, which is the default. "vol status" will give you a list. This will add any spare disk to the volume - you can also specify which one to add if you'd like. A handy trick if you run out of space is to reduce your snap reserve space by a few percent while the spare disk is added to the volume. Adding the disk takes a bit of time, so this space stolen from snapshots will keep you running. -- Dane Jasper Sonic (707)522-1001 (33.6kbps) (707)522-1000 (Voice) mailto:support@sonic.net http://www.sonic.net Key fingerprint = A5 D6 6E 16 D8 81 BA E9 CB BD A9 77 B3 AF 45 53

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