toasters

toasters@lists.teaparty.net

13531 discussions

RE: TCP v UDP performance
by Peter Bryant 14 Jun '02

14 Jun '02

*** Before acting on this e-mail or opening any attachment you are advised to read the disclaimer at the end of this e-mail *** Thanks for the tip Kevin (and others), as we've a managed solution for the Sun kit I'll pass this on them as knows (and who should have got the damn thing working properly in the first place). Strange that with only a modest amount of filer and Solaris knowledge (but of course access to this list) that I ended up finding the information that got the performance sorted instead of the paid for professionals <g> Thanks toaster world! Peter -----Original Message----- From: kevin graham [mailto:kgraham@dotnetdotcom.org] Sent: 14 June 2002 06:02 To: Peter Bryant Cc: 'toasters(a)mathworks.com' Subject: RE: TCP v UDP performance > Thanks for the tip though. I suspect the drivers are probably OK, > install was only done a couple of months back and up to date versions > used - unless you know a previous driver is better.... <g> For 2.6, do make sure you have 106764-08 installed. Since SUNWged is an unbundled driver, patches for it will _not_ be included in 'Recommended' clusters (one of the reasons I despise them), nor will patchdiag include it (unless its logic has been altered significantly since I last read source). I didn't take the time to read all the bug reports, but there were resolved performance issues with ttcp workloads which will resemble udp to the driver since IIRC that card doesn't do anything like tcp checksum offloading. ..kg.. . o O ( still wondering what was so wrong with the rebranded Alteon ACEnic Sun Gigabit Ethernet 1.0 that they stuck us with this crap. Do yourself a favor and buy a SysKonnect or IntraServer card) > -----Original Message----- > From: Jason S. Cash [mailto:cash@UDel.Edu] > Sent: 12 June 2002 19:02 > To: Peter Bryant > Cc: 'toasters(a)mathworks.com' > Subject: Re: TCP v UDP performance > > > On Tue, 11 Jun 2002, Peter Bryant wrote: > > > Sometime ago I posted some performance tweaks for TCP performance, > > which (when the filer was switched to TCP) worked a treat. I was > > hoping to get the same for UDP. However... > > > > It seems that UDP on Sun over 1GB Ethernet and above is problematic. > > Some details below (words and details have been changed to protect the > > guilty!). As a result we're sticking to TCP for now. > > What version of solaris and what gig-e card? I would look for a new > driver for the gigaswift adaptor that helps immensly w/ UDP NFS perf. > > Jason > > > > > > Peter > > > > ===================================================== > > > > I've done a bit of research and found out that testing of a very > > similar setup to yours, by another customer, showed that there is a > > performance bug in the NFS UDP implementation of Solaris. > > > > We all know that NFS over UDP is about 20% faster than NFS over TCP > > however, the Solaris implementation of UDP breaks this rule when > > gigabit Ethernet is involved..! It seems to be that when NFS is used > > with UDP for internet, 10Mb and 100Mb connectivity then the rule > > applies and also when you have a gigabit Ethernet connection under low > > load then again all is fine. > > > > The performance problem appears when you try to load the gig > > connection heavily - Solaris's UDP simply cannot perform at the > > required rate. Now, thankfully, the TCP implementation in Solaris is > > very good and is up to the job - hence, the situation you find whereby > > NFS over TCP is much better than NFS over UDP. This matches exactly > > with your findings where under normal database usage your Gig + > > NFS/UDP connection is fine - but when you try to backup over the Gig > > Ethernet link the load on the network goes up and UDP can't perform. > > You switched from UDP to TCP and the problem went away. > > > > My recommendation to you is to keep using NFS over TCP - the other > > customer has decided to stay with TCP as it works well and they can't > > see any benefit in moving back to UDP. > > > > > > ******************************* Disclaimer > > ***************************** > > Confidentiality: This e-mail and any attachments are intended for the > > addressee(s) only and may be confidential. If they have come to you in > > error you must take no action based on them, nor must you copy or show > > them to anyone; please reply to this e-mail and highlight the error. > > > > Viruses: Although we have taken steps to ensure that this e-mail > > and > > attachments are free from any virus, we advise that in keeping with > > good practice the recipient should ensure they are actually virus > > free. > > ********************** http://www.burallplastec.com ******************** > > > > /* Jason S. Cash - Systems Programmer > IT/Network and Systems Services > University of Delaware, Newark Delaware > e:cash@udel.edu v: 302-831-0461 */ >

