toasters

toasters@lists.teaparty.net

13531 discussions

Filer Shelfs used on non-NetApp Hardware
by Steve Evans 16 Apr '04

16 Apr '04

I have a couple FC8 shelfs that are no longer being used on Filers. Can I reuse them on non-NetApp hardware? Steve Evans SDSU Foundation

1 0

Re: NetApp DR Tape Solutions
by Andrew Siegel 16 Apr '04

16 Apr '04

We have a clustered F880 with about 8.5TB of usable data on it, split among a dozen volumes. FWIW, we back this up onto three LTO2 drives in about 60 hours (i.e. we start it at 7pm Friday and it runs until Monday morning). This occupies about 24 tapes. We originally wanted the 9940B, but it was too expensive, and I have to say that I am very happy with the LTO2. I have not had a single media failure among the nearly 500 tapes that we've used. They are very fast and very reliable. -- Andrew Siegel Head of Systems Blue Sky Studios, Inc. 44 South Broadway, 17th floor White Plains, NY 10601 914-259-6336 direct 914-259-6500 main 914-259-6499 fax abs(a)blueskystudios.com

1 0

RE: NetApp DR Tape Solutions
by Melvin, Grant 16 Apr '04

16 Apr '04

Hi Ben, > Tape, to me, seems the more prudent solution, because > it allows for offsite of the data (in case of fire, > WW3, etc) and we can maintain multiple independent > copies of the data to guard against logical corruption > of the data, if it occured. If logical corruption > occurs we need to catch the problem before the snap > to the NearStore happens or we're screwed, right? Have you considered SnapVault? http://www.netapp.com/products/filer/snapvault.html It's a sibling to SnapMirror and provides online backups normally resident on the NearStore. You could SnapVault from either filer (production filer or SnapMirror destination). It allows you to have onsite or offsite backup versions online in a read- able (non-proprietry) format so single file restores can be performed quickly and easily either by mounting the NearStore via NFS and/ or CIFS. Or by using one of many SnapVault compliant (its controlled by a NDMP V4 extension) applications that are on the market today. Not that I want to put you off tape, but we're seeing a strong movement towards disk-based backup and using tape for archival. SnapVault allows you to setup a retention policy on your backups just like you'd do within you tape library and the best bit is that after you do a baseline or level 0 backup you only need to perform incrementals forever after that. And these can be run every hour, only send changed data blocks over the network and therefore only save changed blocks per backup on the NearStore. Since each backup version is a NetApp Snapshot and you can have 250 Snapshots per volume, every backup is a full so no more incrementals to tape and no more incremental restores are required. Customers who've deployed SnapVault have often upgraded their tape drive & tape library to the latest tape drive technology such as the drives you suggest LTO-2, 9940B and S-AIT, but along with SnapVault they have been able to make a smaller investment in their tape infrastructure and tape media. I for one am not scared of S-AIT, but my previous position was at Ampex and we invented helical scan! SnapVault in the form of an Open Systems SnapVault agent (that is also controlled via the same NDMP V4 extension) also allows the NearStore to be a online backup for Windows (NT, W2K & 2003), Solaris, AIX, HP-UX, Linux and SGI IRIX. Sorry if this comes over too much of a plug, but I'd rather have you examine your other options to tape as backup. SnapVault (just like tape) would allow you to maintain multiple independent copies of the data to guard against logical corruption of the data, if it occurred. Cheers, Grant For information on NetApp's Data Protection Solutions view http://www.netapp.com/solutions/data_protection.html. =========== grant(a)netapp.com ========== Grant Melvin === === Data Protection Specialist === === Network Appliance === |\ | __ ___ /\ __ __ === 475 East Java Drive === | \ | |__ | /__\ |__| |__| === Sunnyvale === | \| |__ | / \| | (R) === California === === 94089, USA === Network Appliance === Tel:(408)822-6761 ====== The evolution of storage.(tm) ===== Fax:(408)822-4611 -----Original Message----- From: Ben Rockwood [mailto:BRockwood@homestead-inc.com] Sent: Thursday, April 15, 2004 2:53 PM To: toasters(a)mathworks.com Subject: NetApp DR Tape Solutions Hello Toasters. I've got 2 940 Filers with 5TB of capacity each currently, with the expectation that it will grow significantly over time. We're using snapmirror from one filer to the other in order to provide redunancy and this also servers as our "backup". I think it's time to move to a more substantial solution, namely for DR purposes. The options, due to budget, are NearStore or tape. Obviously the best solution would be to snapmirror to a NearStore and then to do tape backups from the spinning copy, but we can't afford that sort of solution right now. Tape, to me, seems the more prudent solution, because it allows for offsite of the data (in case of fire, WW3, etc) and we can maintain multiple independant copies of the data to guard against logical corruption of the data, if it occured. If logical corruption occurs we need to catch the problem before the snap to the NearStore happens or we're screwed, right? So tape has the advantage given our constraints. So the question becomes which media to use. 9940B is out immediately due to cost ($40K/drive is insane). Which leaves LTO Gen2 at 200G native and S-AIT at 500G Native. Naturally I'm liking the S-AIT option because I can do offsites with a signficantly lower media count, despite the fact that the media cost is higher. And, because my data is primarily web content (HTML flattext and GIF/JPG images) I should be a pretty decent compression ratio. This brings me to the big question. Has anyone managing Filers used S-AIT yet? It's really an argument between Helical Scan tape technology (wear rate, failures, etc) vs the stable and proven Linear technology of LTO Gen2. Despite the drawbacks associated with all the problems inhearent to Helical Scan, the 500G native, and possible 2.66:1 (I expect that with my data 2:1 is adiquate) compression ration the advantages to S-AIT for Filer backup is really hard to ignore. My estimates right now in the pro-con area between the 2 formats looks like this: Total Capacity of each Filer as currently configured: 5.2TB Media Consumption per Filer: LTO Gen2: Backup of Full Capacity without Compression: 26 Tapes (approx) S-AIT: Backup of Full Capacity without Compression: 10 Tapes (approx) So assuming I get around 2:1 compression which is reasonable, I can do full capacity backups in 5 tapes per filer with S-AIT vs 13 with LTO! That means if I want to keep 4 complete backups at any given time, I need a library with an insane media count, because we're looking at 26x4x2=208 slots, and bring that down to 130 or so with compression. With S-AIT I need less than 50 not considering compression. And to that, with compression I might be able to cram all 5TB onto 4 tapes, which means I can buy a 4 drive library and stream to all 4 tapes similatiously without a media change in the middle. Anyway, obviously I'm feeling scared about S-AIT but cannot ignore the awsome potential it has for bulk data. Can anyone please share their insights or opinions? Is anyone currently using S-AIT for filers? Thanx. benr.

