toasters

toasters@lists.teaparty.net

13531 discussions

Can one change the number of disks in a raid group on the fly
by Brent Ellis 03 Apr '07

03 Apr '07

Question about resizing raid groups. Can one change the number of disks in a raid group on the fly in a netapp filer? I currently have an aggregate with a single raid groups and I would like to add another shelf. So as to reduce the amount of storage I lose can I change the size of the raid group and grow the underlying raid for the aggregate or do I have to start a new raid group? Brent Ellis Computing Services Group Boston University

3 2

RE: CIFS overhead with Netapp Filers
by Ganjihal, Chetan 03 Apr '07

03 Apr '07

I think it would be important to know the state of the system(filer), the values set for different options, system utilization etc. If there is a perfstat output with stats gathered during the operation(file copy) being carried out, it will help understand the problem. cheers Chetan ________________________________ From: Shane Garoutte [mailto:sgaroutte@gmail.com] Sent: Thursday, March 29, 2007 12:59 AM To: Langdon, Laughlin T. ((Lock)) Cc: Glenn Walker; toasters(a)mathworks.com Subject: Re: CIFS overhead with Netapp Filers A quick crawl on NOW provided the following: http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675 if CIFS performance is slow after investigating performance issues, modify the filer's CIFS negotiated buffer size. 1. Verify that hardware or software problems do not exist within the filer, network and client. 2. Record the CIFS negotiated buffer size by capturing the output of the filer command: options cifs.neg_buf_size 3. Enter the following filer commands: a. cifs terminate b. options cifs.neg_buf_size 16644 c. cifs restart 4. If the buffer size in step 3b does not improve performance, try the following buffer sizes: a. Use '17424'. Note: Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; therefore, upgrade to a release that fixes bug 33396 only if performance does not improve. b. Use '33472' for environments mixed with Windows NT and Windows 2000. c. Use '65340' for Windows 2000 only environments. 5. If performance remains slow: a. Re-confirm that hardware or software problems do not exist within the filer, network and client. b. Restore the original CIFS negotiated buffer size (refer to steps 2 and 3). c. During a performance interruption, capture a packet trace between the filer and Windows client. d. Send the packet trace to Network Appliance Technical Support for analysis. On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote: I'm doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth) From Windows server to windows server I get 500 Mbps From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps I've tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable. From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers Typically, you shouldn't see any performance decrease - rather, you should get better performance. Are you seeing some sort of decrease? What I can point out: with some things (Excel\Word to be specific), MS will implement stuff that's not really documented for the file open\discovery which can cause problems, but I doubt that's what you are running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn't always go very well given the fact that it's not the best technology and sometimes can display interop problems with other vendors (not just NetApp). What exactly are you doing for your test? Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters(a)mathworks.com Subject: CIFS overhead with Netapp Filers I was wondering what the CIFS overhead for a NetApp filer would be. Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps). Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead? What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap? (same results using static link aggregation, and LACP for the VIF) Thanks Lock

5 7

ontap gx
by grace rante 31 Mar '07

31 Mar '07

Heya, Any ontap gx users out there? im interested in checking out the coral/file striping/HPO feature of GX and just want to check here first if anybody already had a chance to play with HPO and if you guys have any feedbacks... thanks, graziee

2 1

Re: CIFS overhead with Netapp Filers
by Davies,Matt 30 Mar '07

30 Mar '07