1 0

RE: TCP v UDP performance
by mds＠gbnet.net 14 Jun '02

14 Jun '02

On Thu 13 Jun, 2002, kevin graham <kgraham(a)dotnetdotcom.org> wrote: > > For 2.6, do make sure you have 106764-08 installed. Since SUNWged is an > unbundled driver, patches for it will _not_ be included in 'Recommended' > clusters (one of the reasons I despise them), nor will patchdiag include > it (unless its logic has been altered significantly since I last read > source). Yeah, the patchdiag and patchcheck scripts will believe what they're told in the .xref. However, I always use the '-l' flag which appends a list of patches worth considering based on your other installed packages. If you'd like the output to be in html with links to the patch pages in sunsolve, then take a look at http://www.gbnet.net/~mds/pd.pl . There's an extra switch '-w' which makes it stuff random bits of HTML into the output and I find it saves me hours when assembling bespoke patch lists. For the US sunsolve use '-W'. The output is way faster for the browser to handle than that from patchcheck and in some ways more useful. Needless to say this is a complete hack, is unsupported by everyone, is a mild abuse of Sun copyright and I should probably be hung by the RIAA and the Fatherland Defence Force for even thinking about it. But if it's useful then I hope I earn some forgiveness along the way. >-- End of excerpt from kevin graham -- -Mark ... an Englishman in London ...

1 0

RE: TCP v UDP performance
by Peter Bryant 14 Jun '02

14 Jun '02

*** Before acting on this e-mail or opening any attachment you are advised to read the disclaimer at the end of this e-mail *** Solaris 6, and we used Sun's own PCI Gigabit 2.0 card (as it's described on the invoice) Thanks for the tip though. I suspect the drivers are probably OK, install was only done a couple of months back and up to date versions used - unless you know a previous driver is better.... <g> Peter -----Original Message----- From: Jason S. Cash [mailto:cash@UDel.Edu] Sent: 12 June 2002 19:02 To: Peter Bryant Cc: 'toasters(a)mathworks.com' Subject: Re: TCP v UDP performance On Tue, 11 Jun 2002, Peter Bryant wrote: > Sometime ago I posted some performance tweaks for TCP performance, > which (when the filer was switched to TCP) worked a treat. I was > hoping to get the same for UDP. However... > > It seems that UDP on Sun over 1GB Ethernet and above is problematic. > Some details below (words and details have been changed to protect the > guilty!). As a result we're sticking to TCP for now. What version of solaris and what gig-e card? I would look for a new driver for the gigaswift adaptor that helps immensly w/ UDP NFS perf. Jason > > Peter > > ===================================================== > > I've done a bit of research and found out that testing of a very > similar setup to yours, by another customer, showed that there is a > performance bug in the NFS UDP implementation of Solaris. > > We all know that NFS over UDP is about 20% faster than NFS over TCP > however, the Solaris implementation of UDP breaks this rule when > gigabit Ethernet is involved..! It seems to be that when NFS is used > with UDP for internet, 10Mb and 100Mb connectivity then the rule > applies and also when you have a gigabit Ethernet connection under low > load then again all is fine. > > The performance problem appears when you try to load the gig > connection heavily - Solaris's UDP simply cannot perform at the > required rate. Now, thankfully, the TCP implementation in Solaris is > very good and is up to the job - hence, the situation you find whereby > NFS over TCP is much better than NFS over UDP. This matches exactly > with your findings where under normal database usage your Gig + > NFS/UDP connection is fine - but when you try to backup over the Gig > Ethernet link the load on the network goes up and UDP can't perform. > You switched from UDP to TCP and the problem went away. > > My recommendation to you is to keep using NFS over TCP - the other > customer has decided to stay with TCP as it works well and they can't > see any benefit in moving back to UDP. > > > ******************************* Disclaimer > ***************************** > Confidentiality: This e-mail and any attachments are intended for the > addressee(s) only and may be confidential. If they have come to you in > error you must take no action based on them, nor must you copy or show > them to anyone; please reply to this e-mail and highlight the error. > > Viruses: Although we have taken steps to ensure that this e-mail and > attachments are free from any virus, we advise that in keeping with > good practice the recipient should ensure they are actually virus > free. > ********************** http://www.burallplastec.com ******************** > /* Jason S. Cash - Systems Programmer IT/Network and Systems Services University of Delaware, Newark Delaware e:cash@udel.edu v: 302-831-0461 */

