toasters

toasters@lists.teaparty.net

13531 discussions

Re: Netapp nfs over tcp
by Gordon Keegan 16 Feb '99

16 Feb '99

> On Fri, 12 Feb 1999, Gordon Keegan wrote: > > > > > Speaking of NFS over TCP, we'd also like to try turning nfs.tcp.enable > > on to do some testing. Does anyone know if this would affect current > > mounts if we just enable it at the filer command line with > > "options nfs.tcp.enable on", or can that be done? > > Your clients aren't currently mounting with tcp, you'll have to have > them umount the server and then remount after you've enabled it on > the server. So it is kind of a chore. > I probably didn't phrase the question as well as I should have. If I enable NFS over TCP, then mount a single host using TCP and do testing, will that stomp on the dozens of other clients that still have their UDP mounts? (there; hopefully that was better :) -- Gordon Keegan, M10-10 Phone: (508) 261-4696 Motorola ISG Fax: (508) 261-5757 20 Cabot Boulevard Mansfield, MA 02048 email: lgk011(a)dma.isg.mot.com

6 5

Re: Sharing files between NT and Unix
by mds＠gbnet.net 16 Feb '99

16 Feb '99

On Tue 16 Feb, 1999, "Schepers, Jan" <Jan.Schepers(a)nl.origin-it.com> wrote: > Hello People, > > > Apparently I have never understood the concept of an netapp filer, > but this is what an HP guy is trying to tell me: > "NetApps Filers can't share files between NT and Unix *simultaneously*." Well as the above statment is totally, provably incorrect... > > What could he have meant ? ...he evidently meant 'I will lie outrageously to try to boost my company's chances of a sale'. So many companies' sales-forces resort to this that I find myself proposing a cull of salespeople - in the Canadian-baby-seal style, to preserve the viability of the rest of the species. > > cheers, You're most welcome. > > Jan > >-- End of excerpt from "Schepers, Jan"

1 0

Re: Netapp nfs over tcp
by Daniel Quinlan 16 Feb '99

16 Feb '99

Actually, I have one question: is there any reason we wouldn't want to start using NFSv3/UDP for Solaris boxes on our switched LAN? - Dan

2 1

Shared Snapshot directory
by Patrick.Day.B＠bayer.com 16 Feb '99

16 Feb '99

This is kinda long, so i appologize ahead of time... We are running OnTap version 5.2.1 on a 740. When we ordered the system we got an autoloader backup (powerstor L500). Unfortuantly, Ontap can't handle the loader to meet our needs. So, as a solution, we attached the device to an NT server running BackupExec 7.2. I was thinking that in order to get a good backup of the system i could share out the .snapshot/nightly.0 as shapc$. This would give me a look at the system from the the root directory. At first it appeared that this would work fine, the CIFS SHARE command shows the snapc$ share as always being mapped to the nightly.0 directory, even after the nightly.0 is changed to nightly.1. However, when i did a snap list command, it shows that the nightly.1 is "busy". When i do a backup, it backs up the OLD snapshot directory and when i open the directory, i confirm that it is the old data. It seems that the Netfiler remembers which directory is mapped regardless of the name. I have found that when i reboot, the share is recreated to the correct directory, but rebooting every night is not an option. I have also changed the saved nightly snapshots to 1. The system will not create a new snapshot because the old one is busy and of course, having only one nightly snapshot is not an option. Is there any way to get the netfiler to refresh the share automatically? ---or make it stupid and not remeber that today's nightly.1 is yesterday's nightly.0? Any input would be appreciated. --Patrick Day Sys. Admin Bayer Corporation

2 1

Linux NFS over TCP
by Daniel Quinlan 16 Feb '99

16 Feb '99

FYI - with the current Linux release (version 2.2.1), NFS over TCP is now working (it went into 2.2.0-pre6). But, only NFS version 2. Anyone have an opinion on NFSv2 over TCP compared to NFSv2 over UDP? I seem to remember seeing some benchmark that showed it was better, but now I can only find benchmarks (like SPEC SFS 2.0) that show it has a faster response time, but not throughput. - Dan

1 0

Tape Drives Question????
by Jason Middlebrooks 15 Feb '99

15 Feb '99