Don't worry about it, I will try on Monday with new servers that have both broadcom and intel NICs in them and are what through out I get, are if that has any effect. Are the NICs in the servers you are testing with, inbuilt, PCI or PCI express ? And what manufacturer ? Cheers Matt -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: jack1729(a)gmail.com <jack1729(a)gmail.com>; chetan.ganjihal(a)netapp.com <chetan.ganjihal(a)netapp.com>; sgaroutte(a)gmail.com <sgaroutte(a)gmail.com>; ggwalker(a)mindspring.com <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 22:19:26 2007 Subject: RE: CIFS overhead with Netapp Filers srry.. zipped that part of your post :) The weird thing is that you are getting the same speed (low end) for server to server that I get to my filer 250Mbps.. but I get upwards of 500-600Mbps from server to server.. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 1:57 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: Re: CIFS overhead with Netapp Filers Did that, same speeds, sorry...... Matt -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: jack1729(a)gmail.com <jack1729(a)gmail.com>; chetan.ganjihal(a)netapp.com <chetan.ganjihal(a)netapp.com>; sgaroutte(a)gmail.com <sgaroutte(a)gmail.com>; ggwalker(a)mindspring.com <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 21:50:27 2007 Subject: RE: CIFS overhead with Netapp Filers can you take that same file and copy it from a server to a server on the same network etc? ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 1:16 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers In the interim, I decided to unbox and startup our new FAS270 and quickly set it up. With just a single nic I have taken a 500MB zip file, and copied from server A to the filer and from server A to another server. Both servers are running single Nics Peak rate was around 250Mb/s, average rate was around 130Mb/s to both the filer and the server. The filer is running 7.0.5 I have made no changes to TCP window size on either the servers or the filers, the servers are Win2k3 SP1. I also did the same test on our production FAS250 and got the same result, which is running 7.1 Sorry I haven’t been much help Cheers Matt From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@mayo.edu] Sent: 30 March 2007 20:40 To: Davies,Matt; slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers :) Already been down that path.. Heck I've gone single port, with a crossover cable.. same reuslts.. That's why I'm here.. to see if we're the only ones experiencing this, or if it's just what NetaApp does (I hope not ;) ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 12:38 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers Shame, that might have answered the problem. Have you tried just using 1 ethernet port on the filer ? Have you tried using ports on the same switch, I have seen some problems with cross stack etherchannels, usually if the stack isn’t connected correctly. The following command will give you the details. UKswitchstack#sh switch stack-ring speed Stack Ring Speed : 32G Stack Ring Configuration: Full Stack Ring Protocol : StackWise UKswitchstack# My new filer arrived today, but will try and reproduce on Monday But just so you know: After enabling QOS on cat3750, certain application (mostly bursty and TCP based) may experience significant performance degradation. This issue is resolved starting Cisco IOS 12.2(25)SEE1. With the changes in the new release, the following global config. commands are still required : ------------------------------------------------------------------------------ mls qos queue-set output 1 threshold 2 3200 3200 100 3200 mls qos queue-set output 1 threshold 3 3200 3200 100 3200 ------------------------------------------------------------------------------ Cheers Matt From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@mayo.edu] Sent: 30 March 2007 20:17 To: Davies,Matt; slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers sorry, Yes I meant 3750. No QOS. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 11:47 AM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: Re: CIFS overhead with Netapp Filers I presume you mean the 3750 ? Is QoS enabled on the switch ? -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: Jack Lyons <jack1729(a)gmail.com>; Ganjihal, Chetan <chetan.ganjihal(a)netapp.com>; Shane Garoutte <sgaroutte(a)gmail.com>; Glenn Walker <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 19:37:47 2007 Subject: RE: CIFS overhead with Netapp Filers 2 Cisco 3950s cross connected in the back. Should be configed for LACP, 3 ports on one switch 3 ports on the other switch. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Thu 3/29/2007 1:34 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers May be a stupid question, but what network switch are you using ? Cheers Matt ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: 29 March 2007 21:00 To: slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers yes, that all looks true Aggregate is maxed out size of 39 disks Raid DP. I’ve also tried 10k FC drives, and 7.5k SATA drives. Same performance. no jumbo frames. No cifs tuning. can anyone else try this? take a large file and copy it from a windows server to a windows server. then copy the sam file from the same server to a netapp filer. you can use the nul trigger to really isolate network usage (doesn;t actually write the file) What Mbps do you get on each xfer? I get approx 500 mbps to a windows server, and 250 mbps to the filer. same file, same tcp window size, same server.. only delta is once to server once to filer. If you want to you can also do a read from the filer and the server to get the read performance. ________________________________ From: slinkymax0r [mailto:slinkywizard@integra.net] Sent: Thu 3/29/2007 10:48 AM To: Langdon, Laughlin T. (Lock) Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers > my previous posts mention that I'm running 7.2.1.. now I've updated to > 7.2.1.1 Snapshot of thie issue: User is running windows 2003. Throughput ramps up with multiple copies, just doesn't seem to "fill the pipe" with a single file copy operation. No network errors, TCP and lower level tuning on the stack hasn't improved the issue.* (Any Netdiag output to share?) No idea if CIFs buffer tuning has been done on the filer, per NetApp CIFS troubleshooting instructions. No info on Aggregate Layout or volume options (Might be helpful). No idea if jumbo frames are part of the mix. Accurate so far? Regards, Max > ________________________________ > > From: Jack Lyons [mailto:jack1729@gmail.com] > Sent: Thu 3/29/2007 3:42 AM > To: Ganjihal, Chetan > Cc: Shane Garoutte; Langdon, Laughlin T. (Lock); Glenn Walker; > toasters(a)mathworks.com > Subject: Re: CIFS overhead with Netapp Filers > > > > Make sure that you don't have smb signing enabled, it was by default in > 7.0.1 but 7.0.2 later is was disabled by default. > > Ganjihal, Chetan wrote: >> I think it would be important to know the state of the system(filer), >> the values set for different options, system utilization etc. >> If there is a perfstat output with stats gathered during the >> operation(file copy) being carried out, it will help understand the >> problem. >> cheers >> Chetan >> ------------------------------------------------------------------------ >> *From:* Shane Garoutte [mailto:sgaroutte@gmail.com] >> *Sent:* Thursday, March 29, 2007 12:59 AM >> *To:* Langdon, Laughlin T. ((Lock)) >> *Cc:* Glenn Walker; toasters(a)mathworks.com >> *Subject:* Re: CIFS overhead with Netapp Filers >> >> A quick crawl on NOW provided the following: >> http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675 >> >> if CIFS performance is slow after investigating performance issues, >> modify the filer's CIFS negotiated buffer size. >> >> 1. Verify that hardware or software problems do not exist within the >> filer, network and client. >> 2. Record the CIFS negotiated buffer size by capturing the output of >> the filer command: >> options cifs.neg_buf_size >> 3. Enter the following filer commands: >> a. cifs terminate >> b. options cifs.neg_buf_size 16644 >> c. cifs restart >> 4. If the buffer size in step 3b does not improve performance, try the >> following buffer sizes: >> a. Use '17424'. >> Note: >> Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; >> therefore, upgrade to a release that fixes bug 33396 only if >> performance does not improve. >> b. Use '33472' for environments mixed with Windows NT and Windows 2000. >> c. Use '65340' for Windows 2000 only environments. >> 5. If performance remains slow: >> a. Re-confirm that hardware or software problems do not exist within >> the filer, network and client. >> b. Restore the original CIFS negotiated buffer size (refer to steps 2 >> and 3). >> c. During a performance interruption, capture a packet trace between >> the filer and Windows client. >> d. Send the packet trace to Network Appliance Technical Support for >> analysis. >> >> >> On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote: >> >>> I'm doing a straight drag and drop using UNC paths with a single >>> 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka >>> start more than one copy on more than one server the filer happily >>> provides more bandwidth) >>> >>> From Windows server to windows server I get 500 Mbps >>> >>> From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get >>> about 250 Mbps >>> >>> I've tried TCP windows size, Flow Control, LCAP, Static Link >>> Aggregation, Singe port on the filer (no vif), straight crossover >>> cable. >>> >>> *From:* Glenn Walker [mailto:ggwalker@mindspring.com] >>> *Sent:* Tuesday, March 27, 2007 5:15 PM >>> *To:* Langdon, Laughlin T. (Lock); toasters(a)mathworks.com >>> <mailto:toasters@mathworks.com> >>> *Subject:* RE: CIFS overhead with Netapp Filers >>> >>> Typically, you shouldn't see any performance decrease - rather, you >>> should get better performance. >>> >>> Are you seeing some sort of decrease? >>> >>> What I can point out: with some things (Excel\Word to be specific), >>> MS will implement stuff that's not really documented for the file >>> open\discovery which can cause problems, but I doubt that's what you >>> are running into given the speed you are speaking of. Likewise, using >>> Windows NLB (LB not HA) doesn't always go very well given the fact >>> that it's not the best technology and sometimes can display interop >>> problems with other vendors (not just NetApp). >>> >>> What exactly are you doing for your test? >>> >>> Glenn >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* owner-toasters(a)mathworks.com >>> [mailto:owner-toasters@mathworks.com] *On Behalf Of *Langdon, >>> Laughlin T. (Lock) >>> *Sent:* Tuesday, March 27, 2007 2:33 PM >>> *To:* toasters(a)mathworks.com <mailto:toasters@mathworks.com> >>> *Subject:* CIFS overhead with Netapp Filers >>> >>> I was wondering what the CIFS overhead for a NetApp filer would be. >>> >>> Let's say for instance a Windows Server to Windows Server transfer on >>> the same switch, same subnet, GIG copper interconnects, no TOE card, >>> etc gets me up to about 50% utilization (500Mbps). >>> >>> Should that same server to a Netapp Filer see a 20-30% degradation in >>> TX/RX speeds because of CIFS overhead? >>> >>> What should I expect for data rates in this type of scenario? Are >>> there any tweaks anyone knows of to decrease this gap? >>> >>> (same results using static link aggregation, and LACP for the VIF) >>> >>> Thanks >>> >>> Lock >>> >>> >> > > > ____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com. Thank You.

2 1

Re: CIFS overhead with Netapp Filers
by Davies,Matt 30 Mar '07

30 Mar '07