2 1

Native LDAP authentication , when ?
by Frank Bonnet 13 Jun '02

13 Jun '02

Hi Few monthes ago I posted a request to know WHEN Ontap will support LDAP as an authetication method ( instead of NIS/YP ) ? I haven't received any infos from Netapp folks about this subject ... I mean LDAP and certainly NOT M$ Active Directory ! ( openldap prefered ! ) Any infos about this welcome ! Frank Bonnet

1 0

nfs.tcp.enable
by Geoff Hardin 12 Jun '02

12 Jun '02

Based on discussion generated by a post yesterday regarding Sun GbE performance and NetApp filers, I had a question about the nfs.tcp.enable option. I have heard that once you enable this, it is impossible to switch back to UDP; is this true? I don't really have any filers I can test this on, and I'd rather not find out that switching to TCP doesn't fix my problem but I can't go back to UDP. Thanks, Geoff Hardin geoff.hardin(a)dalsemi.com This space is for rent in order to increase company revenue.

2 1

TCP v UDP performance
by Peter Bryant 12 Jun '02

12 Jun '02

*** Before acting on this e-mail or opening any attachment you are advised to read the disclaimer at the end of this e-mail *** Sometime ago I posted some performance tweaks for TCP performance, which (when the filer was switched to TCP) worked a treat. I was hoping to get the same for UDP. However... It seems that UDP on Sun over 1GB Ethernet and above is problematic. Some details below (words and details have been changed to protect the guilty!). As a result we're sticking to TCP for now. Peter ===================================================== I've done a bit of research and found out that testing of a very similar setup to yours, by another customer, showed that there is a performance bug in the NFS UDP implementation of Solaris. We all know that NFS over UDP is about 20% faster than NFS over TCP however, the Solaris implementation of UDP breaks this rule when gigabit Ethernet is involved..! It seems to be that when NFS is used with UDP for internet, 10Mb and 100Mb connectivity then the rule applies and also when you have a gigabit Ethernet connection under low load then again all is fine. The performance problem appears when you try to load the gig connection heavily - Solaris's UDP simply cannot perform at the required rate. Now, thankfully, the TCP implementation in Solaris is very good and is up to the job - hence, the situation you find whereby NFS over TCP is much better than NFS over UDP. This matches exactly with your findings where under normal database usage your Gig + NFS/UDP connection is fine - but when you try to backup over the Gig Ethernet link the load on the network goes up and UDP can't perform. You switched from UDP to TCP and the problem went away. My recommendation to you is to keep using NFS over TCP - the other customer has decided to stay with TCP as it works well and they can't see any benefit in moving back to UDP. ******************************* Disclaimer ***************************** Confidentiality: This e-mail and any attachments are intended for the addressee(s) only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e-mail and highlight the error. Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good practice the recipient should ensure they are actually virus free. ********************** http://www.burallplastec.com ********************

2 1

RE: Cannot delete .snapshot folder
by Maglinger, Paul 10 Jun '02

10 Jun '02