Will a Redwood Tape Drive work with a Netapp Filer. Has anybody tried this yet??? Jason Middlebrooks Systems Engineer Datalink Phone: 888-933-9327x260 2264 Northwest Parkway, Suite I Pager: 888-502-1625 Marietta, GA 30067 Fax: 770-933-9272

1 0

Re: Netapp nfs over tcp
by mds＠gbnet.net 15 Feb '99

15 Feb '99

Oooooooooh. An idea is aborning.... How about allowing filers admins to specify the protocol capability profile that a client is allowed to see on a client-by-client basis in a file not unlike the name-mapping files and exports files and quotas files that we already use... Then we could have NFS-over-TCP turned on for WAN clients but turned off for LAN clients and can experiment with NFS3/2 - all by configuring at the server end (one place) rather than at the client end (many places). Thoughts?

3 2

subscription
by Michael Chong 13 Feb '99

13 Feb '99

Michael M. Chong Web Server Düde The Motley Fool http://www.motleyfool.com

1 0

RE: Can Netapp F700 series do load balancing via NT without using a Virtual IP?
by Sam Schorr 13 Feb '99

13 Feb '99

Keith, We have struggled with this same problem. However, in our case, the "clients" are actually IIS systems in a Virtual IP site. We had tried to have 2 NICs in the IIS NT "clients", one connecting to the shared net that also had the PDC, WINS, DNS and other servers on one subnet, while we had the filer and our SQL server on another sunet. The second subnet I'll call a "backchannel", the idea being to have requests from the IIS "clients" routed to the filer or database through the "backchannel". What we ran into was that even though we put this backchannel on its own switch, and even though we specifically called the filer by the IP address via UNC (ie, \\filerIP\sharename), NT still treats this as a string, not an IP. Thus, NT would try to resolve this through WINS, which it routed through the other subnet!! (the one the WINS server could 'see'). We tried many tricks including using the NOWINS and NOBROADCAST settings on the second NIC in the filer. We still have not been able to get a second subnet going. Can you suggest what we may be missing? Sam -----Original Message----- From: Keith Brown [mailto:keith@netapp.com] Sent: Friday, February 12, 1999 2:53 PM To: Mike Ball; toasters(a)mathworks.com Subject: Re: Can Netapp F700 series do load balancing via NT without using a Virtual IP? >I am assuming [Windows NT] sees the filer as a multihomed server and sees all four IP's >But does it load balance between the 4 ports on the quad card? A commonly asked question. I think I used to have a pointer to a Microsoft document that described this, but apparently that has gone walk-about, so I'm afraid you're stuck with my from-memory verbage below for now... The Windows NT client usually starts out with the filer's name. It uses this name to queery WINS and gets returned a list of IP addresses (assuming the filer is multihomed). It then goes through the list of returned addresses and compares them with the address on its own, usually single interface. First it looks for an address to use that is on the same IP subnet as it finds itself on. If it finds multiple of those, it picks one at random, which will tend to balance the load to a single filer that has multiple interfaces connected to that same subnet as the client. If it doesn't find a match, it will look for an interface in the same IP network as it finds itself on. Again, if it finds multiple of those it will pick one at random, tending to balance the load to the target's interfaces. Finally, if it finds none of the above, it will just pick an address to use at random and go for it. Per our 5.1 releases of Data ONTAP and higher, you also have the ability to control which interfaces the filer will register with WINS. This gives you the ability to stop certain Windows clients from choosing interfaces on the filer which they might not be able to access for various topological and/or routing issues. Keith

1 0

RE: FW: FW: URGENT!!!! FW: NetApp Filer software versions 5.x: po ten tial har dware killer (fwd)
by Madison, Shannon 12 Feb '99

12 Feb '99

"Jason Downs" wrote: > Oh, and by the way: Keep in mind that _I am a customer_. > Attacking me or making snide comments instead of > addressing the issues that I've raised does NOT encourage > me to purchase more Network Appliance products. Please accept my humblest apologies. There was never any intention on the part of myself, Radek, or Network Appliance to insult you or your opinions. -Shannon Madison

1 0

Re: Can Netapp F700 series do load balancing via NT without using a Virtual IP?
by Keith Brown 12 Feb '99

12 Feb '99