Did that, same speeds, sorry...... Matt -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: jack1729(a)gmail.com <jack1729(a)gmail.com>; chetan.ganjihal(a)netapp.com <chetan.ganjihal(a)netapp.com>; sgaroutte(a)gmail.com <sgaroutte(a)gmail.com>; ggwalker(a)mindspring.com <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 21:50:27 2007 Subject: RE: CIFS overhead with Netapp Filers can you take that same file and copy it from a server to a server on the same network etc? ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 1:16 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers In the interim, I decided to unbox and startup our new FAS270 and quickly set it up. With just a single nic I have taken a 500MB zip file, and copied from server A to the filer and from server A to another server. Both servers are running single Nics Peak rate was around 250Mb/s, average rate was around 130Mb/s to both the filer and the server. The filer is running 7.0.5 I have made no changes to TCP window size on either the servers or the filers, the servers are Win2k3 SP1. I also did the same test on our production FAS250 and got the same result, which is running 7.1 Sorry I haven’t been much help Cheers Matt From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@mayo.edu] Sent: 30 March 2007 20:40 To: Davies,Matt; slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers :) Already been down that path.. Heck I've gone single port, with a crossover cable.. same reuslts.. That's why I'm here.. to see if we're the only ones experiencing this, or if it's just what NetaApp does (I hope not ;) ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 12:38 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers Shame, that might have answered the problem. Have you tried just using 1 ethernet port on the filer ? Have you tried using ports on the same switch, I have seen some problems with cross stack etherchannels, usually if the stack isn’t connected correctly. The following command will give you the details. UKswitchstack#sh switch stack-ring speed Stack Ring Speed : 32G Stack Ring Configuration: Full Stack Ring Protocol : StackWise UKswitchstack# My new filer arrived today, but will try and reproduce on Monday But just so you know: After enabling QOS on cat3750, certain application (mostly bursty and TCP based) may experience significant performance degradation. This issue is resolved starting Cisco IOS 12.2(25)SEE1. With the changes in the new release, the following global config. commands are still required : ------------------------------------------------------------------------------ mls qos queue-set output 1 threshold 2 3200 3200 100 3200 mls qos queue-set output 1 threshold 3 3200 3200 100 3200 ------------------------------------------------------------------------------ Cheers Matt From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@mayo.edu] Sent: 30 March 2007 20:17 To: Davies,Matt; slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers sorry, Yes I meant 3750. No QOS. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Fri 3/30/2007 11:47 AM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: jack1729(a)gmail.com; chetan.ganjihal(a)netapp.com; sgaroutte(a)gmail.com; ggwalker(a)mindspring.com; toasters(a)mathworks.com Subject: Re: CIFS overhead with Netapp Filers I presume you mean the 3750 ? Is QoS enabled on the switch ? -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: Jack Lyons <jack1729(a)gmail.com>; Ganjihal, Chetan <chetan.ganjihal(a)netapp.com>; Shane Garoutte <sgaroutte(a)gmail.com>; Glenn Walker <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 19:37:47 2007 Subject: RE: CIFS overhead with Netapp Filers 2 Cisco 3950s cross connected in the back. Should be configed for LACP, 3 ports on one switch 3 ports on the other switch. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Thu 3/29/2007 1:34 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers May be a stupid question, but what network switch are you using ? Cheers Matt ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: 29 March 2007 21:00 To: slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers yes, that all looks true Aggregate is maxed out size of 39 disks Raid DP. I’ve also tried 10k FC drives, and 7.5k SATA drives. Same performance. no jumbo frames. No cifs tuning. can anyone else try this? take a large file and copy it from a windows server to a windows server. then copy the sam file from the same server to a netapp filer. you can use the nul trigger to really isolate network usage (doesn;t actually write the file) What Mbps do you get on each xfer? I get approx 500 mbps to a windows server, and 250 mbps to the filer. same file, same tcp window size, same server.. only delta is once to server once to filer. If you want to you can also do a read from the filer and the server to get the read performance. ________________________________ From: slinkymax0r [mailto:slinkywizard@integra.net] Sent: Thu 3/29/2007 10:48 AM To: Langdon, Laughlin T. (Lock) Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers > my previous posts mention that I'm running 7.2.1.. now I've updated to > 7.2.1.1 Snapshot of thie issue: User is running windows 2003. Throughput ramps up with multiple copies, just doesn't seem to "fill the pipe" with a single file copy operation. No network errors, TCP and lower level tuning on the stack hasn't improved the issue.* (Any Netdiag output to share?) No idea if CIFs buffer tuning has been done on the filer, per NetApp CIFS troubleshooting instructions. No info on Aggregate Layout or volume options (Might be helpful). No idea if jumbo frames are part of the mix. Accurate so far? Regards, Max > ________________________________ > > From: Jack Lyons [mailto:jack1729@gmail.com] > Sent: Thu 3/29/2007 3:42 AM > To: Ganjihal, Chetan > Cc: Shane Garoutte; Langdon, Laughlin T. (Lock); Glenn Walker; > toasters(a)mathworks.com > Subject: Re: CIFS overhead with Netapp Filers > > > > Make sure that you don't have smb signing enabled, it was by default in > 7.0.1 but 7.0.2 later is was disabled by default. > > Ganjihal, Chetan wrote: >> I think it would be important to know the state of the system(filer), >> the values set for different options, system utilization etc. >> If there is a perfstat output with stats gathered during the >> operation(file copy) being carried out, it will help understand the >> problem. >> cheers >> Chetan >> ------------------------------------------------------------------------ >> *From:* Shane Garoutte [mailto:sgaroutte@gmail.com] >> *Sent:* Thursday, March 29, 2007 12:59 AM >> *To:* Langdon, Laughlin T. ((Lock)) >> *Cc:* Glenn Walker; toasters(a)mathworks.com >> *Subject:* Re: CIFS overhead with Netapp Filers >> >> A quick crawl on NOW provided the following: >> http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675 >> >> if CIFS performance is slow after investigating performance issues, >> modify the filer's CIFS negotiated buffer size. >> >> 1. Verify that hardware or software problems do not exist within the >> filer, network and client. >> 2. Record the CIFS negotiated buffer size by capturing the output of >> the filer command: >> options cifs.neg_buf_size >> 3. Enter the following filer commands: >> a. cifs terminate >> b. options cifs.neg_buf_size 16644 >> c. cifs restart >> 4. If the buffer size in step 3b does not improve performance, try the >> following buffer sizes: >> a. Use '17424'. >> Note: >> Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; >> therefore, upgrade to a release that fixes bug 33396 only if >> performance does not improve. >> b. Use '33472' for environments mixed with Windows NT and Windows 2000. >> c. Use '65340' for Windows 2000 only environments. >> 5. If performance remains slow: >> a. Re-confirm that hardware or software problems do not exist within >> the filer, network and client. >> b. Restore the original CIFS negotiated buffer size (refer to steps 2 >> and 3). >> c. During a performance interruption, capture a packet trace between >> the filer and Windows client. >> d. Send the packet trace to Network Appliance Technical Support for >> analysis. >> >> >> On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote: >> >>> I'm doing a straight drag and drop using UNC paths with a single >>> 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka >>> start more than one copy on more than one server the filer happily >>> provides more bandwidth) >>> >>> From Windows server to windows server I get 500 Mbps >>> >>> From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get >>> about 250 Mbps >>> >>> I've tried TCP windows size, Flow Control, LCAP, Static Link >>> Aggregation, Singe port on the filer (no vif), straight crossover >>> cable. >>> >>> *From:* Glenn Walker [mailto:ggwalker@mindspring.com] >>> *Sent:* Tuesday, March 27, 2007 5:15 PM >>> *To:* Langdon, Laughlin T. (Lock); toasters(a)mathworks.com >>> <mailto:toasters@mathworks.com> >>> *Subject:* RE: CIFS overhead with Netapp Filers >>> >>> Typically, you shouldn't see any performance decrease - rather, you >>> should get better performance. >>> >>> Are you seeing some sort of decrease? >>> >>> What I can point out: with some things (Excel\Word to be specific), >>> MS will implement stuff that's not really documented for the file >>> open\discovery which can cause problems, but I doubt that's what you >>> are running into given the speed you are speaking of. Likewise, using >>> Windows NLB (LB not HA) doesn't always go very well given the fact >>> that it's not the best technology and sometimes can display interop >>> problems with other vendors (not just NetApp). >>> >>> What exactly are you doing for your test? >>> >>> Glenn >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* owner-toasters(a)mathworks.com >>> [mailto:owner-toasters@mathworks.com] *On Behalf Of *Langdon, >>> Laughlin T. (Lock) >>> *Sent:* Tuesday, March 27, 2007 2:33 PM >>> *To:* toasters(a)mathworks.com <mailto:toasters@mathworks.com> >>> *Subject:* CIFS overhead with Netapp Filers >>> >>> I was wondering what the CIFS overhead for a NetApp filer would be. >>> >>> Let's say for instance a Windows Server to Windows Server transfer on >>> the same switch, same subnet, GIG copper interconnects, no TOE card, >>> etc gets me up to about 50% utilization (500Mbps). >>> >>> Should that same server to a Netapp Filer see a 20-30% degradation in >>> TX/RX speeds because of CIFS overhead? >>> >>> What should I expect for data rates in this type of scenario? Are >>> there any tweaks anyone knows of to decrease this gap? >>> >>> (same results using static link aggregation, and LACP for the VIF) >>> >>> Thanks >>> >>> Lock >>> >>> >> > > > ____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com. Thank You.

2 1

Re: CIFS overhead with Netapp Filers
by Davies,Matt 30 Mar '07

30 Mar '07