That seems to have done it. Thanks Kevin... -----Original Message----- From: kevin graham [mailto:kgraham@dotnetdotcom.org] Sent: Monday, June 10, 2002 15:52 To: Maglinger, Paul Cc: 'NetApps list server' Subject: Re: Cannot delete .snapshot folder > We have a .snapshot folder on one of our volumes that we cannot delete. We > used to run snapshots on this volume, but turned them off and deleted > snapshots contained within. vol options vol0 nosnapdir on ..kg..

1 0

Cannot delete .snapshot folder
by Maglinger, Paul 10 Jun '02

10 Jun '02

We have a .snapshot folder on one of our volumes that we cannot delete. We used to run snapshots on this volume, but turned them off and deleted snapshots contained within. Whenever we try to delete the folder from NT, we get a message, "Access is denied, the source file may be in use". We tried deleting it from a Unix host and get the same problem. What sparked this is that we have 3 directories that we are trying to mount to on the filer. 2 of them have no problem, but the third one gives us an "Access is denied". The only difference that I can see between the 2 that work and the 1 that doesn't is this .snapshot directory that I can't get rid of. Some insight, please? Remember, you are unique... just like everyone else! Paul Maglinger, A+, CA, CET, MCSE Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com

2 1

Backup Exec and incremental backup
by Uros Lampret 07 Jun '02

07 Jun '02

Hi! Does anybody know if it's possible to make incremental backups of snapshot dir. Every night there's nightly.0 snapshot created. I'd like to back it up to tape. I'd like to make weekly full backup and daily incrementals. But snapshot dir is read only. Is it possible to create incremental bacups in this way? Uros _____________________________

1 0

RE: Using Active Directory to set user home folder fails.
by Pero, Eric P (ETSD, IT) 06 Jun '02

06 Jun '02

I'm experiencing a problem accessing homedirs under Windows XP. I used to (about 3 days ago) access my homedir from the filer (ONTAP 6.1.3R1) using the CIFS OPTIONS HOMEDIR DOMAIN feature...I can access my homedir fine from Windows NT4/2K as \\filer\username, but not with Windows XP anymore. Has anyone experienced this problem? Thanks, Eric Pero _______________________________________ Technical Team Leader ETSD Intel Server Support The Hartford Eric.Pero(a)thehartford.com _______________________________________ -----Original Message----- From: Benny Wiström [mailto:benny.wistrom@proact.se] Sent: Thursday, June 06, 2002 3:39 AM To: 'toasters(a)mathworks.com' Subject: Using Active Directory to set user home folder fails. I have a customer who has upgraded to OnTap 6.2R2 and he has run into bug 42100 which is described as follows: Using Active Directory to set a user profile's home folder to map the user's CIFS home directory on a filer fails. When attempting to set the user home directory to \\filer\%username% AD puts up a MsgBox with the error message: The home folder could not be created because: The network name cannot be found. The reason AD does this is because it tries to verify that the home folder path exists. However, the CIFS home directory for a given user is only visible to that user. With the User Manager tool in NT4, setting the user's home folder path to a filer's CIFS home directory would cause a warning but User Manager did not prevent the operation as Active Directory does. The workaround described below doesn't work under version 6.2R2 of OnTap. It does work under version 6.1.2R1. Well the first workaround would work but that is not an option for my customer. He is about to migrate about 500 users so that would definately be to much work. Use this workaround: a) Create a share on the filer with the user's name. b) Set the user profile's home folder to the filer CIFS home directory. c) Delete the share with the user's name. Or use this 2 step procedure for Ontap 6.0 and above: a) Create the homedir folder of the user which is creating the user profiles. For example, if the filer homedir path is /home and AD is being run by Administrator then "mkdir \\filer\home\Administrator" b) When creating a user profile, instead of setting the home folder to \\filer\%username%, set the home folder path to \\filer\CIFS.HOMEDIR or to \\filer\~ Has anyone else come across this problem? If so, how did you fix it. _________________ Regards Benny This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.