>I am assuming [Windows NT] sees the filer as a multihomed server and sees all four IP's >But does it load balance between the 4 ports on the quad card? A commonly asked question. I think I used to have a pointer to a Microsoft document that described this, but apparently that has gone walk-about, so I'm afraid you're stuck with my from-memory verbage below for now... The Windows NT client usually starts out with the filer's name. It uses this name to queery WINS and gets returned a list of IP addresses (assuming the filer is multihomed). It then goes through the list of returned addresses and compares them with the address on its own, usually single interface. First it looks for an address to use that is on the same IP subnet as it finds itself on. If it finds multiple of those, it picks one at random, which will tend to balance the load to a single filer that has multiple interfaces connected to that same subnet as the client. If it doesn't find a match, it will look for an interface in the same IP network as it finds itself on. Again, if it finds multiple of those it will pick one at random, tending to balance the load to the target's interfaces. Finally, if it finds none of the above, it will just pick an address to use at random and go for it. Per our 5.1 releases of Data ONTAP and higher, you also have the ability to control which interfaces the filer will register with WINS. This gives you the ability to stop certain Windows clients from choosing interfaces on the filer which they might not be able to access for various topological and/or routing issues. Keith

1 0

RE: Netapp nfs over tcp
by Thompson, Arnold 12 Feb '99

12 Feb '99

The change is dynamic, but be advised you will need to re-mount the clients to actually use NFS over TCP. > -----Original Message----- > From: Keith Brown [mailto:keith@netapp.com] > Sent: Friday, February 12, 1999 2:20 PM > To: toasters(a)mathworks.com; Gordon Keegan > Subject: Re: Netapp nfs over tcp > > > >Does anyone know if this would affect current > >mounts if we just enable it at the filer command line with > >"options nfs.tcp.enable on", or can that be done? > >Is it a fairly transparent thing or should we schedule > >down time? > > Down time? Heavens no! The words "down" and "time" are > considered very ugly > around these parts when used adjacently. :-) > > I had no reason to believe that this would not be the case, > but just to be on > the safe side I did a little double-check on a filer here for > you, and sure > enough you have nothing to be afraid of. Go ahead and enable > TCP at your > leisure... > > Keith > >

1 0

Re: Netapp nfs over tcp
by Keith Brown 12 Feb '99

12 Feb '99

>Does anyone know if this would affect current >mounts if we just enable it at the filer command line with >"options nfs.tcp.enable on", or can that be done? >Is it a fairly transparent thing or should we schedule >down time? Down time? Heavens no! The words "down" and "time" are considered very ugly around these parts when used adjacently. :-) I had no reason to believe that this would not be the case, but just to be on the safe side I did a little double-check on a filer here for you, and sure enough you have nothing to be afraid of. Go ahead and enable TCP at your leisure... Keith

1 0

Re: Bugtraq item about Netapps.
by sirbruce＠ix.netcom.com 12 Feb '99

12 Feb '99

On 02/11/99 20:22:28 you wrote: > >http://www.geek-girl.com/bugtraq/1999_1/0594.html > >I think that falls into the "Doc, it hurts when I do that" category, but >it's a good reminder anyway. The message, however, is just wrong in many places. I'll quote it below to pick apart. Jason Downs writes: >Filer's typically have an "admin host" which can mount and read/write to the >filer root directory. Without it, it's impossible to do any sort of system >maintenance on the filer. This simply isn't true; there's many sorts of system maintenance that can be done on the console without an admin host, and even moreso now with Web-based administation. One doesn't even have to have a permanent admin host... you could just briefly export the root directory for a quick update, then unexport it from the filer console. >If this host is compromised it's obviously bad news for the filer. But now, >apparently new with the 5.x revisions of the filer operating system, a >malicious individual can likely destroy the disk drive hardware itself. >It is not known if any sort of sanity check is done on the contents of the >firmware files; it's likely there is none, considering the type of code they >contain. This isn't new; a malicious individual could potentially effect firmware in previous versions. This is potentially the case in almost any OS... although I admit, 5.x makes it a little "easier" to do so. Firmware also isn't hardware, although bad firmware could theoretically lead to physical damage of the disk drive hardware mechanism. >Of course, it is trivial to gain command line access to a filer once the >admin host is compromised. They use what amounts to /etc/hosts.equiv for rsh >access. Wrong. People keep thinking the admin host is some mythical authoritative host. It isn't. It's nothing. Forget the term. You *can*, if you like, allow one or more hosts to telnet into the filer, rsh into it without a password, or mount it's root partitions. These are no more or no less a factor in the filer than in any other system, and you are perfectly capable of *not* allowing a host to do any of the above. The filer will continue to work. >It has always been important to make sure the "admin host" of a filer is >secure. This is true. >Now it seems Network Appliance has just raised the stakes; not >only can you lose your data, but you can also potentially lose hundreds >of thousands of dollars worth of hardware. This isn't true, and no one should be doing risk-analysis assuming that a user accessing a system through software can't do damange to the hardware underneath. Jason, I'm CC:ing you on this; you're free to insert it into the bugtraq archive record if you wish since I don't subscribe to it. Bruce