I presume you mean the 3750 ? Is QoS enabled on the switch ? -----Original Message----- From: Langdon, Laughlin T. (Lock) <Langdon.Lock(a)mayo.edu> To: Davies,Matt; slinkywizard(a)integra.net <slinkywizard(a)integra.net> CC: Jack Lyons <jack1729(a)gmail.com>; Ganjihal, Chetan <chetan.ganjihal(a)netapp.com>; Shane Garoutte <sgaroutte(a)gmail.com>; Glenn Walker <ggwalker(a)mindspring.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Fri Mar 30 19:37:47 2007 Subject: RE: CIFS overhead with Netapp Filers 2 Cisco 3950s cross connected in the back. Should be configed for LACP, 3 ports on one switch 3 ports on the other switch. ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Thu 3/29/2007 1:34 PM To: Langdon, Laughlin T. (Lock); slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers May be a stupid question, but what network switch are you using ? Cheers Matt ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: 29 March 2007 21:00 To: slinkywizard(a)integra.net Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers yes, that all looks true Aggregate is maxed out size of 39 disks Raid DP. I’ve also tried 10k FC drives, and 7.5k SATA drives. Same performance. no jumbo frames. No cifs tuning. can anyone else try this? take a large file and copy it from a windows server to a windows server. then copy the sam file from the same server to a netapp filer. you can use the nul trigger to really isolate network usage (doesn;t actually write the file) What Mbps do you get on each xfer? I get approx 500 mbps to a windows server, and 250 mbps to the filer. same file, same tcp window size, same server.. only delta is once to server once to filer. If you want to you can also do a read from the filer and the server to get the read performance. ________________________________ From: slinkymax0r [mailto:slinkywizard@integra.net] Sent: Thu 3/29/2007 10:48 AM To: Langdon, Laughlin T. (Lock) Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers > my previous posts mention that I'm running 7.2.1.. now I've updated to > 7.2.1.1 Snapshot of thie issue: User is running windows 2003. Throughput ramps up with multiple copies, just doesn't seem to "fill the pipe" with a single file copy operation. No network errors, TCP and lower level tuning on the stack hasn't improved the issue.* (Any Netdiag output to share?) No idea if CIFs buffer tuning has been done on the filer, per NetApp CIFS troubleshooting instructions. No info on Aggregate Layout or volume options (Might be helpful). No idea if jumbo frames are part of the mix. Accurate so far? Regards, Max > ________________________________ > > From: Jack Lyons [mailto:jack1729@gmail.com] > Sent: Thu 3/29/2007 3:42 AM > To: Ganjihal, Chetan > Cc: Shane Garoutte; Langdon, Laughlin T. (Lock); Glenn Walker; > toasters(a)mathworks.com > Subject: Re: CIFS overhead with Netapp Filers > > > > Make sure that you don't have smb signing enabled, it was by default in > 7.0.1 but 7.0.2 later is was disabled by default. > > Ganjihal, Chetan wrote: >> I think it would be important to know the state of the system(filer), >> the values set for different options, system utilization etc. >> If there is a perfstat output with stats gathered during the >> operation(file copy) being carried out, it will help understand the >> problem. >> cheers >> Chetan >> ------------------------------------------------------------------------ >> *From:* Shane Garoutte [mailto:sgaroutte@gmail.com] >> *Sent:* Thursday, March 29, 2007 12:59 AM >> *To:* Langdon, Laughlin T. ((Lock)) >> *Cc:* Glenn Walker; toasters(a)mathworks.com >> *Subject:* Re: CIFS overhead with Netapp Filers >> >> A quick crawl on NOW provided the following: >> http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675 >> >> if CIFS performance is slow after investigating performance issues, >> modify the filer's CIFS negotiated buffer size. >> >> 1. Verify that hardware or software problems do not exist within the >> filer, network and client. >> 2. Record the CIFS negotiated buffer size by capturing the output of >> the filer command: >> options cifs.neg_buf_size >> 3. Enter the following filer commands: >> a. cifs terminate >> b. options cifs.neg_buf_size 16644 >> c. cifs restart >> 4. If the buffer size in step 3b does not improve performance, try the >> following buffer sizes: >> a. Use '17424'. >> Note: >> Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; >> therefore, upgrade to a release that fixes bug 33396 only if >> performance does not improve. >> b. Use '33472' for environments mixed with Windows NT and Windows 2000. >> c. Use '65340' for Windows 2000 only environments. >> 5. If performance remains slow: >> a. Re-confirm that hardware or software problems do not exist within >> the filer, network and client. >> b. Restore the original CIFS negotiated buffer size (refer to steps 2 >> and 3). >> c. During a performance interruption, capture a packet trace between >> the filer and Windows client. >> d. Send the packet trace to Network Appliance Technical Support for >> analysis. >> >> >> On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote: >> >>> I'm doing a straight drag and drop using UNC paths with a single >>> 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka >>> start more than one copy on more than one server the filer happily >>> provides more bandwidth) >>> >>> From Windows server to windows server I get 500 Mbps >>> >>> From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get >>> about 250 Mbps >>> >>> I've tried TCP windows size, Flow Control, LCAP, Static Link >>> Aggregation, Singe port on the filer (no vif), straight crossover >>> cable. >>> >>> *From:* Glenn Walker [mailto:ggwalker@mindspring.com] >>> *Sent:* Tuesday, March 27, 2007 5:15 PM >>> *To:* Langdon, Laughlin T. (Lock); toasters(a)mathworks.com >>> <mailto:toasters@mathworks.com> >>> *Subject:* RE: CIFS overhead with Netapp Filers >>> >>> Typically, you shouldn't see any performance decrease - rather, you >>> should get better performance. >>> >>> Are you seeing some sort of decrease? >>> >>> What I can point out: with some things (Excel\Word to be specific), >>> MS will implement stuff that's not really documented for the file >>> open\discovery which can cause problems, but I doubt that's what you >>> are running into given the speed you are speaking of. Likewise, using >>> Windows NLB (LB not HA) doesn't always go very well given the fact >>> that it's not the best technology and sometimes can display interop >>> problems with other vendors (not just NetApp). >>> >>> What exactly are you doing for your test? >>> >>> Glenn >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* owner-toasters(a)mathworks.com >>> [mailto:owner-toasters@mathworks.com] *On Behalf Of *Langdon, >>> Laughlin T. (Lock) >>> *Sent:* Tuesday, March 27, 2007 2:33 PM >>> *To:* toasters(a)mathworks.com <mailto:toasters@mathworks.com> >>> *Subject:* CIFS overhead with Netapp Filers >>> >>> I was wondering what the CIFS overhead for a NetApp filer would be. >>> >>> Let's say for instance a Windows Server to Windows Server transfer on >>> the same switch, same subnet, GIG copper interconnects, no TOE card, >>> etc gets me up to about 50% utilization (500Mbps). >>> >>> Should that same server to a Netapp Filer see a 20-30% degradation in >>> TX/RX speeds because of CIFS overhead? >>> >>> What should I expect for data rates in this type of scenario? Are >>> there any tweaks anyone knows of to decrease this gap? >>> >>> (same results using static link aggregation, and LACP for the VIF) >>> >>> Thanks >>> >>> Lock >>> >>> >> > > > ____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com. Thank You.

2 5

RE: CIFS overhead with Netapp Filers
by Langdon, Laughlin T. (Lock) 30 Mar '07

30 Mar '07