1 0

NetApp DR Tape Solutions
by Ben Rockwood 15 Apr '04

15 Apr '04

Hello Toasters. I've got 2 940 Filers with 5TB of capacity each currently, with the expectation that it will grow significantly over time. We're using snapmirror from one filer to the other in order to provide redunancy and this also servers as our "backup". I think it's time to move to a more substantial solution, namely for DR purposes. The options, due to budget, are NearStore or tape. Obviously the best solution would be to snapmirror to a NearStore and then to do tape backups from the spinning copy, but we can't afford that sort of solution right now. Tape, to me, seems the more prudent solution, because it allows for offsite of the data (in case of fire, WW3, etc) and we can maintain multiple independant copies of the data to guard against logical corruption of the data, if it occured. If logical corruption occurs we need to catch the problem before the snap to the NearStore happens or we're screwed, right? So tape has the advantage given our constraints. So the question becomes which media to use. 9940B is out immediately due to cost ($40K/drive is insane). Which leaves LTO Gen2 at 200G native and S-AIT at 500G Native. Naturally I'm liking the S-AIT option because I can do offsites with a signficantly lower media count, despite the fact that the media cost is higher. And, because my data is primarily web content (HTML flattext and GIF/JPG images) I should be a pretty decent compression ratio. This brings me to the big question. Has anyone managing Filers used S-AIT yet? It's really an argument between Helical Scan tape technology (wear rate, failures, etc) vs the stable and proven Linear technology of LTO Gen2. Despite the drawbacks associated with all the problems inhearent to Helical Scan, the 500G native, and possible 2.66:1 (I expect that with my data 2:1 is adiquate) compression ration the advantages to S-AIT for Filer backup is really hard to ignore. My estimates right now in the pro-con area between the 2 formats looks like this: Total Capacity of each Filer as currently configured: 5.2TB Media Consumption per Filer: LTO Gen2: Backup of Full Capacity without Compression: 26 Tapes (approx) S-AIT: Backup of Full Capacity without Compression: 10 Tapes (approx) So assuming I get around 2:1 compression which is reasonable, I can do full capacity backups in 5 tapes per filer with S-AIT vs 13 with LTO! That means if I want to keep 4 complete backups at any given time, I need a library with an insane media count, because we're looking at 26x4x2=208 slots, and bring that down to 130 or so with compression. With S-AIT I need less than 50 not considering compression. And to that, with compression I might be able to cram all 5TB onto 4 tapes, which means I can buy a 4 drive library and stream to all 4 tapes similatiously without a media change in the middle. Anyway, obviously I'm feeling scared about S-AIT but cannot ignore the awsome potential it has for bulk data. Can anyone please share their insights or opinions? Is anyone currently using S-AIT for filers? Thanx. benr.

1 0

Linux NFS cache problem?
by Jun Ohata 15 Apr '04

15 Apr '04

Hi all, Has anyone encounter the problem like this? 1. If a user replace a file (which on the Filer) using cp command using Solaris 8 machine such as; # cp newfile oldfile 2. Then, on Linux server(NFS Client) A , reading the file, the file is new one. 3. But on another Linux server B, reading same file above, the file is stil OLD. We experienced many times on many files and Linux servers. I suspect some linux cache behavior (attribute caching?), but This situation still remain after a few days... [Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5 [Our Linux (all)] kernel 2.4.20, based on RHL 7.3 [Filer] F825, NetApp Release 6.3.3D2 I've read Technical report written by Chuck Lever(TR3183), noct and/or noac options may help, but I don't know why such long time Linux does not see a new file. Anyone? Thanks, -- Jun Ohata ohhata(a)tnes.nec.co.jp

