toasters

toasters@lists.teaparty.net

1 participants
13514 discussions

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

CIFS share access?
by Alexander Strauss 11 Mar '99

11 Mar '99

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

2 1

Shelves, disks, et al
by Stephen C. Woods 11 Mar '99

11 Mar '99

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

2 1

RE: Accessing CIFS shares with Unix authentication
by Will Harper 11 Mar '99

11 Mar '99

I can't answer your question directly, but I have "heard" that CIFS is a problem. It works ok, when it is working, but when it hiccups, it is not easily corrected. When a CIFS connection is broken, it stays broken. A vendor's engineer (Auspex) told me that he had found that an NFS client on NT actually provided better end results for all of the H-A storage systems that he had worked with. He suggested Samba or Hummingbird. NFS, he explained, keeps trying to reconnect until you fix the problem, and then NFS fixes itself. Will Harper, MCSE -----Original Message----- From: P.S.Jones [SMTP:P.S.Jones@durham.ac.uk] Sent: Wednesday, March 10, 1999 11:01 AM To: toasters(a)mathworks.com Subject: Accessing CIFS shares with Unix authentication We have a Network Appliance 740 Filer for evaluation and want to try it in a mixed Unix and NT environment. I think we can handle the Unix side without any real problems. What we are struggling with is how to provide access to the CIFS file store to our NT clients by supplying Unix credentials? I'll explain this in a bit more detail. Our NT service has no user accounts, or rather it has one, a general auto logon account. Within this account's logon script we prompt for authentication details (real user ID and password) and then map network shares against our existing Netware 3.1 servers. In the summer we plan to retire Netware 3.1 and provide the home file store from a Unix like system. We've tried Samba and quite like it but we want to evaluate the Filer as well. But how can we map a CIFS share from the Filer using just Unix credentials? I'm trying to read the documentation at the moment and have come across the usermap.cfg file mechanism, but this doesn't seem quite appropriate since we don't have any NT accounts. I wonder if anyone on this list has solved a problem like this? Are we going to have to run Samba anyway for the authentication? Any comments gratefully received. -- Paul Jones, ITS, University of Durham, South Road, Durham DH1 3LE Email: P.S.Jones(a)durham.ac.uk Phone/Fax: 0191 374 2879/3741

4 4

Re: Accessing CIFS shares with Unix authentication
by Mark Muhlestein 10 Mar '99

10 Mar '99

>At 01:25 pm 3/10/99 -0500, Will Harper wrote: >>I can't answer your question directly, but I have "heard" that CIFS is a >>problem. It works ok, when it is working, but when it hiccups, it is not >>easily corrected. When a CIFS connection is broken, it stays broken. >> >>A vendor's engineer (Auspex) told me that he had found that an NFS client >>on NT actually provided better end results for all of the H-A storage >>systems that he had worked with. He suggested Samba or Hummingbird. NFS, >>he explained, keeps trying to reconnect until you fix the problem, and then >>NFS fixes itself. Samba? Samba is a CIFS server. As Dave Hitz pointed out, there are tradeoffs with the various protocols, but with a Netapp box you can use whichever suits your needs best. Mark Muhlestein -- mmm(a)netapp.com

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