yes, that all looks true Aggregate is maxed out size of 39 disks Raid DP. I've also tried 10k FC drives, and 7.5k SATA drives. Same performance. no jumbo frames. No cifs tuning. can anyone else try this? take a large file and copy it from a windows server to a windows server. then copy the sam file from the same server to a netapp filer. you can use the nul trigger to really isolate network usage (doesn;t actually write the file) What Mbps do you get on each xfer? I get approx 500 mbps to a windows server, and 250 mbps to the filer. same file, same tcp window size, same server.. only delta is once to server once to filer. If you want to you can also do a read from the filer and the server to get the read performance. ________________________________ From: slinkymax0r [mailto:slinkywizard@integra.net] Sent: Thu 3/29/2007 10:48 AM To: Langdon, Laughlin T. (Lock) Cc: Jack Lyons; Ganjihal, Chetan; Shane Garoutte; Glenn Walker; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers > my previous posts mention that I'm running 7.2.1.. now I've updated to > 7.2.1.1 Snapshot of thie issue: User is running windows 2003. Throughput ramps up with multiple copies, just doesn't seem to "fill the pipe" with a single file copy operation. No network errors, TCP and lower level tuning on the stack hasn't improved the issue.* (Any Netdiag output to share?) No idea if CIFs buffer tuning has been done on the filer, per NetApp CIFS troubleshooting instructions. No info on Aggregate Layout or volume options (Might be helpful). No idea if jumbo frames are part of the mix. Accurate so far? Regards, Max > ________________________________ > > From: Jack Lyons [mailto:jack1729@gmail.com] > Sent: Thu 3/29/2007 3:42 AM > To: Ganjihal, Chetan > Cc: Shane Garoutte; Langdon, Laughlin T. (Lock); Glenn Walker; > toasters(a)mathworks.com > Subject: Re: CIFS overhead with Netapp Filers > > > > Make sure that you don't have smb signing enabled, it was by default in > 7.0.1 but 7.0.2 later is was disabled by default. > > Ganjihal, Chetan wrote: >> I think it would be important to know the state of the system(filer), >> the values set for different options, system utilization etc. >> If there is a perfstat output with stats gathered during the >> operation(file copy) being carried out, it will help understand the >> problem. >> cheers >> Chetan >> ------------------------------------------------------------------------ >> *From:* Shane Garoutte [mailto:sgaroutte@gmail.com] >> *Sent:* Thursday, March 29, 2007 12:59 AM >> *To:* Langdon, Laughlin T. ((Lock)) >> *Cc:* Glenn Walker; toasters(a)mathworks.com >> *Subject:* Re: CIFS overhead with Netapp Filers >> >> A quick crawl on NOW provided the following: >> http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675 >> >> if CIFS performance is slow after investigating performance issues, >> modify the filer's CIFS negotiated buffer size. >> >> 1. Verify that hardware or software problems do not exist within the >> filer, network and client. >> 2. Record the CIFS negotiated buffer size by capturing the output of >> the filer command: >> options cifs.neg_buf_size >> 3. Enter the following filer commands: >> a. cifs terminate >> b. options cifs.neg_buf_size 16644 >> c. cifs restart >> 4. If the buffer size in step 3b does not improve performance, try the >> following buffer sizes: >> a. Use '17424'. >> Note: >> Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; >> therefore, upgrade to a release that fixes bug 33396 only if >> performance does not improve. >> b. Use '33472' for environments mixed with Windows NT and Windows 2000. >> c. Use '65340' for Windows 2000 only environments. >> 5. If performance remains slow: >> a. Re-confirm that hardware or software problems do not exist within >> the filer, network and client. >> b. Restore the original CIFS negotiated buffer size (refer to steps 2 >> and 3). >> c. During a performance interruption, capture a packet trace between >> the filer and Windows client. >> d. Send the packet trace to Network Appliance Technical Support for >> analysis. >> >> >> On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote: >> >>> I'm doing a straight drag and drop using UNC paths with a single >>> 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka >>> start more than one copy on more than one server the filer happily >>> provides more bandwidth) >>> >>> From Windows server to windows server I get 500 Mbps >>> >>> From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get >>> about 250 Mbps >>> >>> I've tried TCP windows size, Flow Control, LCAP, Static Link >>> Aggregation, Singe port on the filer (no vif), straight crossover >>> cable. >>> >>> *From:* Glenn Walker [mailto:ggwalker@mindspring.com] >>> *Sent:* Tuesday, March 27, 2007 5:15 PM >>> *To:* Langdon, Laughlin T. (Lock); toasters(a)mathworks.com >>> <mailto:toasters@mathworks.com> >>> *Subject:* RE: CIFS overhead with Netapp Filers >>> >>> Typically, you shouldn't see any performance decrease - rather, you >>> should get better performance. >>> >>> Are you seeing some sort of decrease? >>> >>> What I can point out: with some things (Excel\Word to be specific), >>> MS will implement stuff that's not really documented for the file >>> open\discovery which can cause problems, but I doubt that's what you >>> are running into given the speed you are speaking of. Likewise, using >>> Windows NLB (LB not HA) doesn't always go very well given the fact >>> that it's not the best technology and sometimes can display interop >>> problems with other vendors (not just NetApp). >>> >>> What exactly are you doing for your test? >>> >>> Glenn >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* owner-toasters(a)mathworks.com >>> [mailto:owner-toasters@mathworks.com] *On Behalf Of *Langdon, >>> Laughlin T. (Lock) >>> *Sent:* Tuesday, March 27, 2007 2:33 PM >>> *To:* toasters(a)mathworks.com <mailto:toasters@mathworks.com> >>> *Subject:* CIFS overhead with Netapp Filers >>> >>> I was wondering what the CIFS overhead for a NetApp filer would be. >>> >>> Let's say for instance a Windows Server to Windows Server transfer on >>> the same switch, same subnet, GIG copper interconnects, no TOE card, >>> etc gets me up to about 50% utilization (500Mbps). >>> >>> Should that same server to a Netapp Filer see a 20-30% degradation in >>> TX/RX speeds because of CIFS overhead? >>> >>> What should I expect for data rates in this type of scenario? Are >>> there any tweaks anyone knows of to decrease this gap? >>> >>> (same results using static link aggregation, and LACP for the VIF) >>> >>> Thanks >>> >>> Lock >>> >>> >> > > >

3 3

bug #1287 problems with netgroup and rw access list
by Kerry Herschel 30 Mar '07

30 Mar '07

Hi, Has anyone had problems with using a netgroup name in a rw access list in an exports file? I just found bug #1287. I am using a netgroup file on the filer to define names to use in the exports file currently but I have had some problems. I am running DOT 7.0.3. It would be a real drawback if I can't use a netgroup name for rw access. Thanks, Kerry

4 4

RE: CIFS overhead with Netapp Filers
by Dean, Phil (ITO) 29 Mar '07

29 Mar '07

Just one question, Are you sure that the NIC duplex settings are correct, your not using auto on a port switch that is set as 100/Full? Also have you checked that you are not getting network errors on the filer side. Regards, Phil -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: Thursday, 29 March 2007 10:46 AM To: Shane Garoutte Cc: Langdon, Laughlin T. ((Lock)); toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers MS's implementation of NFS? Less overhead? Highly doubtful ;) I'm pretty sure that MS would make CIFS faster by making NFS slower... ________________________________ From: Shane Garoutte [mailto:sgaroutte@gmail.com] Sent: Wednesday, March 28, 2007 8:28 PM To: Glenn Walker Cc: Langdon, Laughlin T. ((Lock)); toasters(a)mathworks.com Subject: Re: CIFS overhead with Netapp Filers On Mar 28, 2007, at 5:04 PM, Glenn Walker wrote: As for the SMB vs CIFS thing, they're essentially the same. If you're using Windows, you're using CIFS (unless you've loaded services for unix, but I'm pretty sure you'd realize if you were utilizing NFS by accident). Due to the fact that it would be faster with less overhead? Oh wait, this is windows... nm ;) jk ************** 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. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. **************************************************************

2 1

RE: CIFS share on a Unix filesystem and Office 2003
by Miller, Michael CTR USTRANSCOM J2 29 Mar '07

29 Mar '07