4 4

diatribes f1nd a ch1ck racketeers
by Shuhei 15 Apr '04

15 Apr '04

1 0

unregister
by Wil Ng 13 Apr '04

13 Apr '04

---------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind ASL to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------------------------------------------------------------

1 0

WINING NOTIFICATION
by ELGORDO LOTERIA PRIMITIVA 12 Apr '04

12 Apr '04

ELGORDO LOTERIA PRIMITIVA PIS0 36, CALLE CARLOS OTERGA, 28002 MADRID, SPAIN. TEL/FAX: +34-645-630-404. FROM:THE DESK OF THE VIC-PRESIDENT. INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. REF NO: EGS/2551256007/03 BATCH NO: 15/0018/IPthD ATTENTION: RE:AWARD FINAL NOTIFICATION. We are pleased to inform you of the release of the result of the EL GROUP SWEEPSTAKE LOOTERY/INTERNATIONAL PROGRAMME played on the 15th March 2004.Your name attached to ticket number 025-11464992-750 with serial number 2113-05 drew the lucky numbers 13-15-22-37-39-45, Which consequently won the lottery in the 3rd category. You have therefore been approved for the lump sum pay out of 315,810.00 (Three Hundred and Fifteen Thousand Eight Hundred and Ten Euro Only) in cash credited to file Ref No: EGS/ 25512600/03. This is from a total cash prize shared among the thirty=0ne International Winners in this category. CONGATULATIONS!!! Your fund is now deposited with a security companyinsured on your name. Due to mixed up of some numbers and the names we ask that you keep this award from public notice until your claim has been processed and the money remitted to your account as this is part of our security protocol to avoid double claiming or unwarranted taking advantage of this programme by participants. All participants were selected through a computer ballot system drew from 25,000 names fromAsia,Australia,New Zealand, Middle East,Europe,North America as part of our International promotions programme, Which we conduct once every year. We hope your lucky name will a bigger win in the next programme.To begin your lottery claim, Please complete the PAYMENT PROCESSING FORM which will be send o you with this notification letter and you will fax a copy to a claim agent assigned to you. Mrs. Eva Perez. Foreign Operation manager EURO GLOBAL SECURITY COMPANY Tel: +34-675-118-081 Fax: +34-656-471-863. For the processing and remittance of your winning prize to a designated account of your choice. Remember, All prize money must be claimed notlatter than 28TH April 2004.After this date all fund will be returned to the MINISTERIO DE ECONOMIA HACIENDA AS UNCLAIMED. Note. In order to avoid unnecessary delays and complications. Please remember to quote your Reference Number, Batch Number and prize claim track number in every correspondence with your agent or us. Furthermore, Should there be any change of your address, do inform your claims agent as soon as possible. Congratulation again from all members of our staff and thank you for being a part of our promotions programme. Yours Sincerely. PEDRO GARZON CEO President PRIZE CLAIM TICKET NO: 31736745.

1 0

Be the dealer, win other players money japanese
by Leonard Rocha 12 Apr '04

12 Apr '04

1 0

My Impotency FINALLY solved! ild WA
by Dionne Emery 12 Apr '04

12 Apr '04

Be a winner with Apoll0! Quality enlargement from as little as just $40 a month Make a BIG difference in your life today with the power and promise of Apollo male enhancement patch. Increase size and stamina by up to 3 inches in as little as just 12 weeks! We guarantee your satisfaction or you get your payment back! Over 95% of our buyers have been astonished with the results! Click below to Learn more ORDER TODAY! http://iamtoor.com/4/1/index.php?ai=7038

1 0

Re[8]: Отдых в Сочи на майские праздники
by Tillable I. Report 09 Apr '04

09 Apr '04

РПаЎ±б l H

1 0

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

RE: CIFS performance Issue
by lallin＠millermartin.com 05 Apr '04

05 Apr '04

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 Jack Lyons 05 Apr '04

05 Apr '04

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

AW: AntiVirus Solutions
by Scholz Wolfgang 05 Apr '04

05 Apr '04

hi everybody, we are using trendmicro to scan our filer for about 8 months now without major issues. the only very annoying thing is that the error message box presented to the client in case of an infection is not customizable. the error message that comes from the trendmicro scanner is really unusable (it´s the complete path to the file which can be very very long) . regards wolfgang > -----Ursprüngliche Nachricht----- > Von: Jack Lyons [mailto:jack.lyons@martinagency.com] > Gesendet: Freitag, 2. April 2004 15:41 > An: 'toasters(a)mathworks.com' > Betreff: 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. > >

1 0

RE: CIFS performance Issue
by Jack Lyons 02 Apr '04

02 Apr '04

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:

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