1 0

Using Active Directory to set user home folder fails.
by Benny Wiström 06 Jun '02

06 Jun '02

I have a customer who has upgraded to OnTap 6.2R2 and he has run into bug 42100 which is described as follows: Using Active Directory to set a user profile's home folder to map the user's CIFS home directory on a filer fails. When attempting to set the user home directory to \\filer\%username% AD puts up a MsgBox with the error message: The home folder could not be created because: The network name cannot be found. The reason AD does this is because it tries to verify that the home folder path exists. However, the CIFS home directory for a given user is only visible to that user. With the User Manager tool in NT4, setting the user's home folder path to a filer's CIFS home directory would cause a warning but User Manager did not prevent the operation as Active Directory does. The workaround described below doesn't work under version 6.2R2 of OnTap. It does work under version 6.1.2R1. Well the first workaround would work but that is not an option for my customer. He is about to migrate about 500 users so that would definately be to much work. Use this workaround: a) Create a share on the filer with the user's name. b) Set the user profile's home folder to the filer CIFS home directory. c) Delete the share with the user's name. Or use this 2 step procedure for Ontap 6.0 and above: a) Create the homedir folder of the user which is creating the user profiles. For example, if the filer homedir path is /home and AD is being run by Administrator then "mkdir \\filer\home\Administrator" b) When creating a user profile, instead of setting the home folder to \\filer\%username%, set the home folder path to \\filer\CIFS.HOMEDIR or to \\filer\~ Has anyone else come across this problem? If so, how did you fix it. _________________ Regards Benny

1 0

Anyone have a raw (Unix mailbox) copy of the List Archive?
by David L Kindred (Dave) 05 Jun '02

05 Jun '02

Does anyone have a copy of the List Archive in a raw (preferably Unix mailbox) format? I'd like to have a local copy to facilitate searching by myself and co-workers, and to keep the search burden off our gracious host's desktop. The HTML version is nice for browsing, but harder to manipulate with other tools. Thanks. -- David L. Kindred <mailto:d.kindred@telesciences.com> Unix Systems & Network Administrator Telesciences, Inc. <http://www.telesciences.com> Support: <http://support.telesciences.com> 2000 Midlantic Drive, Suite 410, Mt. Laurel, NJ 08054 Tel: +1.856.866.1000 ext. 4184 Fax: +1.856.866.0185 Cel: +1.609.413.6205 Pgr: +1.800.689.5182 SMS: <mailto:davidlkindred@vtext.com> ---

1 0

ndmpcopy
by Neil Stichbury 03 Jun '02

03 Jun '02

Folks, Would someone be able to forward me a copy of ndmpcopy object for Solaris 2.6 thanks. The make is not working for me and I don't really have time for the learning curve just at the moment to sort the Makefiles. Unless you have modified (all) Makefiles for SUN make ?. Regards, Neil Stichbury PS: will be used on Filer running 6.01.R3

1 0

RE: SNMP Trap Information
by Ben Rockwood 30 May '02

30 May '02

Sadly, I too have to point to the MIB itself. I did want to point out that OnTap does supply a very rich and powerful (and easy) method by which to define custom traps. So if you are looking for a specific trap you might consider simply building your own. Ben Rockwood -----Original Message----- From: Infantino, Vincent (Exchange) [mailto:vinfantino@bear.com] Sent: Thu 5/30/2002 5:15 AM To: 'toasters(a)mathworks.com' Cc: Subject: SNMP Trap Information Would anyone have a complete list of SNMP traps sent by the filers that I can use to decide what is relevant to my environment? I have tried requesting this list from different resources at NetApp, but have only come up with a mib and a data file that need to be cross-referenced. The end result does not produce a trap with a clear description. Any help would be appreciated. Vinny Infantino

1 0

scsi.cmd.checkCondition:error (Sense Data aborted command)
by Chuah, Nicholas 30 May '02

30 May '02