I already have SecureShare in place. It's a great tool. I meant to put the permissions data in the last message. They are as expected. Mike -----Original Message----- From: tmac [mailto:tmacmd@gmail.com] Sent: Thursday, March 29, 2007 9:56 AM To: Miller, Michael CTR USTRANSCOM J2 Cc: toasters(a)mathworks.com Subject: Re: CIFS share on a Unix filesystem and Office 2003 Get the SecureShare Access: http://now.netapp.com/NOW/download/tools/ssaccess/ It should run on any MS platform. If you have not used it, after you install it (which takes seconds) whenever you right-click on a file that is on a Filer and select properties, you will get another tab...SecureShare. Here you can see UID/GID and all unix perms including sticky bits and so forth. If the permissions allow, you can also change the UNIX perms. This can also be used in a NTFS qtree, but everything is grayed out. I also do not think MS will help. Even though it is likely an OFFICE problem, Work with NetApp for a solution. MS will not change their application. --tmac On 3/29/07, Miller, Michael CTR USTRANSCOM J2 <michael.miller.ctr(a)ustranscom.mil> wrote: > I also think it is an Office issue, just wanted to see whatever one > else thought before I fought for a Microsoft trouble call. > > One part I forgot in the original message is that all tests were done > on the same file, in the same location, with the same Office 2003 load > and by the same user(me) with domain admin and root rights. The only > change was the system the test was done on. > > Mike > > > -----Original Message----- > From: tmac [mailto:tmacmd@gmail.com] > Sent: Thursday, March 29, 2007 9:10 AM > To: Miller, Michael CTR USTRANSCOM J2 > Cc: toasters(a)mathworks.com > Subject: Re: CIFS share on a Unix filesystem and Office 2003 > > > I am not positive, but this could be an issue with OFFICE. > > MS apps routinely create a temp file (a tilde file) and when you save, > it deletes the original and copies the tilde file into its' place. > > This wrecks havoc with a NetApp using MIXED or UNIX qtrees. Since the > original file is gone, the new file is written with new permissions. > > Check the UNIX perms on the file and see if they are what you expect. > > Maybe....you have you user mapping setup so your account maps to root? > Then your file could be written with UID 0, and then you may not be > able to access from Windows. > > In the NTFS side, even though the UID is root, there is also an ACE > that shows you as the owner (not root). > > There is a fix in ONTAP, although I do not think it was introduced > until 7.2. I think the option is "cifs.preserve_unix_security" > > > > On 3/29/07, Miller, Michael CTR USTRANSCOM J2 > <michael.miller.ctr(a)ustranscom.mil> wrote: > > > > > > > > I don't know if anyone can help but I thought I would ask. > > > > We host home directories and common file storage on a FAS960 running > > OnTap 7.0.3 with CIFS and NFS licenses. We use NTFS shares for > > Windows > > > roaming profiles but everything else is a Unix filesystem shared by > > CIFS and NFS. > > > > We had a problem show up when using Office 2003 with the Document > > Image Writer feature that I have not been able to track down. > > > > Using XP or 2003 systems I can print to the Document Image Writer > > printer, open the file it creates, modify and then save the file > > with no problems. > > > > On a 2000 Pro system I can create the file but I can not modify it > > after that from the Office 2003 MDI application. Whenever the file > > is opened you can make changes but you can not save the changes and > > there > > > are no errors or warnings generated. If the file is on a NTFS > > filesystem (NetApp or > > otherwise) you can make all of the changes you want. It is also > possible to > > create the file on the NFS filesystem, copy it to a NTFS filesystem, > make > > and save changes and then copy it back to the NFS filesystem > > properly. > > > > I have done all of the normal research and have even done packet > > captures. Nothing indicates what the issue might be. Any thoughts or > > hints? > > > > Thanks > > Mike Miller > > General Dynamics Information Technology > > Michael.Miller.ctr(a)ustranscom.mil Michael.Miller(a)gdit.com > > > > > -- > --tmac > > RedHat Certified Engineer > -- --tmac RedHat Certified Engineer

1 0

CIFS share on a Unix filesystem and Office 2003
by Miller, Michael CTR USTRANSCOM J2 29 Mar '07

29 Mar '07

I don't know if anyone can help but I thought I would ask. We host home directories and common file storage on a FAS960 running OnTap 7.0.3 with CIFS and NFS licenses. We use NTFS shares for Windows roaming profiles but everything else is a Unix filesystem shared by CIFS and NFS. We had a problem show up when using Office 2003 with the Document Image Writer feature that I have not been able to track down. Using XP or 2003 systems I can print to the Document Image Writer printer, open the file it creates, modify and then save the file with no problems. On a 2000 Pro system I can create the file but I can not modify it after that from the Office 2003 MDI application. Whenever the file is opened you can make changes but you can not save the changes and there are no errors or warnings generated. If the file is on a NTFS filesystem (NetApp or otherwise) you can make all of the changes you want. It is also possible to create the file on the NFS filesystem, copy it to a NTFS filesystem, make and save changes and then copy it back to the NFS filesystem properly. I have done all of the normal research and have even done packet captures. Nothing indicates what the issue might be. Any thoughts or hints? Thanks Mike Miller General Dynamics Information Technology Michael.Miller.ctr(a)ustranscom.mil Michael.Miller(a)gdit.com

2 2

CIFS overhead with Netapp Filers
by Langdon, Laughlin T. (Lock) 29 Mar '07

29 Mar '07

I was wondering what the CIFS overhead for a NetApp filer would be. Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps). Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead? What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap? (same results using static link aggregation, and LACP for the VIF) Thanks Lock

6 15

Re: CIFS overhead with Netapp Filers
by Bryan_West＠shamrockfoods.com 28 Mar '07

28 Mar '07

It could be your network cards we experienced the same issue years ago and replacing the network cards on our windows servers solved it. ----- Original Message ----- From: "Paul Keating" [pkeating(a)bank-banque-canada.ca] Sent: 03/28/2007 08:58 AM To: "Langdon, Laughlin T. (Lock)" <Langdon.Lock(a)Mayo.EDU>;"Brosseau, Paul" <Paul.Brosseau(a)netapp.com>;<toasters(a)mathworks.com> Subject: RE: CIFS overhead with Netapp Filers Windows *is* CIFS. Even many MS docs have dropped references to SMB, or will say something like "...CIFS (formerly SMB)...." Paul -- -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: March 28, 2007 11:34 AM To: Brosseau, Paul; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers I'm assuming the windows to windows xfer is actually SMB not CIFS ==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu.

2 1

RE: CIFS overhead with Netapp Filers
by Paul Keating 28 Mar '07

28 Mar '07

I assume, in both cases, you're doing the test, right after a clean reboot of the Windows server or filer? ie, you're reading from the disk and not from cache? Are you reading from a similar backend disk subsystem in both cases? Paul -- -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: March 28, 2007 12:10 PM To: Willeke, Jochen; Brosseau, Paul; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers Either way our performance is in the dirt ;) From: Willeke, Jochen [mailto:Jochen.Willeke@wincor-nixdorf.com] Sent: Wednesday, March 28, 2007 9:09 AM To: Langdon, Laughlin T. (Lock); Brosseau, Paul; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers AFAIK SMB and CIFS is quite the same. SMB is the old name and CIFS is the rebrand :D Regards Jochen _____ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Wednesday, March 28, 2007 5:34 PM To: Brosseau, Paul; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers I'm assuming the windows to windows xfer is actually SMB not CIFS From: Brosseau, Paul [mailto:Paul.Brosseau@netapp.com] Sent: Wednesday, March 28, 2007 7:16 AM To: Langdon, Laughlin T. (Lock); toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers Wouldn't the Windows Server to Windows Server file transsfer also use CIFS? How are the 2 Windows servers logically connected? Mapped drive? Network Place? IN either case they would also be using CIFS as their file transfer protocol. Remember, CIFS is a Windows protocol not a Netapp protocol. We simply implement it on our storage controllers (filers). I would expect performance to be as good or better. Paulb From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@Mayo.EDU] Sent: Tuesday, March 27, 2007 2:33 PM To: toasters(a)mathworks.com Subject: CIFS overhead with Netapp Filers I was wondering what the CIFS overhead for a NetApp filer would be. Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps). Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead? What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap? (same results using static link aggregation, and LACP for the VIF) Thanks Lock ==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu.

2 1

RE: CIFS overhead with Netapp Filers
by Paul Keating 28 Mar '07

28 Mar '07

Windows *is* CIFS. Even many MS docs have dropped references to SMB, or will say something like "...CIFS (formerly SMB)...." Paul -- -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: March 28, 2007 11:34 AM To: Brosseau, Paul; toasters(a)mathworks.com Subject: RE: CIFS overhead with Netapp Filers I'm assuming the windows to windows xfer is actually SMB not CIFS ==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu.

1 0

Method to exercise tape drive?
by Darren Dunham 28 Mar '07

28 Mar '07

Sometimes when troubleshooting backups I want to see if the host can drive data to a tape drive at high speed without involving a filesystem or backup software or the like. I've got some slow NDMP backups on some filers that have fiber-attached LTO-3 drives. At the moment I'm assuming that the contents of the filesystem make it difficult to drive the tapes at high speed, but it would be nice to have another data point that would show that the local drive is or is not behaving properly. Is there any way to have the filer send data to the drive without actually invoking an NDMP backup or running a 'dump'? On another host I might mount a scratch tape and run 'dd if=/dev/zero of=/dev/tape' with an appropriate block size and count. I see a 'dd', but I don't know of a data source like /dev/zero. Is this or something similar possible? Thanks. -- Darren Dunham ddunham(a)taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >

2 1

NFS File locking between Linux/Windows
by masterblaster 28 Mar '07

28 Mar '07

Hi everyone, currently we have a problem with file locking between Linux and Windows. We use shared access via NFS to files on a FAS3050 filer from Linux and Windows clients. We noticed that file locks, which are set by Linux, only apply to Linux clients and file locks, which are set by Windows, only apply to Windows clients and not vice versa. Question: Is it possible to lock files via NFS from Linux in that way that the files are also locked for Windows client and vice versa (i.e. for OpenOffice Documents) ? Environment: - Netapp Filer FAS3050 with Ontap 7.1.1.1 - Linux NFS Client (Suse 10.0) - Windows XP NFS Client (NFS Client: Microsoft Services for Unix) - Windows NT with Maestro NFS (from Hummingbird) Test programs: - Linux: "flock" command - Windows: "locktest.exe" We don't need byte-range or oplocks ! Just the whole file needs to be locked. Any ideas ? Thanks in advance. -- View this message in context: http://www.nabble.com/NFS-File-locking-between-Linux-Windows-tf3452921.html… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

2 2

RE: Any way to dump file listings with acls
by George, Andrew 27 Mar '07

27 Mar '07

You could try dumpsec (google it, it's on winfiles from memory). Be prepared for it to take a LONG time and generate some big files though _____ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Ken Williams Sent: Wednesday, 28 March 2007 6:51 AM To: toasters(a)mathworks.com Subject: Any way to dump file listings with acls Does anyone know of a way to dump out the complete file listing of a filer? How about a way that includes the ACL? I want to get an index of all the files on each of our filers. Currently I'm using an NFS mounted volume and running "find ./ >> findfile". I've also tried using gnu slocate (basically find driven by an index database). Both of these methods take long periods of time. __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213 "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."

1 0

Any way to dump file listings with acls
by Ken Williams 27 Mar '07

27 Mar '07

Does anyone know of a way to dump out the complete file listing of a filer? How about a way that includes the ACL? I want to get an index of all the files on each of our filers. Currently I'm using an NFS mounted volume and running "find ./ >> findfile". I've also tried using gnu slocate (basically find driven by an index database). Both of these methods take long periods of time. __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213

1 0

LACP and filers
by tmac 27 Mar '07

27 Mar '07

Has anyone successfully configured LACP for channeling of interface to a Cat6500? What is commands are need on the Switch (IOS)? What needs to be done on the filer? I played with this, but was uncertain. Can anyone shed some light? thanks -- --tmac RedHat Certified Engineer #804006984323821 Principal Consultant, RABA Technologies 240-373-3926 (office) 301-688-4705 (Lab) 214-279-3926 (eFAX)

2 1

Re: how to obtain patch releases
by Chris Thompson 27 Mar '07

27 Mar '07

Mention of patch releases prompts me to vent spleen about the following... If you exercise NOW to fetch ONTAP 7.1.2 you end up at http://now.netapp.com/NOW/download/software/ontap/7.1.2/download.shtml which looks fine until you realise there's no reference to checksums for the files you are about to download. Mystified, I tried 7.1.2P1 instead, which ends one at http://now.netapp.com/NOW/download/software/ontap/7.1.2P1/download.cgi which has the expected link to a checksum page. So although I didn't need any of the fixes in the P1 version, I decide to use that instead. Later, it occurred to me to look at http://now.netapp.com/NOW/download/software/ontap/7.1.2/download.cgi which does have a link to the checksums for the 7.1.2 files. But by then, it was too late ... [In case you are wondering, I am not avoiding 7.2.x because of the problems described by various toaster-posters, but because I am stuck with an F800 series filer.] -- Chris Thompson Email: cet1(a)cam.ac.uk

1 0

RE: Drive cleaning
by Todd Kofchur 27 Mar '07

27 Mar '07

" Now, LTO technology has a variable speed head which speeds up and slows down relative to the speed of the tape passing it. This removes the shoe-shine affect seen in DLT drives." This does not completely remove the possibility of shoe-shine. All tape drives must maintain a minimal speed to write data to the tape and they will NOT be able to go below this threshold. If your network is slower than this minimal threshold you will get shoe-shining even with variable speed heads. __________________________ Todd Kofchur President Penaria Technologies, Inc. O: 703-327-3874 C: 703-220-0347 www.penaria.com -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Parsons, Steve Sent: Tuesday, March 27, 2007 12:51 PM To: Mark.Jeffries(a)ubs.com; tmacmd(a)gmail.com; pkeating(a)bank-banque-canada.ca Cc: michael.miller.ctr(a)ustranscom.mil; toasters(a)mathworks.com Subject: RE: Drive cleaning Rather, http://www.overlandstorage.com/whitepapers/LTO_Cleaning_wp.pdf. Steve -----Original Message----- From: Mark.Jeffries(a)ubs.com [mailto:Mark.Jeffries@ubs.com] Sent: Tuesday, March 27, 2007 4:47 AM To: tmacmd(a)gmail.com; pkeating(a)bank-banque-canada.ca Cc: michael.miller.ctr(a)ustranscom.mil; toasters(a)mathworks.com Subject: RE: Drive cleaning It is a little known fact that cleaning tapes do not clean. They are a fixed length of tape which is used to calibrate the gearing of drives when an error occurs. For instance, a DLT drive needs it's head spin speed to be synchronised with the speed that the tape passes it as the tape needs to move at a constant speed. If too many errors occur, a DLT drive will ask to be "cleaned". Now, LTO technology has a variable speed head which speeds up and slows down relative to the speed of the tape passing it. This removes the shoe-shine affect seen in DLT drives. I have never seen an LTO drive require "cleaning" as they tend to always be in sync. Take from this what you will, but I'd rather use the space in the library for data. If an LTO drive asks for cleaning, it has issues!!! Regards, Jeffers. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of tmac Sent: 26 March 2007 14:14 To: Paul Keating Cc: Miller, Michael CTR USTRANSCOM J2; toasters(a)mathworks.com Subject: Re: Drive cleaning It is fixed now. NBU 6.0 does in fact support TapeAlert on most NDMP-attached tape drives now. All the tapes were discovered, I told it which two were cleaning tapes. NBU just never modified the "cleanings left" and left it at 0. Hence, I had no available media. As soon as I moved it to a non-zero number, it was good. On 3/26/07, Paul Keating <pkeating(a)bank-banque-canada.ca> wrote: > > The STK libraries only require them if you're using library based > cleaning. > > If you're using tape alert, or otherwise using Netbackup controlled > cleaning, you can make any tape ID a cleaning tape......then using "CLN" > labels is only a Really Good Idea (TM). > > Also, Tape alert does not work (or didn't, last I heard) for Filer > attached drives. > Any tape drives connected to an NDMP device must be cleaned manually, > or on a "frequency based" schedule, as the NDMP devices do not know > what to do with the received tape alert message, like a Netbackup > media server would. > You could use Library based cleaning, but that must be turned on for > all drives in the Libary, and frequently causes problems with Netbackup. > > Now back to your problem. If the media were "discovered" by Netbackup, > and they didn't have a barcode rule defined for them, they were > probably placed in the "DEFAULT" media type, which is probably HCART3. > In that case, you need to change the cleaning tapes to media type > "HC3_CLN", and make sure the "number of cleanings remaining" is set to > a value higher than 0, Volume Pool is set to "None". > > However it is much easier to define your cleaning tapes before you > inventory the robot, as you can't change the media type in the GUI for > an assigned media cart. > > Cheers, > > Paul > -- > > > > -----Original Message----- > > From: owner-toasters(a)mathworks.com > > [mailto:owner-toasters@mathworks.com] On Behalf Of Miller, Michael > > CTR USTRANSCOM J2 > > Sent: March 26, 2007 7:25 AM > > To: tmac; toasters(a)mathworks.com > > Subject: RE: Drive cleaning > > > > > > Do you need a cleaning tape barcode label? Assumes your library uses > > barcodes of course, I don't know the device myself. The StorageTek > > libraries I have used required them. > > > > Mike Miller > > General Dynamics Information Technology Michael.Miller(a)gdit.com > > Phone: 618-229-1185 > > > > > > -----Original Message----- > > From: owner-toasters(a)mathworks.com > > [mailto:owner-toasters@mathworks.com] > > On Behalf Of tmac > > Sent: Sunday, March 25, 2007 5:00 PM > > To: toasters(a)mathworks.com > > Subject: Drive cleaning > > > > > > I have: > > > > 2 x R200(7.2.1.1), 1 x FAS980(7.2.1.1), 1 x Brocade 3850 > > (5.2.0a) Scalar > > i500 (320) with 3 x LTO-3 (IBM, 64D0) All connected through FC > > switch. Th library is licensed for 82 slots. 80 of them have LTO3 > > tapes 2 of them are cleaning tapes > > > > I run the auto-configure on Veritas. > > It picks up the library on all three filers, only uses the library > > on one (as expected). It sees three paths to each of the tape drives > > (also as expected) The inventory scans all the media and sees 82 > > tapes. I tell > > it ID 99 & 100 are the cleaning tapes. > > > > I can create policies and backup without any problems. > > > > Veritas NBU 6.0 (and MP2, MP3 & MP4) has a problem trying to clean > > the tape drives. When I try to manually clean one I get the > > following: > > > > (96) unable to allocate new media for backup, storage unit has none > > available > > > > Detailed status: > > requesting resource IBM.ULTRIUM-TD3:001:__ANY__ > > Error nbjm (pid=22634) NBU status: 96, EMM status: No media is > > available unable to allocate new media for backup, storage unit has > > none available > > (96) > > > > Every time, it is the same. > > > > TapeAlert shows enabled for the drives. > > > > > > Anyone have any ideas? > > > > -- > > --tmac > > > > RedHat Certified Engineer > > > ====================================================================== > ============== > > La version française suit le texte anglais. > > ---------------------------------------------------------------------- > -------------- > > This email may contain privileged and/or confidential information, and > the Bank of Canada does not waive any related rights. Any > distribution, use, or copying of this email or the information it > contains by other than the intended recipient is unauthorized. If you > received this email in error please delete it immediately from your > system and notify the sender promptly by email that you have done so. > > ---------------------------------------------------------------------- > -------------- > > Le présent courriel peut contenir de l'information privilégiée ou > confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y > rapportent. Toute diffusion, utilisation ou copie de ce courriel ou > des renseignements qu'il contient par une personne autre que le ou les > destinataires désignés est interdite. Si vous recevez ce courriel par > erreur, veuillez le supprimer immédiatement et envoyer sans délai à > l'expéditeur un message électronique pour l'aviser que vous avez > éliminé de votre ordinateur toute copie du courriel reçu. > -- --tmac RedHat Certified Engineer Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.

1 0

how to obtain patch releases
by J. Greg Mackinnon 27 Mar '07

27 Mar '07

We currently are running OnTap 7.2.0 and not having fun with it. 7.2.1 contains many important fixes, but 7.2.1P1 has some critical fixes as well. I am getting fed up waiting for the next GA release, and I am willing to take the risk of running a patch build. The only problem... I cannot figure out how to download it! In the past I have found patch release download links in the NOW KB when referencing a related bug number... not so this time. Anyone know how to get the binaries? Open a support case? Bribe a NetApp tech? Thanks, -Greg Mackinnon University of Vermont

4 3

RE: Drive cleaning
by Paul Keating 27 Mar '07

27 Mar '07

The STK libraries only require them if you're using library based cleaning. If you're using tape alert, or otherwise using Netbackup controlled cleaning, you can make any tape ID a cleaning tape......then using "CLN" labels is only a Really Good Idea (TM). Also, Tape alert does not work (or didn't, last I heard) for Filer attached drives. Any tape drives connected to an NDMP device must be cleaned manually, or on a "frequency based" schedule, as the NDMP devices do not know what to do with the received tape alert message, like a Netbackup media server would. You could use Library based cleaning, but that must be turned on for all drives in the Libary, and frequently causes problems with Netbackup. Now back to your problem. If the media were "discovered" by Netbackup, and they didn't have a barcode rule defined for them, they were probably placed in the "DEFAULT" media type, which is probably HCART3. In that case, you need to change the cleaning tapes to media type "HC3_CLN", and make sure the "number of cleanings remaining" is set to a value higher than 0, Volume Pool is set to "None". However it is much easier to define your cleaning tapes before you inventory the robot, as you can't change the media type in the GUI for an assigned media cart. Cheers, Paul -- > -----Original Message----- > From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com] On Behalf Of Miller, > Michael CTR USTRANSCOM J2 > Sent: March 26, 2007 7:25 AM > To: tmac; toasters(a)mathworks.com > Subject: RE: Drive cleaning > > > Do you need a cleaning tape barcode label? Assumes your library uses > barcodes of course, I don't know the device myself. The StorageTek > libraries I have used required them. > > Mike Miller > General Dynamics Information Technology > Michael.Miller(a)gdit.com > Phone: 618-229-1185 > > > -----Original Message----- > From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com] > On Behalf Of tmac > Sent: Sunday, March 25, 2007 5:00 PM > To: toasters(a)mathworks.com > Subject: Drive cleaning > > > I have: > > 2 x R200(7.2.1.1), 1 x FAS980(7.2.1.1), 1 x Brocade 3850 > (5.2.0a) Scalar > i500 (320) with 3 x LTO-3 (IBM, 64D0) All connected through FC switch. > Th library is licensed for 82 slots. 80 of them have LTO3 tapes 2 of > them are cleaning tapes > > I run the auto-configure on Veritas. > It picks up the library on all three filers, only uses the library on > one (as expected). It sees three paths to each of the tape > drives (also > as expected) The inventory scans all the media and sees 82 > tapes. I tell > it ID 99 & 100 are the cleaning tapes. > > I can create policies and backup without any problems. > > Veritas NBU 6.0 (and MP2, MP3 & MP4) has a problem trying to clean the > tape drives. When I try to manually clean one I get the following: > > (96) unable to allocate new media for backup, storage unit has none > available > > Detailed status: > requesting resource IBM.ULTRIUM-TD3:001:__ANY__ > Error nbjm (pid=22634) NBU status: 96, EMM status: No media > is available > unable to allocate new media for backup, storage unit has > none available > (96) > > Every time, it is the same. > > TapeAlert shows enabled for the drives. > > > Anyone have any ideas? > > -- > --tmac > > RedHat Certified Engineer > ==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu.

4 3

Drive cleaning
by tmac 26 Mar '07

26 Mar '07

I have: 2 x R200(7.2.1.1), 1 x FAS980(7.2.1.1), 1 x Brocade 3850 (5.2.0a) Scalar i500 (320) with 3 x LTO-3 (IBM, 64D0) All connected through FC switch. Th library is licensed for 82 slots. 80 of them have LTO3 tapes 2 of them are cleaning tapes I run the auto-configure on Veritas. It picks up the library on all three filers, only uses the library on one (as expected). It sees three paths to each of the tape drives (also as expected) The inventory scans all the media and sees 82 tapes. I tell it ID 99 & 100 are the cleaning tapes. I can create policies and backup without any problems. Veritas NBU 6.0 (and MP2, MP3 & MP4) has a problem trying to clean the tape drives. When I try to manually clean one I get the following: (96) unable to allocate new media for backup, storage unit has none available Detailed status: requesting resource IBM.ULTRIUM-TD3:001:__ANY__ Error nbjm (pid=22634) NBU status: 96, EMM status: No media is available unable to allocate new media for backup, storage unit has none available (96) Every time, it is the same. TapeAlert shows enabled for the drives. Anyone have any ideas? -- --tmac RedHat Certified Engineer

2 2

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