toasters March 1999

toasters@lists.teaparty.net

138 participants
192 discussions

Start a nNew thread

NIS+
by Jason Middlebrooks 15 Mar '99

15 Mar '99

I know that the netapps support NIS but what about NIS+ ????? Thanks for all the answers. Jason

3 2

filer-mrtg
by Graham C. Knight 12 Mar '99

12 Mar '99

In a fit of needing a diversion i installed filer-mrtg yesterday and boy is it cool! I do have a question for those in the know though - i'm having a hard time correlating the "Network Kbytes sent and recieved" with the "Network Interface Sent And Received" I would figure that on a system with 1 interface that these graphs should be pretty much identical - but on some systems the path of the graph is very similar but the numbers are really different - sometimes as much as 2-1 in favor of the "Network Kbytes Sent and Recieved" category. Is this a bug - or am i missing something here.... Thanks for any info you all can provide. GRaham

2 1

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

12 Mar '99

Probably because we qualified both. Dual-sourcing critical components like disk drives is standard procedure when multiple sources are available. (I can't say for sure because the qual for those happened before I got here.) Doing so has saved the posterior anatomy of more than one system vendor when it turns out that the product delivered by one source suddenly develops problems due to manufacturing process changes that occurred after qualification and/or problems that take a long time to appear (anyone remember the IBM stiction problems :-), or availability simply becomes a problem. I would imagine that most vendors don't want to qualify more than 2 both due to the cost of each qual and also because of the fact that qualifying N drives turns into an N^2 problem. If you qualify 3 drives, you have to ensure that all combinations work (e.g. a SCSI bus with drive A, B, and C works well, ditto for just drive A, B, and drive A, C, etc.). You wouldn't think that this should be an issue but it has been in the past. I think you can get away with skimping on some testing for situations where the N Gbytes and M Gbyte drives from the same manufacturer are the same family running the same firmware. But even then, I suspect you have to check for vibration issues in your supported enclosures. Ray > -----Original Message----- > From: Jonah Yokubaitis [mailto:barron@staff.texas.net] > Sent: Thursday, March 11, 1999 7:18 PM > To: Chen, Ray > Cc: 'Jim Davis'; toasters(a)mathworks.com > Subject: RE: FW: Shelves, disks, et al > > > > On Thu, 11 Mar 1999, Chen, Ray wrote: > > |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, > > If that's the case, then why does one of our F630s (9gig SCSI drives > in it) having 2 *different* model numbers of drives in it? All drives > came directly from Netapp. > > Jonah > > Jonah Barron Yokubaitis > http://www.texas.net <--- The ISP > http://www.giganews.com <--- News Outsourcing >

1 0

Re: CIFS share access?
by Allan Burrington 12 Mar '99

12 Mar '99

Assuming the filer can handle standard PC functionality - you can use subst to map any path to a drive letter. Target has share: C$ Within the C$ share is a directory named 'foo'. Do: subst z: \\target\c$\foo You now have z: rooted at the foo directory. -A ----- Original Message ----- From: Keith Brown <keith(a)netapp.com> To: Alexander Strauss <strauss(a)ti.com>; <toasters(a)mathworks.com> Sent: Thursday, March 11, 1999 10:27 AM Subject: Re: CIFS share access? >>I shared the directory where most of our Unix-Homes are located under >>the CIFS sharename UNIX_HOMES. There's no problem to connect >>\\filer\unix_homes, but I cannot connect directly to a sub-directory, >>i.e. \\filer\unix_homes\alex. > >As has already been stated, the cifs.home_dir option of Data ONTAP might >provide you with the functionality that you are looking for. > >However... I suspect that you *might* be under the impression that CIFS shares >are supposed to work like NFS exports in the above respect. Alas they don't. > >As you probably know, if you export "/home/keith" via NFS, it makes it possible >to directly mount any subdirectory of "/home/keith" from an NFS client (e.g. >"/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share >"/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client is >"\\FILERNAME\KEITHDIR". You can't do something like a: > > net use q: \\FILERNAME\KEITHDIR\docs\cifs > >Keith >

2 1

Re: CIFS share access?
by Mark Muhlestein 11 Mar '99

11 Mar '99

You are correct, Alan; this works fine. Thanks for the good pointer. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Allan Burrington <allan(a)mirapoint.com> To: Keith Brown <keith(a)netapp.com>; Alexander Strauss <strauss(a)ti.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Thursday, March 11, 1999 11:48 AM Subject: Re: CIFS share access? >Assuming the filer can handle standard PC functionality - you can use subst >to map any path to a drive letter. > > Target has share: C$ > Within the C$ share is a directory named 'foo'. > >Do: > subst z: \\target\c$\foo > >You now have z: rooted at the foo directory. > >-A > >----- Original Message ----- >From: Keith Brown <keith(a)netapp.com> >To: Alexander Strauss <strauss(a)ti.com>; <toasters(a)mathworks.com> >Sent: Thursday, March 11, 1999 10:27 AM >Subject: Re: CIFS share access? > > >>>I shared the directory where most of our Unix-Homes are located under >>>the CIFS sharename UNIX_HOMES. There's no problem to connect >>>\\filer\unix_homes, but I cannot connect directly to a sub-directory, >>>i.e. \\filer\unix_homes\alex. >> >>As has already been stated, the cifs.home_dir option of Data ONTAP might >>provide you with the functionality that you are looking for. >> >>However... I suspect that you *might* be under the impression that CIFS >shares >>are supposed to work like NFS exports in the above respect. Alas they >don't. >> >>As you probably know, if you export "/home/keith" via NFS, it makes it >possible >>to directly mount any subdirectory of "/home/keith" from an NFS client >(e.g. >>"/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share >>"/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client >is >>"\\FILERNAME\KEITHDIR". You can't do something like a: >> >> net use q: \\FILERNAME\KEITHDIR\docs\cifs >> >>Keith >> > >

1 0

Re: NFS fundamentally broken ??? (HA implications)
by mds＠gbnet.net 11 Mar '99

11 Mar '99

On Wed 10 Mar, 1999, Philip Thomas <thomas(a)act.sps.mot.com> wrote: > Hi, > An experienced sys admin and a colleague of mine argue that > NFS is "fundamentally broken", in the sense that because of > it's stateless architecture, a NFS client can "hang" during > shutdown if it's NFS server(s) does not respond. > This is aggravated when an "ack" is lost between server/client. > He claims to have gone through NFS code while he was at a prestigious university. > Granted I am not an expert, all the years I have worked with NFS, > I never had a problem shutting down a system because it's NFS > mount was not "responding". > But I am hoping for folks with "theoretical" background to shed some > more light into the above argument. > Both from experience, and from what I know of the workings of NFS, it *is* possible for a client to hang for valid reasons, even when shutting down, on mounts from unresponsive NFS servers. You can work around this by using dangerous options like soft mounts, or by killing processes that are using the NFS mounted areas and forcing the client to umount problem mounts. Excitingly, NetApp's use clever status-monitoring such that they can maintain NFS locks (even though they're just advisory) when the server reboots, and they, as servers, can suffer from clients that have died away with open locks. NetApp's spend some time every few minutes looking for such clients, and slowing down a bit while they do so. They also syslog a lot about that sort of thing. So there's a bit of a two-way street here, even though NFS is putatively stateless. We recently hit a bug related to that and a very helpful NetApp engineer (who I won't name to save him any embarrassment) is looking at how to smooth out that sort of wrinkle in the future - in fact at least part of that is going into a patch release in the near future. Check out the differences between intr and non-intr, and soft and hard mount options in the man-pages, and Hal Stern's book - I think that might make things clearer. > This brings to the second question. > The same person emphasize the above issue as an added reason for not > having NFS mount points on his HP High Availability (ServiceGuard). > Is there any site out there, in this wide world, using HP's ServiceGuard > (or any other HA) on a system that is an NFS client and would like to > comment on their experience in private or in this forum. Ah. There he has a point in principle, but in practicality I'd expect there to be no particular issue. We run a couple of Sun HA1.3 clusters here, and there's a Sun Cluster 2.x going in that I've had some sight of. They all use NFS mounts to import filesystems from servers, both Unix and NetApp. The design of HA clusters basically hinges on timeouts (as NFS does itself, thinking about it). If a node in an HA cluster must go down, it *will*, even if it's hanging on NFS mounts from elsewhere - usually because one timeout or other will trigger it's suicide, or for a sibling to commit fratricide (sororicide?). Obviously suicide or fratricide leaves a machine open to problems where neat and tidy shutdown without hanging on NFS mounts will be far superior. The fact that one node is having problems with an NFS mount probably means the other node(s) will too, and that will impact the overall HA cluster, which is bad(tm). So the secret is to make sure any mounts in an HA cluster are (a) required absolutely for the function the cluster provides and (b) are at least as reliable as the cluster is intended to be. I'm happy to use our NetApp's fs's on our HA clusters. I happen to think the group implementing the Cluster 2.x environment are storing up problems for themselves by using Unix NFS servers. Your mileage will vary. Hope that's helpful. > > Philip Thomas > Motorola - PEL, M/S M350 > 2200 W. Broadway M350 > Mesa, AZ 85202 > rxjs80(a)email.sps.mot.com > (602) 655-3678 > (602) 655-2285 (fax) >-- End of excerpt from Philip Thomas

2 1

Re: CIFS share access?
by Keith Brown 11 Mar '99

11 Mar '99

>I shared the directory where most of our Unix-Homes are located under >the CIFS sharename UNIX_HOMES. There's no problem to connect >\\filer\unix_homes, but I cannot connect directly to a sub-directory, >i.e. \\filer\unix_homes\alex. As has already been stated, the cifs.home_dir option of Data ONTAP might provide you with the functionality that you are looking for. However... I suspect that you *might* be under the impression that CIFS shares are supposed to work like NFS exports in the above respect. Alas they don't. As you probably know, if you export "/home/keith" via NFS, it makes it possible to directly mount any subdirectory of "/home/keith" from an NFS client (e.g. "/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share "/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client is "\\FILERNAME\KEITHDIR". You can't do something like a: net use q: \\FILERNAME\KEITHDIR\docs\cifs Keith

1 0

FW: Shelves, disks, et al
by Alvarado, Michael 11 Mar '99

11 Mar '99

-----Original Message----- From: Stephen C. Woods [mailto:scw@sprynet.com] Sent: Wednesday, March 10, 1999 12:45 PM To: toasters(a)mathworks.com Subject: Shelves, disks, et al I've got a couple of questions for the list. (1) Can 9 GB drives be used in the same type shelves as 4 GB drives? I'm talking about narrow drives here. (2) Can they be mixed (4 and 9 GB drives) in a shelf? How about on the same controller? (3) Is there any source for drives other than Netapps? (4) If one obtains drives from another source can they be put under support (yeah I know, fat chance)? Would they void current hardware support? Would they void software support? (5) If I had some extra narrow shelves is there a market? We're thinking about decommissioning one of our older filers. Reply-to set to the list, as I'll bet dollars to doughnuts that other folks are interested. Thanks in advance Steve Woods ******************************************************************** Hi Steve and to the other members of the toasters(a)mathworks.com list I am happy to answer the questions you posed about Network Appliance storage Regarding the question about using non-Network Appliance disk drives in our filers. Our policy is that only Network Appliance-supplied disk drives can be used in our filers else the warranty is voided on the filers. There are very good reasons behind this policy. 1. Extensive screening and thorough integration is the difference. Network Appliance-supplied drives are burned in, carefully integrated, and screened to minimize reliability problems and maximize uptime. 2. Special driver software. Network Appliance drives have special driver software that has been written to optimize the performance of drives and filers. Every disk drive has unique characteristics. We carefully evaluate those characteristics and we specify specific changes to ensure the best possible performance. 3. Must meet exacting specifications. Drives are often seen as indistinguishable and interchangeable. This is not the case. 9 GB drives can differ by power consumption, vibration characteristics, firmware levels, revision levels, cooling requirements, actual performance, and quality. Network Appliance tests to ensure those specific characteristics working well together. So, just buying a 9 GB drive is not the answer. Buying to our engineering and purchasing specifications is what is needed. 4. Total Solutions. Network Appliance provides a total product solution. These drives are part of the total Network Appliance solution. Our total solution is not designed to work with other components, even if the raw component manufacturer is the same. 5. Support, Support, Support. Support and service are an integral part of our products. The advance replacement feature and technical support on our products is part of what sets drives purchased from Network Appliance apart from drives purchased from others. We stand behind our drives in a way other outlets won't. 6. Extensive quality control. NetApp has an extensive quality control system in place. We have to be sure of the whole process by which components (such as disk drive) are manufactured, tested, and delivered. Purchasing from another source prevents Network Appliance from ensuring the customer of the quality they depend on. Plus, the unique changes our vendors perform for us will not be found in drives purchased from other sources. 7. We fail what commodity outlets buy. Finally, drives that customers can buy from commodity outlets have failed the exacting quality, performance, and reliability standards of Network Appliance. Network Appliance has specifically rejected the drives that show up at these venues. In addition, drives at commodity outlets are subject to damaging handling and failure-inducing shock and vibration. Customers who buy from commodity outlets suffer greater data loss, shorter drive life, and higher incidences of failure and downtime. Regarding the question about using 9 GB drives in the same shelves as 4 GB drives, there are several guidelines that need to be heeded. First, the disk shelves that supported 4 Gb drives did not support properly the 9 Gb drives and network Appliance was forced to go to a new shelf design. Therefore, our engineering analysis determined that putting 9 GB drives in the 4 GB shelves would result in insufficient power and cooling to ensure the reliability our users have come to expect from Network Appliance. Second, there are guidelines for using 4 GB drives in new filer models. These guidelines take into account the operating system limitations of each filer. Be sure to review the technical product bulletins to ensure that the operating system limits on your filer are accounted for in terms of total storage capacity as well as the maximum number of slots available for the dual-channel SCSI adapters. Let me summarize these guidelines for you: Filer Storage Options F220 14 x 4 GB Fast Narrow SCSI drives F330 28 x 4 GB Fast Narrow SCSI drive OR 14 x 4 GB Fast Narrow SCSI and 7 x 9 GB drives F540 52 x 4 GB Fast Wide SCSI drives OR 26 x 4 GB Fast Wide SCSI and 13 x 9 GB Fast Wide SCSI drives Note: 4 GB count could include up to 24 Fast Narrow SCSI drives F210 14 x 4 GB Fast Wide SCSI drives OR 7 x 9 GB Fast Wide SCSI drives F230 14 x 4 GB Fast Wide SCSI drives OR 14 x 9 GB Fast Wide SCSI drives OR 7 x 4 GB and 7 x 9 GB drives F520 28 x 4 GB Fast Wide SCSI drives OR 28 x 9 GB Fast Wide SCSI drives OR 56 x 9 GB FC-AL drives OR 14 x 4 Fast Wide SCSI GB and 14 x 9 Fast Wide SCSI GB OR 21 x 4 GB Fast Wide SCSI and 7 x 9 GB Fast Wide SCSI OR 7 x 4 GB Fast Wide SCSI and 21 x 9 GB Fast Wide SCSI F630 52 x 4 GB Fast Wide SCSI drives OR 52 x 9 GB Fast Wide SCSI drives OR Up to 168 x 9 GB FC-AL drives OR Up to 84 x 18 GB FC-AL drives

2 1

Re: cifs reconfiguration (workgroup -> domain)
by Keith Brown 11 Mar '99

11 Mar '99

>Caution: It is difficult to change this decision after you run setup. Hmmm. I'm not sure what drove us to make this statement in the documentation, as making this transition is actually quite simple and straightforward. I *think* that it might have been the fact that CIFS has to be stopped and restarted to move from workgroup mode into domain mode (or vice versa), thus temporarily and briefly disrupting file service to Windows clients. However, if you can arrange to make the transition at a time of low usage (the small hours of the morning for example), the disruption should have minimal impact. The whole operation should take just a few minutes. You need to execute a "cifs terminate" followed by another "cifs setup" and then you're basically done. ><gulp> Okay, I do want to change (from a workgroup to a domain). Good move! :-) >How difficult is "difficult"? As I mentioned, not very (aside from the brief service disruption). >How does changing the authentication method from NIS to a domain >controller affect the UNIX boxes accessing the filer via NFS? It doesn't. However, if you do start creating NTFS or MIXED mode file systems after making the transition, you may need to take a look at how UNIX security is effected by the use of these modes. There are two papers in the "Technology" section of our web site that explain these issues quite well. If you stick with UNIX mode file systems however, you have absolutely no reason to be concerned about how the new domain mode of CIFS effects NFS, because it doesn't. Keith

3 3

Re: CIFS share access?
by Alexander Strauss 11 Mar '99

11 Mar '99

Graham, this only works if the Unix home has the same name as the NT username ... a workaround would be to create symlinks. Thank you, Alex "Graham C. Knight" wrote: > > Try setting your cifs.home_dir option > to /path/unix_homes > > That will allow users to map their directories > as \\filer\username > > There a re a bunch of acveats with using > the cifs.home_dir option though - the main > one being that there can only be one > cifs.home_dir mount point per filer. The > second one being that users can only mount their > own home directories with this method - they cannot > mount other peoples homes. > > Graham > > Alexander Strauss wrote: > > > > Hello, > > > > I shared the directory where most of our Unix-Homes are located under > > the CIFS sharename UNIX_HOMES. There's no problem to connect > > \\filer\unix_homes, but I cannot connect directly to a sub-directory, > > i.e. \\filer\unix_homes\alex. > > > > Is this way to connect not implemented or is it a configuration problem? > > > > thank you, > > -- > > Alexander Strauss - Email: strauss(a)ti.com - TI-MSG: ALST > > System Administrator - Mixed Signal & Logic Products Europe > > Texas Instruments Deutschland GmbH, 85350 Freising, Germany > > Phone: +49 8161 80-3606 - Fax: +49 8161 80-4477 -- Alexander Strauss - Email: strauss(a)ti.com - TI-MSG: ALST System Administrator - Mixed Signal & Logic Products Europe Texas Instruments Deutschland GmbH, 85350 Freising, Germany Phone: +49 8161 80-3606 - Fax: +49 8161 80-4477

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
20
Older →

Jump to page:

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 March 1999