8 8

Can Netapp F700 series do load balancing via NT without using a Virtual IP?
by Mike Ball 12 Feb '99

12 Feb '99

I am trying to find out if you can do load balancing on a filer box w/o using a virtual IP? For example, if I have a quad Ethernet card installed in a F760 with the ports assigned to IP's 10.0.0.1, 10.0.0.2, 10.0.0.3 and 10.0.0.4 how does NT 4.0 deal with accessing the filer? I am assuming it sees the filer as a multihomed server and sees all four IP's. But does it load balance between the 4 ports on the quad card?

1 0

Can Netapp F700 series do load balancing via NT without using a Virtual IP?
by Mike Ball 12 Feb '99

12 Feb '99

1 0

Re: FW: FW: URGENT!!!! FW: NetApp Filer software versions 5.x: poten tial har dware killer (fwd)
by Jason Downs 12 Feb '99

12 Feb '99

In message <7F608EC0BDE6D111B53A00805FA7F7DA02C3834B(a)TAHOE.netapp.com>, "Madison, Shannon" writes: >Forwarded per Radek: > >-----Original Message----- >From: Radek Aster >Sent: Friday, February 12, 1999 11:20 AM >Subject: Re: FW: URGENT!!!! FW: NetApp Filer software versions 5.x: >potential har dware killer (fwd) > > > >IMHO, this is a pile. Jason makes the statement that he can create a file >(of the appropriate size), fill it will garbage, and download it to disk >drives which will then become bricks. > >Geez. How stupid does he think Seagate is? Don't answer that. :-) It's not a question of how stupid I think Seagate is. It's a question of how stupid I think NetApp is for implementing 'online' disk firmware updates. >Seriously, the firmware files have checksums embedded in them. As part of >the update process, the drive will verify the checksum before committing >the firmware to flash. If the checksum doesn't verify, the update is >cancelled. No harm, no foul. Pretty SOP with firmware downloads. Heck, one >could make the same "security" argument with any hardware component with >downloadable firmware. Why pick on drives? All a checksum does is make it more difficult than dd'ing /dev/zero in order to produce something the drive will take. You're missing the point. >Granted, he *could* get his hands on unqualified and/or bad firmware and >download it to the drives .... is this enough to cry "the sky is falling"? > If this is seem as a serious enough "security issue", we can always ship >*encrypted* files, and decrypt them ourselves before downloading, thereby >verifying the contents and identity of files we ship. IMHO, the 'best' way to do it would be to require the files be on a floppy, or some other method which restricts firmware updates to the physical console. Oh, and by the way: Keep in mind that _I am a customer_. Attacking me or making snide comments instead of addressing the issues that I've raised does NOT encourage me to purchase more Network Appliance products. >--Radek > >Jason Downs downsj(a)downsj.com <mailto:downsj@downsj.com> writes: > >Jason> I was going through the documentation for version 5.2.1 >Jason> (the latest) of the Network Appliance Filer operating system when I >Jason> stumbled upon this little gem: "Use the disk_fw_update command to >Jason> update out-of-date firmware on all disks or a specified disk on a >Jason> filer. Each filer is shipped with a /etc/disk_fw directory that >Jason> contains the latest firmware revisions." > >Jason> [...] > >Jason> "In the /etc/disk_fw directory, the firmware file name >is >Jason> in the form of product_ID.revision.LOD. For example, if the firmware >Jason> file is for Seagate disks with product ID ST19171FC and the firmware >Jason> revision is FB37, the file name is ST19171FC.FB37.LOD. The revision >Jason> in the file name is the number against which the filer compares each >Jason> disk's existing firmware revision." > >Jason> [...] > >Jason> "Before Data ONTAP 5.2, the disk_fw_update command copi >ed >Jason> firmware files from the /etc directory. In the /etc directory, the >Jason> name for the firmware file was in the form of product_ID.LOD. The >Jason> revision number was not included in the file name. Data ONTAP 5.2 >Jason> continues to support firmware files in the /etc directory for >Jason> backward compatibility. That is, if you obtain a disk firmware file >Jason> and store it in the /etc directory, you can use the disk_fw_update >Jason> command to copy that firmware file to disks, unless there is also a >Jason> firmware file for the same product ID in the /etc/disk_fw directory. >Jason> The files in the /etc/disk_fw directory take precedence over the >Jason> files in the /etc directory." > >Jason> [...] > > >Jason> Filer's typically have an "admin host" which can mount >and >Jason> read/write to the filer root directory. Without it, it's impossible >Jason> to do any sort of system maintenance on the filer. If this host is >Jason> compromised it's obviously bad news for the filer. But now, >Jason> apparently new with the 5.x revisions of the filer operating system, >Jason> a malicious individual can likely destroy the disk drive hardware >Jason> itself. It is not known if any sort of sanity check is done on the >Jason> contents of the firmware files; it's likely there is none, >Jason> considering the type of code they contain. Of course, it is trivial >Jason> to gain command line access to a filer once the admin host is >Jason> compromised. They use what amounts to /etc/hosts.equiv for rsh >Jason> access. It has always been important to make sure the "admin host" >Jason> of a filer is secure. Now it seems Network Appliance has just >Jason> raised the stakes; not only can you lose your data, but you can also >Jason> potentially lose hundreds of thousands of dollars worth of hardware. > >Jason> -- Jason Downs downsj(a)downsj.com <mailto:downsj@downsj. >com> -- Jason Downs downsj(a)downsj.com Little. Yellow. Secure. http://www.openbsd.org/ Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW.