Is the above error critical? There is only one such message in the log while tones of "NDMP#:IO exception: Socket closed" "Top level IOException" error. NOW site has some (Sense Data no error) info but could not find anything on (Sense Data aborted command), what is the best way to rectify this? ONTAP 6.1R1 740. Regards, Nic

1 0

RE: SNMP Trap Information
by Roufay, Charles 30 May '02

30 May '02

The netapp.mib and the traps.dat files are the only ones needed. Of course it takes a while to get used to the definitions. Charles [Roufay, Charles] -----Original Message----- From: Infantino, Vincent (Exchange) [mailto:vinfantino@bear.com] Sent: Thursday, May 30, 2002 2:15 PM To: 'toasters(a)mathworks.com' Subject: SNMP Trap Information Would anyone have a complete list of SNMP traps sent by the filers that I can use to decide what is relevant to my environment? I have tried requesting this list from different resources at NetApp, but have only come up with a mib and a data file that need to be cross-referenced. The end result does not produce a trap with a clear description. Any help would be appreciated. Vinny Infantino

1 0

SNMP Trap Information
by Infantino, Vincent (Exchange) 30 May '02

30 May '02

Would anyone have a complete list of SNMP traps sent by the filers that I can use to decide what is relevant to my environment? I have tried requesting this list from different resources at NetApp, but have only come up with a mib and a data file that need to be cross-referenced. The end result does not produce a trap with a clear description. Any help would be appreciated. Vinny Infantino *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***********************************************************************

1 0

RE: OPLOCKS
by Eisler, Alex 29 May '02

29 May '02

From my experience, don't use oplocks - it tends to do more harm than good. Just do 'options cifs.oplocks.enable off' Alex. -----Original Message----- From: stefan.holzwarth(a)zentrale.adac.de [mailto:stefan.holzwarth@zentrale.adac.de] Sent: Wednesday, May 29, 2002 11:54 To: toasters(a)mathworks.com Subject: OPLOCKS Hi, since we have some small instabilities in our network ;-) it sometimes occures that a oplock isn't released by a NT Workstation. I have then to do manually a cifs terminate for that PC. Is there another way to do that? Shorter timeouts for automatic break by the filer? Why does the filer not recognize the situation - the new cifs session from that rebootet NT workstation (we use 6.1.2 R1) Thanks for input Stefan Holzwarth ---------------------------------------------------------------------------- -- Stefan Holzwarth ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste) Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: (089) 76768924 mailto:stefan.holzwarth@zentrale.adac.de

1 0

OPLOCKS
by stefan.holzwarth＠zentrale.adac.de 29 May '02

29 May '02

Hi, since we have some small instabilities in our network ;-) it sometimes occures that a oplock isn't released by a NT Workstation. I have then to do manually a cifs terminate for that PC. Is there another way to do that? Shorter timeouts for automatic break by the filer? Why does the filer not recognize the situation - the new cifs session from that rebootet NT workstation (we use 6.1.2 R1) Thanks for input Stefan Holzwarth ---------------------------------------------------------------------------- -- Stefan Holzwarth ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste) Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: (089) 76768924 mailto:stefan.holzwarth@zentrale.adac.de

1 0

RE: True 64 UNIX and Filers
by Ben Rockwood 29 May '02

29 May '02

