toasters

toasters@lists.teaparty.net

13515 discussions

DFS Replication
by Alan Biren 07 Apr '04

07 Apr '04

I have a DFS environment with one Filer. I am able to set the shares for DFS, but the Filer does not support DFS Replication. Does anyone have a solution that they have working to resolve this. I'd like not to have to replace the existing DFS with VFM/StorageX. ***************************************************************************************************** If you have received this email in error please notify the the system manager or the sender immediately and do not disclosed the to anyone or make copies. ** eSafe scanned this email for viruses, vandals or malicious content ** ** To find out eSafe(TM) and other Aladdin Security Products, contact AMC Corporation at (212) 620-0700 *****************************************************************************************************

1 0

RE: SnapMirror and Qtrees
by Gole, Abhijeet 07 Apr '04

07 Apr '04

-----Original Message----- From: Odhner, Christian Sent: Wednesday, April 07, 2004 11:00 AM To: Gole, Abhijeet; c-dl-snapmirror Subject: RE: SnapMirror and Qtrees > renamed /vol/vol1/MySpace (or My_Space) for snapmirror to work. Before I > change the names of 86 qtrees and their corresponding DFS share > pointers, I'm hoping that someone can tell me that NetApp was incorrect While Colin or someone else can comment on the current state of the bug and any workarounds, I should point out that even if there is no current workaround, the customer does NOT need to change his DFS pointers. Just change the qtree names, and change the CIFS share mappings on the filer side so that the same (old) share names point to the new (no-space) qtree names. Share names and Qtree names don't have to match, so client reconfiguration of any sort can be avoided pretty easily. -Chris -----Original Message----- From: Haber, David J. [mailto:david.haber@fahc.org] Sent: Wednesday, April 07, 2004 10:34 AM To: toasters(a)mathworks.com Subject: SnapMirror and Qtrees I have been told by NetApp support that you cannot, at this time, snapmirror qtrees that have spaces in their name. That is, a qtree with the path /vol/vol1/My Space cannot be snapmirrored. It would have to be renamed /vol/vol1/MySpace (or My_Space) for snapmirror to work. Before I change the names of 86 qtrees and their corresponding DFS share pointers, I'm hoping that someone can tell me that NetApp was incorrect and there is a way to snapmirror qtrees with spaces in their names. Or, can someone at NetApp who might be readin this give me an idea when the bug (86447) will be fixed.

1 0

SnapMirror and Qtrees
by Haber, David J. 07 Apr '04

07 Apr '04

I have been told by NetApp support that you cannot, at this time, snapmirror qtrees that have spaces in their name. That is, a qtree with the path /vol/vol1/My Space cannot be snapmirrored. It would have to be renamed /vol/vol1/MySpace (or My_Space) for snapmirror to work. Before I change the names of 86 qtrees and their corresponding DFS share pointers, I'm hoping that someone can tell me that NetApp was incorrect and there is a way to snapmirror qtrees with spaces in their names. Or, can someone at NetApp who might be readin this give me an idea when the bug (86447) will be fixed.

1 0

RE: CIFS performance Issue
by Tim Driggers 07 Apr '04

07 Apr '04