1 0

FW: FW: URGENT!!!! FW: NetApp Filer software versions 5.x: poten tial har dware killer (fwd)
by Madison, Shannon 12 Feb '99

12 Feb '99

Forwarded per Radek: -----Original Message----- From: Radek Aster Sent: Friday, February 12, 1999 11:20 AM Subject: Re: FW: URGENT!!!! FW: NetApp Filer software versions 5.x: potential har dware killer (fwd) IMHO, this is a pile. Jason makes the statement that he can create a file (of the appropriate size), fill it will garbage, and download it to disk drives which will then become bricks. Geez. How stupid does he think Seagate is? Don't answer that. :-) Seriously, the firmware files have checksums embedded in them. As part of the update process, the drive will verify the checksum before committing the firmware to flash. If the checksum doesn't verify, the update is cancelled. No harm, no foul. Pretty SOP with firmware downloads. Heck, one could make the same "security" argument with any hardware component with downloadable firmware. Why pick on drives? Granted, he *could* get his hands on unqualified and/or bad firmware and download it to the drives .... is this enough to cry "the sky is falling"? If this is seem as a serious enough "security issue", we can always ship *encrypted* files, and decrypt them ourselves before downloading, thereby verifying the contents and identity of files we ship. --Radek Jason Downs downsj(a)downsj.com <mailto:downsj@downsj.com> writes: Jason> I was going through the documentation for version 5.2.1 Jason> (the latest) of the Network Appliance Filer operating system when I Jason> stumbled upon this little gem: "Use the disk_fw_update command to Jason> update out-of-date firmware on all disks or a specified disk on a Jason> filer. Each filer is shipped with a /etc/disk_fw directory that Jason> contains the latest firmware revisions." Jason> [...] Jason> "In the /etc/disk_fw directory, the firmware file name is Jason> in the form of product_ID.revision.LOD. For example, if the firmware Jason> file is for Seagate disks with product ID ST19171FC and the firmware Jason> revision is FB37, the file name is ST19171FC.FB37.LOD. The revision Jason> in the file name is the number against which the filer compares each Jason> disk's existing firmware revision." Jason> [...] Jason> "Before Data ONTAP 5.2, the disk_fw_update command copied Jason> firmware files from the /etc directory. In the /etc directory, the Jason> name for the firmware file was in the form of product_ID.LOD. The Jason> revision number was not included in the file name. Data ONTAP 5.2 Jason> continues to support firmware files in the /etc directory for Jason> backward compatibility. That is, if you obtain a disk firmware file Jason> and store it in the /etc directory, you can use the disk_fw_update Jason> command to copy that firmware file to disks, unless there is also a Jason> firmware file for the same product ID in the /etc/disk_fw directory. Jason> The files in the /etc/disk_fw directory take precedence over the Jason> files in the /etc directory." Jason> [...] Jason> Filer's typically have an "admin host" which can mount and Jason> read/write to the filer root directory. Without it, it's impossible Jason> to do any sort of system maintenance on the filer. If this host is Jason> compromised it's obviously bad news for the filer. But now, Jason> apparently new with the 5.x revisions of the filer operating system, Jason> a malicious individual can likely destroy the disk drive hardware Jason> itself. It is not known if any sort of sanity check is done on the Jason> contents of the firmware files; it's likely there is none, Jason> considering the type of code they contain. Of course, it is trivial Jason> to gain command line access to a filer once the admin host is Jason> compromised. They use what amounts to /etc/hosts.equiv for rsh Jason> access. It has always been important to make sure the "admin host" Jason> of a filer is secure. Now it seems Network Appliance has just Jason> raised the stakes; not only can you lose your data, but you can also Jason> potentially lose hundreds of thousands of dollars worth of hardware. Jason> -- Jason Downs downsj(a)downsj.com <mailto:downsj@downsj.com>