Absolutely NOT. Toaster's are for Network attached storage, NOT local disk. A quorum device is, as you state, a disk which is connected to both nodes, but must be direct attach via SCSI (whether the medium is SCSI or FC doesn't matter). A network device may not (and SHOULD not) be used for quorum. Your quorum device should be the closest, simplest and most robust disk (preferably) avalible. If you review your documentation for your cluster implementation, you'll find that you need to supply it with a SCSI ID, which a Filer would not be. Ben Rockwood -----Original Message----- From: Uros Lampret [mailto:netapp@ourspace.si] Sent: Tue 5/28/2002 11:42 PM To: Ben Rockwood Cc: toasters(a)mathworks.com Subject: Re: True 64 UNIX and Filers I'm asking because in Cluster configuration there must be a Quorum disk wich is accessible by both UNIX servers. So it must be external storage. Usualy someone would suggest SAN, but i'l like to set it up wit Filer. ----- Original Message ----- From: "Ben Rockwood" <BRockwood(a)homestead-inc.com> To: "Uros Lampret" <netapp(a)ourspace.si> Cc: <toasters(a)mathworks.com> Sent: Wednesday, May 29, 2002 7:50 AM Subject: RE: True 64 UNIX and Filers In what regard? Filers will work with any networked device (one assmumes almost any network device knows one of the filers many protocals). What would be any diffrent in a Tru64 Cluster? A better question is more likely: is it a good idea to use a Filer for a Cluster. Can you explain a bit more what you are looking to do? benr. -----Original Message----- From: Uros Lampret [mailto:netapp@ourspace.si] Sent: Tue 5/28/2002 9:46 PM To: 'Toasters (E-mail)' Cc: Subject: True 64 UNIX and Filers Is it possible to use True 64 unix Cluster with NetApp Filers? regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

1 0

RE: True 64 UNIX and Filers
by Ben Rockwood 29 May '02

29 May '02

In what regard? Filers will work with any networked device (one assmumes almost any network device knows one of the filers many protocals). What would be any diffrent in a Tru64 Cluster? A better question is more likely: is it a good idea to use a Filer for a Cluster. Can you explain a bit more what you are looking to do? benr. -----Original Message----- From: Uros Lampret [mailto:netapp@ourspace.si] Sent: Tue 5/28/2002 9:46 PM To: 'Toasters (E-mail)' Cc: Subject: True 64 UNIX and Filers Is it possible to use True 64 unix Cluster with NetApp Filers? regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

2 1

Re: True 64 UNIX and Filers
by SreeHarsha.V.Kannantha 29 May '02

29 May '02

Yes , if it supports NFS version 2 or 3 Regards SreeHarsha ---------- Original Message ---------------------------------- From: "Uros Lampret" <netapp(a)ourspace.si> Date: Wed, 29 May 2002 06:46:24 +0200 Is it possible to use True 64 unix Cluster with NetApp Filers? regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

1 0

True 64 UNIX and Filers
by Uros Lampret 29 May '02

29 May '02

Is it possible to use True 64 unix Cluster with NetApp Filers? regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

1 0

very serious NFS bug
by Igor Schein 28 May '02

28 May '02

Hi, I came across the following bug. NFS writes from Redhat 7.3 client result in filer giving a lot of RPC timeouts for all other clients on the network. Here's a link describing what's known about this bug so far: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65069 With default wsize value of 15K, tcpdump shows a lot of fragmentation packets. While it's obvious that it's RedHat 7.3 bug, I am still wondering why NFS v3 is vulnerable to such sort of DoS attack. On related note, I looked at registry file on the file, and I found these entries: options.nfs.tcp.recvwindowsize=26280 options.nfs.tcp.xfersize=32768 options.nfs.udp.xfersize=32768 Is the 1st one only applicable to NFS over TCP? Is the last one read-only? Thanks Igor

1 0

RE: Accessing a share from DOS.
by Asbjørn Bjørkelund 28 May '02

28 May '02

It's possible to access the filer from a dos 6.22 boot floppy, but i guess your problem is related to the lan manager version on your boot floppy, it should be at least lan manager ver 2.2c, i had the same problem as you are experiencing now i solved it with downloading boot floppies from either www.bootdisk.com or www.nu2.nu/bootdisk/network/ then i got a lan manger version that was working ok with the filer. Best Regards Asbjorn Bjorkelund -----Original Message----- From: Benny Wiström Sent: 27. mai 2002 12:56 To: 'toasters(a)mathworks.com' Subject: Accessing a share from DOS. Is it possible to access a share on a filer from DOS 6.22? When I try this I get the following error message: "the network has responded incorrectly" Is DOS supported at all? /Benny

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