Hi Jack, I am using the same win2k server to copy to/from the NetApp and to/from another Win2k server. The only difference is which interface is used (the Win2k server has 100mbit and GigE to different vlans). I am actually transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to defragment the Win2k box was valid, as the test server was slightly fragmented. I did a quick analysis after the defrag and this is what I found: Win2k server writing 30GB file over a 100mbit link to a Win2k Server: 12.2MB/sec (link saturated) Win2k server reading 30GB file over a 100mbit link from a Win2k Server: 12.13MB/sec (link saturated) Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec note: these are the best readings after playing with several Win2k gigE settings (including your suggestion of TCP offload). I guess my question is, should I expect better performance from the NetApp? -----Original Message----- From: Jack Lyons [mailto:jack.lyons@martinagency.com] Sent: Friday, April 02, 2004 9:43 AM To: 'Tim Driggers'; 'NetApp List (E-mail)' Subject: RE: CIFS performance Issue There are a lot of variables involved. What client are you using for copying the file to and from the NetApp. Are you using the Win2k server you are comparing it to? I think some of what is going is that the Win2k maybe caching the writes to the file, but when writing to the Filer it is not caching the reads (or if it is - it isn't doing it efficiently). I bet if you looked at the defrag map of the Win2k box it would be moderately fragmented. Also, for a Gig link, a 30 MB file is not that big. Try using a 300 MB file. We looked at several different solutions using different protocols and CIFS clients. Here is a snapshot of my results. Single Client WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s MacOSX running the Dave Client writing a 300MB file over a GigE link to a FAS960: 22MB/s MacOSX running the Dave Client reading a 300MB file over a GigE link from a FAS960: 38MB/s However with 5 clients connected to a gig switch to a single GigE connected server WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s MacOSX running the Dave Client writing a 300MB file over a GigE link to a FAS960: 18MB/s MacOSX running the Dave Client reading a 300MB file over a GigE link from a FAS960: 23MB/s My analysis is the Wintel box cannot handle the load at GigE speeds. I haven't had a chance to try using a TCP Offload Engine NIC which would probably help. -----Original Message----- From: Tim Driggers [mailto:timd@birthdayexpress.com] Sent: Friday, April 02, 2004 11:59 AM To: NetApp List (E-mail) Subject: CIFS performance Issue Hi All, I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I am having a problem understanding a CIFS transfer rate difference I am seeing between writing to and from the NetApp. First, a little background: The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at this time. The NetApp has full flow control configured. I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to and from the NetApp over NFSv3 at between 92-96mbit consistently, with the FreeBSD using an NFS mount having a 100mbit link. I am able to copy the same 30GB file from the NetApp to a Windows 2000 server using CIFS at 130-160mbit consistently. The Win2k server has a gigabit SX card. When copying the file to the NetApp from the Win2k server, I am seeing a maximum throughput of 69mbit, and usually it settles around 33-40mbit. I am monitoring this transfer rate using 'sh port utillization' on the BlackDiamond. I have tested this on three different Win2k boxes, with nearly identical results. I have also followed instructions on NetApp's website on how to 'improve' performance through registry edits, with no apparent result (positive or negative). I have tried three different flowcontrol settings on the Win2k cards (send, recieve and full) - again with no change in performance. I'm thrilled with the NFS performance, but we are a windows shop. I need to get performance increased on the CIFS writes to the NetApp if it's possible. I have tried every tweak I could find, and nothing seems to change the rate at which I can write to the NetApp via CIFS. I have included some NetApp information: slot 8: Gigabit Ethernet Controller II e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up) slot 9: NVRAM Memory Size: 32 MB netapp1> options cifs cifs.audit.autosave.file.extension cifs.audit.autosave.file.limit 0 cifs.audit.autosave.onsize.enable off cifs.audit.autosave.onsize.threshold 500k cifs.audit.autosave.ontime.enable off cifs.audit.autosave.ontime.interval cifs.audit.enable off cifs.audit.file_access_events.enable on cifs.audit.logon_events.enable on cifs.audit.logsize 524288 cifs.audit.saveas /etc/log/adtlog.evt cifs.bypass_traverse_checking on cifs.comment cifs.guest_account cifs.home_dir cifs.home_dir_namestyle ntname cifs.home_dirs_public_for_admin on cifs.idle_timeout 1800 cifs.max_mpx 50 cifs.netbios_aliases cifs.netbios_over_tcp.enable on cifs.nfs_root_ignore_acl on cifs.oplocks.enable off cifs.oplocks.opendelta 8 cifs.per_client_stats.enable off cifs.perm_check_ro_del_ok on cifs.perm_check_use_gid on cifs.restrict_anonymous.enable off cifs.save_case on cifs.scopeid cifs.search_domains cifs.show_snapshot off cifs.shutdown_msg_level 2 cifs.sidcache.enable on cifs.sidcache.lifetime 1440 cifs.snapshot_file_folding.enable off cifs.symlinks.cycleguard on cifs.symlinks.enable on cifs.tcp_window_size 64240 cifs.trace_dc_connection off cifs.trace_login off cifs.wins_servers <edited> netapp1> options ip ip.fastpath.enable on ip.ipsec.enable off ip.match_any_ifaddr on ip.path_mtu_discovery.enable on ip.ping_throttle.alarm_interval 0 ip.ping_throttle.drop_level 10 ip.tcp.newreno.enable on ip.tcp.sack.enable off If anyone can help, I would really appreciate it. If I need to supply more information, please just ask. Thanks, Tim This email and its contents may be confidential. If it is and you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately. Thank you.

3 2

mcafee virus scanner license
by Jeff Burton 07 Apr '04

07 Apr '04

I am looking at moving many Windows home directories and department shares over to the NetApp from Windows file clusters and everything is going smooth except the cost for virus scanning. McAfee wanted to charge us per user account at our company, since they could all technically access the server. Since we have about 70K people and probably >80K accounts, that is quite expensive even with the 2 digit cost per client. They have now agreed to charge us per user account that is actually accessing the NetApp, which is still outrageously expensive even with 10K users. Is this how all virus scanning software is licensed (per user) for the NetApp? It's going to be hard to sell a >100K cost to scan a NetApp when the Windows file servers cost, what, $5/per no matter how many users. Thanks, Jeff _________________________________________________________________ Frustrated with dial-up? Lightning-fast Internet access for as low as $29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/

2 1

Snapvault for open systams
by Mats.Oberg＠tietoenator.com 06 Apr '04

06 Apr '04

Hi, has anybody tried the open systems snapvault agent? And if you have, what kind of speed did you see from different machines? ---- Mats

1 0

RE: AntiVirus Solutions
by Hill, Aaron 06 Apr '04

06 Apr '04

Oops, too many zeroes. 10,000+ users that is. Too much caffeine! -----Original Message----- From: Hill, Aaron Sent: Tuesday, 6 April 2004 10:08 AM To: 'Jack Lyons'; 'toasters(a)mathworks.com' Subject: RE: AntiVirus Solutions We use TrendMicro. To put it simply, it works. Multiple Filers, multiple sites, clustered and not. (960s,825s,R150s). Maybe 10,0000+ users. Something I didn't like was the fact that coverage was stopped when updates were pushed out. There were ways around this (staggered manual deployment, multiple Information servers on different schedules), but all were less than perfect. We recently installed version 5.61 and this has fixed that problem completely. 5.61 is great, definitely rollout with that version or higher. It includes read-only accounts for web console access if you need separate security team reporting and has a whole bunch of other useful reporting tools. Another thing it fixed was only one connection allowed to the Information Server at a time. The web interface allows as many authenticated sessions as you need. The ability to register multiple filers with a single AV box is great for protection against server/service failure and may help you cut down on virus server costs. In your case, if the servers are dedicated to AV, then two single CPU Xeon/Athlon servers with 1Gig of RAM should do the trick. Small, mirrored hard drives only (<18G) is plenty. 100Mb connections to the filer will do fine, but Gbe would be better. Layered security is always best. So I would recommend a different AV product running on the desktops and maybe another running on Exchange mail. -----Original Message----- From: Jack Lyons [mailto:jack.lyons@martinagency.com] Sent: Friday, 2 April 2004 11:41 PM To: 'toasters(a)mathworks.com' Subject: AntiVirus Solutions We are looking for a virus scanning solution for our FAS960 with 350 users accessing via CIFS. Trend Micro is a little cheaper than McAfee but we are a McAfee shop. But I have also heard that Trend Micro is better for NetApp but I can't find any specifics? Can anyone share their experience with either product? Thanks Jack This email and its contents may be confidential. If it is and you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately. Thank you. ************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. **************************************************

1 0

RE: AntiVirus Solutions
by Hill, Aaron 06 Apr '04

06 Apr '04

We use TrendMicro. To put it simply, it works. Multiple Filers, multiple sites, clustered and not. (960s,825s,R150s). Maybe 10,0000+ users. Something I didn't like was the fact that coverage was stopped when updates were pushed out. There were ways around this (staggered manual deployment, multiple Information servers on different schedules), but all were less than perfect. We recently installed version 5.61 and this has fixed that problem completely. 5.61 is great, definitely rollout with that version or higher. It includes read-only accounts for web console access if you need separate security team reporting and has a whole bunch of other useful reporting tools. Another thing it fixed was only one connection allowed to the Information Server at a time. The web interface allows as many authenticated sessions as you need. The ability to register multiple filers with a single AV box is great for protection against server/service failure and may help you cut down on virus server costs. In your case, if the servers are dedicated to AV, then two single CPU Xeon/Athlon servers with 1Gig of RAM should do the trick. Small, mirrored hard drives only (<18G) is plenty. 100Mb connections to the filer will do fine, but Gbe would be better. Layered security is always best. So I would recommend a different AV product running on the desktops and maybe another running on Exchange mail. -----Original Message----- From: Jack Lyons [mailto:jack.lyons@martinagency.com] Sent: Friday, 2 April 2004 11:41 PM To: 'toasters(a)mathworks.com' Subject: AntiVirus Solutions We are looking for a virus scanning solution for our FAS960 with 350 users accessing via CIFS. Trend Micro is a little cheaper than McAfee but we are a McAfee shop. But I have also heard that Trend Micro is better for NetApp but I can't find any specifics? Can anyone share their experience with either product? Thanks Jack This email and its contents may be confidential. If it is and you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately. Thank you. ************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. **************************************************

1 0

RE: CIFS performance Issue
by Tim Driggers 05 Apr '04

05 Apr '04

I've been copying using Explorer. I have always wondered if there was a performance issue when copying using Explorer, but wasnt able to find the right KB's about it. Thanks! -----Original Message----- From: lallin(a)millermartin.com [mailto:lallin@millermartin.com] Sent: Monday, April 05, 2004 7:24 AM To: timd(a)birthdayexpress.com; 'NetApp List (E-mail)' Subject: RE: CIFS performance Issue Hey Tim, I hate to throw another variable in the works, but how are you doing the copies? Command line? Windows Explorer? It makes a difference in Windows. See MS KB223140. As far as I know, this still holds true for Win2k and WinXP. See KB270926. Hope this helps in your troubleshooting. Jack Lyons <jack.lyons(a)martinagency.com> on 04/05/2004 09:16:55 AM To: "'Tim Driggers'" <timd(a)birthdayexpress.com>, Jack Lyons <jack.lyons(a)martinagency.com>, "'NetApp List (E-mail)'" <toasters(a)mathworks.com> cc: (bcc: Luther Allin/M&M) Subject: RE: CIFS performance Issue Not sure what version of Data OnTap you are running but have you tried running netdiag to show any lower layer errors. Also, try running sysstat -s 1 to show "real-time" performance stats. We evaluated a FAS880 initially and I think the CIFS protocol is more CPU intensive than NFS and when the CPU >99% we started dropping a lot of packets and saw crappy numbers. -----Original Message----- From: Tim Driggers [mailto:timd@birthdayexpress.com] Sent: Sunday, April 04, 2004 8:58 PM To: 'Jack Lyons'; Tim Driggers; 'NetApp List (E-mail)' Subject: RE: CIFS performance Issue Hi Jack, I am using the same win2k server to copy to/from the NetApp and to/from another Win2k server. The only difference is which interface is used (the Win2k server has 100mbit and GigE to different vlans). I am actually transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to defragment the Win2k box was valid, as the test server was slightly fragmented. I did a quick analysis after the defrag and this is what I found: Win2k server writing 30GB file over a 100mbit link to a Win2k Server: 12.2MB/sec (link saturated) Win2k server reading 30GB file over a 100mbit link from a Win2k Server: 12.13MB/sec (link saturated) Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec note: these are the best readings after playing with several Win2k gigE settings (including your suggestion of TCP offload). I guess my question is, should I expect better performance from the NetApp? -----Original Message----- From: Jack Lyons [mailto:jack.lyons@martinagency.com] Sent: Friday, April 02, 2004 9:43 AM To: 'Tim Driggers'; 'NetApp List (E-mail)' Subject: RE: CIFS performance Issue There are a lot of variables involved. What client are you using for copying the file to and from the NetApp. Are you using the Win2k server you are comparing it to? I think some of what is going is that the Win2k maybe caching the writes to the file, but when writing to the Filer it is not caching the reads (or if it is - it isn't doing it efficiently). I bet if you looked at the defrag map of the Win2k box it would be moderately fragmented. Also, for a Gig link, a 30 MB file is not that big. Try using a 300 MB file. We looked at several different solutions using different protocols and CIFS clients. Here is a snapshot of my results. Single Client WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s MacOSX running the Dave Client writing a 300MB file over a GigE link to a FAS960: 22MB/s MacOSX running the Dave Client reading a 300MB file over a GigE link from a FAS960: 38MB/s However with 5 clients connected to a gig switch to a single GigE connected server WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s MacOSX running the Dave Client writing a 300MB file over a GigE link to a FAS960: 18MB/s MacOSX running the Dave Client reading a 300MB file over a GigE link from a FAS960: 23MB/s My analysis is the Wintel box cannot handle the load at GigE speeds. I haven't had a chance to try using a TCP Offload Engine NIC which would probably help. -----Original Message----- From: Tim Driggers [mailto:timd@birthdayexpress.com] Sent: Friday, April 02, 2004 11:59 AM To: NetApp List (E-mail) Subject: CIFS performance Issue Hi All, I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I am having a problem understanding a CIFS transfer rate difference I am seeing between writing to and from the NetApp. First, a little background: The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at this time. The NetApp has full flow control configured. I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to and from the NetApp over NFSv3 at between 92-96mbit consistently, with the FreeBSD using an NFS mount having a 100mbit link. I am able to copy the same 30GB file from the NetApp to a Windows 2000 server using CIFS at 130-160mbit consistently. The Win2k server has a gigabit SX card. When copying the file to the NetApp from the Win2k server, I am seeing a maximum throughput of 69mbit, and usually it settles around 33-40mbit. I am monitoring this transfer rate using 'sh port utillization' on the BlackDiamond. I have tested this on three different Win2k boxes, with nearly identical results. I have also followed instructions on NetApp's website on how to 'improve' performance through registry edits, with no apparent result (positive or negative). I have tried three different flowcontrol settings on the Win2k cards (send, recieve and full) - again with no change in performance. I'm thrilled with the NFS performance, but we are a windows shop. I need to get performance increased on the CIFS writes to the NetApp if it's possible. I have tried every tweak I could find, and nothing seems to change the rate at which I can write to the NetApp via CIFS. I have included some NetApp information: slot 8: Gigabit Ethernet Controller II e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up) slot 9: NVRAM Memory Size: 32 MB netapp1> options cifs cifs.audit.autosave.file.extension cifs.audit.autosave.file.limit 0 cifs.audit.autosave.onsize.enable off cifs.audit.autosave.onsize.threshold 500k cifs.audit.autosave.ontime.enable off cifs.audit.autosave.ontime.interval cifs.audit.enable off cifs.audit.file_access_events.enable on cifs.audit.logon_events.enable on cifs.audit.logsize 524288 cifs.audit.saveas /etc/log/adtlog.evt cifs.bypass_traverse_checking on cifs.comment cifs.guest_account cifs.home_dir cifs.home_dir_namestyle ntname cifs.home_dirs_public_for_admin on cifs.idle_timeout 1800 cifs.max_mpx 50 cifs.netbios_aliases cifs.netbios_over_tcp.enable on cifs.nfs_root_ignore_acl on cifs.oplocks.enable off cifs.oplocks.opendelta 8 cifs.per_client_stats.enable off cifs.perm_check_ro_del_ok on cifs.perm_check_use_gid on cifs.restrict_anonymous.enable off cifs.save_case on cifs.scopeid cifs.search_domains cifs.show_snapshot off cifs.shutdown_msg_level 2 cifs.sidcache.enable on cifs.sidcache.lifetime 1440 cifs.snapshot_file_folding.enable off cifs.symlinks.cycleguard on cifs.symlinks.enable on cifs.tcp_window_size 64240 cifs.trace_dc_connection off cifs.trace_login off cifs.wins_servers <edited> netapp1> options ip ip.fastpath.enable on ip.ipsec.enable off ip.match_any_ifaddr on ip.path_mtu_discovery.enable on ip.ping_throttle.alarm_interval 0 ip.ping_throttle.drop_level 10 ip.tcp.newreno.enable on ip.tcp.sack.enable off If anyone can help, I would really appreciate it. If I need to supply more information, please just ask. Thanks, Tim This email and its contents may be confidential. If it is and you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately. Thank you. This email and its contents may be confidential. If it is and you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately. Thank you.

1 0

RE: CIFS performance Issue
by Tim Driggers 05 Apr '04

05 Apr '04

Yes, it uses the default (8). -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Monday, April 05, 2004 2:46 AM Cc: 'NetApp List (E-mail)' Subject: Re: CIFS performance Issue the volume onto / from which you read / write is composed of at least 6 disks, right ? Tim Driggers wrote: >Hi Jack, > > >I am using the same win2k server to copy to/from the NetApp and to/from >another Win2k server. The only difference is which interface is used (the >Win2k server has 100mbit and GigE to different vlans). I am actually >transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to >defragment the Win2k box was valid, as the test server was slightly >fragmented. I did a quick analysis after the defrag and this is what I >found: > >Win2k server writing 30GB file over a 100mbit link to a Win2k Server: >12.2MB/sec (link saturated) >Win2k server reading 30GB file over a 100mbit link from a Win2k Server: >12.13MB/sec (link saturated) >Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec >Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec > >note: these are the best readings after playing with several Win2k gigE >settings (including your suggestion of TCP offload). I guess my question >is, should I expect better performance from the NetApp? > >-----Original Message----- >From: Jack Lyons [mailto:jack.lyons@martinagency.com] >Sent: Friday, April 02, 2004 9:43 AM >To: 'Tim Driggers'; 'NetApp List (E-mail)' >Subject: RE: CIFS performance Issue > > >There are a lot of variables involved. > >What client are you using for copying the file to and from the NetApp. Are >you using the Win2k server you are comparing it to? > >I think some of what is going is that the Win2k maybe caching the writes to >the file, but when writing to the Filer it is not caching the reads (or if >it is - it isn't doing it efficiently). > >I bet if you looked at the defrag map of the Win2k box it would be >moderately fragmented. > >Also, for a Gig link, a 30 MB file is not that big. Try using a 300 MB >file. > >We looked at several different solutions using different protocols and CIFS >clients. Here is a snapshot of my results. > >Single Client >WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s >WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s >MacOSX running the Dave Client writing a 300MB file over a GigE link to a >FAS960: 22MB/s >MacOSX running the Dave Client reading a 300MB file over a GigE link from a >FAS960: 38MB/s > >However with 5 clients connected to a gig switch to a single GigE connected >server >WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s >WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s >MacOSX running the Dave Client writing a 300MB file over a GigE link to a >FAS960: 18MB/s >MacOSX running the Dave Client reading a 300MB file over a GigE link from a >FAS960: 23MB/s > >My analysis is the Wintel box cannot handle the load at GigE speeds. >I haven't had a chance to try using a TCP Offload Engine NIC which would >probably help. > > > > >-----Original Message----- >From: Tim Driggers [mailto:timd@birthdayexpress.com] >Sent: Friday, April 02, 2004 11:59 AM >To: NetApp List (E-mail) >Subject: CIFS performance Issue > >Hi All, > >I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I >am having a problem understanding a CIFS transfer rate difference I am >seeing between writing to and from the NetApp. > >First, a little background: > >The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme >BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at >this time. The NetApp has full flow control configured. > >I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to >and from the NetApp over NFSv3 at between 92-96mbit consistently, with the >FreeBSD using an NFS mount having a 100mbit link. > >I am able to copy the same 30GB file from the NetApp to a Windows 2000 >server using CIFS at 130-160mbit consistently. The Win2k server has a >gigabit SX card. When copying the file to the NetApp from the Win2k server, >I am seeing a maximum throughput of 69mbit, and usually it settles around >33-40mbit. I am monitoring this transfer rate using 'sh port utillization' >on the BlackDiamond. I have tested this on three different Win2k boxes, with >nearly identical results. I have also followed instructions on NetApp's >website on how to 'improve' performance through registry edits, with no >apparent result (positive or negative). I have tried three different >flowcontrol settings on the Win2k cards (send, recieve and full) - again >with no change in performance. > >I'm thrilled with the NFS performance, but we are a windows shop. I need to >get performance increased on the CIFS writes to the NetApp if it's possible. > >I have tried every tweak I could find, and nothing seems to change the rate >at which I can write to the NetApp via CIFS. I have included some NetApp >information: > > > slot 8: Gigabit Ethernet Controller II > e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up) > slot 9: NVRAM > Memory Size: 32 MB > >netapp1> options cifs >cifs.audit.autosave.file.extension >cifs.audit.autosave.file.limit 0 >cifs.audit.autosave.onsize.enable off >cifs.audit.autosave.onsize.threshold 500k >cifs.audit.autosave.ontime.enable off >cifs.audit.autosave.ontime.interval >cifs.audit.enable off >cifs.audit.file_access_events.enable on >cifs.audit.logon_events.enable on >cifs.audit.logsize 524288 >cifs.audit.saveas /etc/log/adtlog.evt >cifs.bypass_traverse_checking on >cifs.comment >cifs.guest_account >cifs.home_dir >cifs.home_dir_namestyle ntname >cifs.home_dirs_public_for_admin on >cifs.idle_timeout 1800 >cifs.max_mpx 50 >cifs.netbios_aliases >cifs.netbios_over_tcp.enable on >cifs.nfs_root_ignore_acl on >cifs.oplocks.enable off >cifs.oplocks.opendelta 8 >cifs.per_client_stats.enable off >cifs.perm_check_ro_del_ok on >cifs.perm_check_use_gid on >cifs.restrict_anonymous.enable off >cifs.save_case on >cifs.scopeid >cifs.search_domains >cifs.show_snapshot off >cifs.shutdown_msg_level 2 >cifs.sidcache.enable on >cifs.sidcache.lifetime 1440 >cifs.snapshot_file_folding.enable off >cifs.symlinks.cycleguard on >cifs.symlinks.enable on >cifs.tcp_window_size 64240 >cifs.trace_dc_connection off >cifs.trace_login off >cifs.wins_servers <edited> > >netapp1> options ip >ip.fastpath.enable on >ip.ipsec.enable off >ip.match_any_ifaddr on >ip.path_mtu_discovery.enable on >ip.ping_throttle.alarm_interval 0 >ip.ping_throttle.drop_level 10 >ip.tcp.newreno.enable on >ip.tcp.sack.enable off > > >If anyone can help, I would really appreciate it. If I need to supply more >information, please just ask. > > >Thanks, > > >Tim > > >This email and its contents may be confidential. If it is and you are not >the intended recipient, please do not disclose or use the information within >this email or its attachments. If you have received this email in error, >please delete it immediately. Thank you. > > > >

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