1 0

Re: Bugtraq item about Netapps.
by sirbruce＠ix.netcom.com 12 Feb '99

12 Feb '99

On 02/11/99 23:28:15 you wrote: > >In message <199921122746541(a)ix.netcom.com>, > sirbruce(a)ix.netcom.com writes: >>This simply isn't true; there's many sorts of system maintenance that can >>be done on the console without an admin host, and even moreso now with >>Web-based administation. One doesn't even have to have a permanent admin >>host... you could just briefly export the root directory for a quick update, >>then unexport it from the filer console. > >So you're saying that having a Java runtime on the filer is an improvement >in security? That's insane. It would be insane; that's why I didn't say it. Your claim, which you neatly snipped, was: >Filer's typically have an "admin host" which can mount and read/write to the >filer root directory. Without it, it's impossible to do any sort of system >maintenance on the filer. To wit, my answer - it's not impossible. Whether or not other methods are more or less secure is a matter of debate, but your original point was wrong. >>This isn't new; a malicious individual could potentially effect firmware in >>previous versions. This is potentially the case in almost any OS... although >>I admit, 5.x makes it a little "easier" to do so. Firmware also isn't hardwar >>e, >>although bad firmware could theoretically lead to physical damage of the disk >>drive hardware mechanism. > >It doesn't make it easier. It makes it trivial. This we'll just have to disagree on. We don't really know without statistically sampling over a number of security incidents and seeing exactly what the increased risk is, and even then we'd have to agree on the range of what is called "trivial". If you surveyed a group of informed security consultants on the issue, however, I don't think "trivial" would be the word of choice. >>Wrong. People keep thinking the admin host is some mythical authoritative >>host. It isn't. It's nothing. Forget the term. You *can*, if you like, >>allow one or more hosts to telnet into the filer, rsh into it without a >>password, or mount it's root partitions. These are no more or no less a >>factor in the filer than in any other system, and you are perfectly capable >>of *not* allowing a host to do any of the above. The filer will continue >>to work. > >And you will be unable to update it's /etc/passwd, /etc/quotas, etc. You >must not run a filer in an environment that changes often. Or when you do, you create a temporary security hole that you can monitor in realtime. (Any real security conscious admin are monitoring all of their stuff anyway, but that's another issue). The point is, again, your statement was wrong. Perhaps you were simply *overstating* to make a point... but in the world of security, one should be careful to convey accurate information, not hype. >>>Now it seems Network Appliance has just raised the stakes; not >>>only can you lose your data, but you can also potentially lose hundreds >>>of thousands of dollars worth of hardware. >> >>This isn't true, and no one should be doing risk-analysis assuming that >>a user accessing a system through software can't do damange to the >>hardware underneath. > >It is true. Perhaps you should pull your head out of the sand for a >minute and stop blindly defending the existance a stupid command. By the way, I was only saying the first part of your statement (before the semicolon, that Netapp had raised the stakes) wasn't true; obviously from the context I agreed with the latter, but feel it's largely irrelevant since one should rate virutally the same possibility to previous OS version. You probably still disagree, but I wanted the clarification so we didn't go down a rathole over a misunderstanding. Even if you're correct, you're talking the filer's risk increasing only so much as to be in line with almost every other OS/platform out there that include facilities for such a thing. Hardly something to get worked up over. Bruce

1 0

Re: Netapp nfs over tcp
by Keith Brown 12 Feb '99

12 Feb '99

>> still are some UNIX clients around whose NFS v3 implementations leave something >> to be desired on the stability and performance fronts. > >The question was about TCP, not the version of the NFS protocol. Sorry. That should have read "NFS v3 implementations and/or NFS vX on TCP implementations". >The reason for that choice had nothing to do with stability nor with >any client issues so far as I know, but rather because most customers >see a performance hit when running TCP with enabled, A performance hit which is oft blamed, sometimes deservedly sometimes not, on the quality of the client implementation. Arguably the mount(1M) command on the client side should favor the higher-performing-under-most-circumstances option (UDP), but NetApp doesn't control that so... Keith

2 1

Re: Where can I get a rack???
by charles＠applix.com 11 Feb '99

11 Feb '99

I just wanted to thank everyone for their input; it has been most helpful! Regards, Charles Homan ------------------------------------------------------------------ Charles Homan Applix, Inc. System & Network Operations Manager 112 Turnpike Rd. choman(a)applix.com Westboro, MA 01581 ------------------------------------------------------------------

1 0

Re: Netapp nfs over tcp
by Keith Brown 11 Feb '99

11 Feb '99

>I've currently got my filers with 'options nfs.tcp.enable off' from when I first >set them up due to a perception that this would cause problems. > >Has anyone got tcp enabled? Have they seen any problems/benefits, or are there >any known issues with this? I think the "problem" with switching on nfs.tcp.enable stems from the way that the mount(1M) command works on many modern UNIX systems. If you don't actually specify the version of NFS that you want to use, and the transport protocol you wish it to ride on the mount(1M) command line, the default is often to use the highest version of NFS available (usually 3) over the first connection oriented transport found (usually TCP), that's supported by both the client *and* the server. So, if you're a little "lazy" when it comes to telling the system exactly what you want, you'll end up with NFS v3 on TCP when what you *probably* wanted was UDP and/or NFS v2. Although NFS v3 over TCP or UDP is "fine by us" at the server end of the show (NFS is one of the small number of things a filer does, so you'll find it's done rather well no matter what flavour you pick ;-)), there have been and still are some UNIX clients around whose NFS v3 implementations leave something to be desired on the stability and performance fronts. Hence the default disablement of some of the fancier combinations, to prevent them from being selected by accident. Keith

2 1

Where can I get a rack???
by charles＠applix.com 11 Feb '99

11 Feb '99

OK, I'm not sure this is entirely appropriate for this list, but here goes: I'm getting a new F720, and I just realized I need to get a rack for it. The F330's we have were already here when I joined the company, and the guy who purchased them has since left the company. In looking through his files, I haven't been able to find reference to where he purchased the racks. Does anyone know of a good source for sturdy racks? It looks like they take the standard 19" racks; can anyone confirm or deny that? How much should I expect to spend? Thanks a lot! Charles Homan ------------------------------------------------------------------ Charles Homan Applix, Inc. System & Network Operations Group 112 Turnpike Rd. choman(a)applix.com Westboro, MA 01581 ------------------------------------------------------------------

6 6

Netscape Enterprise Server 3.0 application failover?
by gsmith＠netapp.com 09 Feb '99

09 Feb '99

Hi, Curious as to whether any of our filer(cluster) customers are doing application failover for Netscape Enterprise server 3.0 with the data stored on filer? If so what is the solution you used and would you be willing to share it with another customer. Please respond to me directly and thanks in advance. Regards, Gil

1 0

18 gig drives and Drive shelf
by Jason Middlebrooks 09 Feb '99

09 Feb '99

Is there anything tricky about adding one of the new fibre channel FC-AL 8 shelves that is full of 18 gig drives to a F760 that currently has 2 FC-AL 7 shelves? Thanks for any comments or advice. Jason Middlebrooks Systems Engineer Datalink Phone: 888-933-9327x260 2264 Northwest Parkway, Suite I Pager: 888-502-1625 Marietta, GA 30067 Fax: 770-933-9272

1 0

Jump to page:

2026

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