Hi, We have several F330 in TIF, 2 of them have an enourmous number of small files: over 3.5M for one single volume. We have increase the maxfiles value to 4328504.
We have currently a significative degradation of backup performances on these 2 servers: backup are done at 1.5Gb, on both server, wheras we reach 5Gb/h for the 3 others.
Servers are all running Dataontap5.2.3, and are all identical. F330, 128Mb Ram, 24*4Gb disks,
I wonder what kind of fine tuning can be done to speed up the backup.
-- Regards, Pierre .
+------------------------------------------------------+ | Pierre Maubert, Sys_Admin Texas Instruments France | | email:p-maubert@ti.com Tel: +33 49322.2681 | | Fax: +33 49202.4669 Pager: 0606498982 | +------------------------------------------------------+
Hi, We have several F330 in TIF, 2 of them have an enourmous number of small files: over 3.5M for one single volume. We have increase the maxfiles value to 4328504.
We have currently a significative degradation of backup performances on these 2 servers: backup are done at 1.5Gb, on both server, wheras we reach 5Gb/h for the 3 others.
How heavily is the filer being used for other things when your backups are running? is this a locally attached device? are you able to keep it streaming? how fast is your network? are you running full duplex?
-s
We've been having a strange routing problem with our 2 NetApps for the past month or so in which the NetApps cannot ping the Cisco router on their subnet (their default route). We have a F740 running 5.2.3 and a F540 running 5.1.2R2 and both are having this problem. The NetApps can also not ping (or connect with any other IP protocol) other hosts on other subnets. However, if a packet crosses the router to a host that the NetApp previously could not reach, then that host becomes reachable for a while. Other hosts on the same subnet as the NetApps do not have this problem, they can ping the router and other hosts on other subnets. However, the Cisco 2924 switch that the NetApps and other hosts are connected to also shows this same behavior. This has led us to suspect a problem with the Cisco switches or router, but we have pretty much eliminated any hardware problems. We have an interesting bridge-group configuration on the router to allow Sun Autoclients to boot from their server which is 1 hop away, and are also using Cisco Hot Standby Router protocol so it could be a weird interaction of these protocols that is confusing the 2924 switch. Still, why are the NetApps the only hosts that seem the be bothered?
The problem was causing "NFS server not responding" incidents lasting for up to 10+ minutes on our clients that were 1 router hop away from the NetApps until I wrote a script that runs on a Sun that pings all of these clients once a minute. There were no clues in the NetApps' or clients' logs.
Has anyone else ever seen a situation like this where the Netapp could not ping its default router?
Does anyone have any advice about using NFS across routers that can minimize or prevent the pauses that we observe on our clients?
Thank you,
Mike
This may be too simple, but it sounds exactly like an ARP problem. Check the subnet mask on the NetApps and do a 'show arp' on the cisco to see if it has arp entries for the filers.
At 9:47 am -0800 8/11/99, Mike Mueller wrote:
We've been having a strange routing problem with our 2 NetApps for the past month or so in which the NetApps cannot ping the Cisco router on their subnet (their default route). We have a F740 running 5.2.3 and a F540 running 5.1.2R2 and both are having this problem. The NetApps can also not ping (or connect with any other IP protocol) other hosts on other subnets. However, if a packet crosses the router to a host that the NetApp previously could not reach, then that host becomes reachable for a while. Other hosts on the same subnet as the NetApps do not have this problem, they can ping the router and other hosts on other subnets. However, the Cisco 2924 switch that the NetApps and other hosts are connected to also shows this same behavior. This has led us to suspect a problem with the Cisco switches or router, but we have pretty much eliminated any hardware problems. We have an interesting bridge-group configuration on the router to allow Sun Autoclients to boot from their server which is 1 hop away, and are also using Cisco Hot Standby Router protocol so it could be a weird interaction of these protocols that is confusing the 2924 switch. Still, why are the NetApps the only hosts that seem the be bothered?
Alex.
"Future" is inherently plural. -- William Gibson
At 10:59 AM 11/8/99 , Alex French wrote:
This may be too simple, but it sounds exactly like an ARP problem. Check the subnet mask on the NetApps and do a 'show arp' on the cisco to see if it has arp entries for the filers.
Good ideas, but we had already checked the ARP tables and masks.
-- Mike
Mike,
I am not familiar with this hub. Be sure to set the port(s) on the hub to a fixed entity, such as 100 Base-T Full Duplex, and then configure the interface of the filer to the same setting using "ifconfig". Having the interface of the filer or the ports on your router auto detecting anything leads to odd results.
-gdg
Mike Mueller wrote:
We've been having a strange routing problem with our 2 NetApps for the past month or so in which the NetApps cannot ping the Cisco router on their subnet (their default route). We have a F740 running 5.2.3 and a F540 running 5.1.2R2 and both are having this problem. The NetApps can also not ping (or connect with any other IP protocol) other hosts on other subnets. However, if a packet crosses the router to a host that the NetApp previously could not reach, then that host becomes reachable for a while. Other hosts on the same subnet as the NetApps do not have this problem, they can ping the router and other hosts on other subnets. However, the Cisco 2924 switch that the NetApps and other hosts are connected to also shows this same behavior. This has led us to suspect a problem with the Cisco switches or router, but we have pretty much eliminated any hardware problems. We have an interesting bridge-group configuration on the router to allow Sun Autoclients to boot from their server which is 1 hop away, and are also using Cisco Hot Standby Router protocol so it could be a weird interaction of these protocols that is confusing the 2924 switch. Still, why are the NetApps the only hosts that seem the be bothered?
The problem was causing "NFS server not responding" incidents lasting for up to 10+ minutes on our clients that were 1 router hop away from the NetApps until I wrote a script that runs on a Sun that pings all of these clients once a minute. There were no clues in the NetApps' or clients' logs.
Has anyone else ever seen a situation like this where the Netapp could not ping its default router?
Does anyone have any advice about using NFS across routers that can minimize or prevent the pauses that we observe on our clients?
Thank you,
Mike
Thanks for the suggestion, but alas this is also not it. Our F540 has 2 interfaces, one of which is FDDI (which doesn't have the problem) and the other is already set to not negotiate as 100tx-fd along with the switch port. The F740 has 1 interface and is set to autonegotiate, but since it hasn't had the drastic performance problems observed with a duplex mismatch and since the F540 is set to not negotiate this rules out this as a factor.
-- Mike
At 11:17 AM 11/8/99 , G D Geen wrote:
Mike,
I am not familiar with this hub. Be sure to set the port(s) on the hub to a fixed entity, such as 100 Base-T Full Duplex, and then configure the interface of the filer to the same setting using "ifconfig". Having the interface of the filer or the ports on your router auto detecting anything leads to odd results.
-gdg
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
Eyal.
Maybe we should start sending rc files of each site so we can compare ?
Ours is:
#Auto-generated by setup Wed Nov 25 15:29:16 IST 1998 hostname netapp2 vif create multi vif0 e0 e3a e3b e3c ifconfig vif0 `hostname`-vif0 mediatype 100tx-fd -wins route add default 223.21.95.254 1 timezone Israel options raid.reconstruct_speed 8 options dns.domainname msil.sps.mot.com options dns.enable off options nis.domainname netmaster options nis.enable on savecore nfs on exportfs -a options autosupport.mailhost msgtel1 options autosupport.to r55789@msgtel1.sps.mot.com,netapp@msil.sps.mot.com,autosupport@netapp.com,netapp@ankor.co.il
options autosupport.noteto netapp_pager@msil.sps.mot.com options autosupport.from MSIL_NetApp2_Design4 options cifs.home_dir /vol/design4/users options cifs.show_snapshot true options cifs.symlinks.enable on options nfs.per_client_stats.enable on snmp contact 'Eyal Traitel' snmp location 'Herzelya, Israel' snmp community add ro msil_filers snmp traphost add netman snmp init 1 ndmpd on options timed.servers timehost1,timehost2,timehost3 options timed.proto ntp options timed.enable on
******************************************************************************************
Can someone recommend/suggest anything about this rc ?
Eyal.
******************************************************************************************
Mike Mueller wrote:
Thanks for the suggestion, but alas this is also not it. Our F540 has 2 interfaces, one of which is FDDI (which doesn't have the problem) and the other is already set to not negotiate as 100tx-fd along with the switch port. The F740 has 1 interface and is set to autonegotiate, but since it hasn't had the drastic performance problems observed with a duplex mismatch and since the F540 is set to not negotiate this rules out this as a factor.
-- Mike
At 11:17 AM 11/8/99 , G D Geen wrote:
Mike,
I am not familiar with this hub. Be sure to set the port(s) on the hub to a fixed entity, such as 100 Base-T Full Duplex, and then configure the interface of the filer to the same setting using "ifconfig". Having the interface of the filer or the ports on your router auto detecting anything leads to odd results.
-gdg
I've tried this also but no joy. Routed is currently off, since our router doesn't use RIP and I thought that it might be a contributor. I have the static route configured in my rc.
As far as sharing rc files, we consider some of the information contained sensitive, such as the snmp community string and IP address. I would even prefer that the autosupport e-mail sent to NetApp was encrypted...
-- Mike
At 7:59 AM +0200 11/9/99, Eyal Traitel wrote:
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
Eyal.
Maybe we should start sending rc files of each site so we can compare ?
On Tue, 9 Nov 1999, Eyal Traitel wrote:
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
route add net default 223.21.95.254 1
to be exact. Otherwise you're putting in a host route.
Tom
----- Original Message ----- From: tkaczma@gryf.net To: toasters@mathworks.com Sent: Tuesday, November 09, 1999 3:27 PM Subject: Re: Strange routing problem
On Tue, 9 Nov 1999, Eyal Traitel wrote:
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
route add net default 223.21.95.254 1
to be exact. Otherwise you're putting in a host route.
Your default route SHOULD be a host route. To the IP address of the router.
Bruce
On Tue, 9 Nov 1999, Bruce Sterling Woodcock wrote:
Your default route SHOULD be a host route.
That is open to interpretation, I guess. I've used systems that were fussy about this point and did not add a correct route if it was not a network route. It may be system administration through old wives tales, but I haven't run into a system yet where specifying the net option for a default route would not work or break something. I have found systems in which the reverse was true.
BTW, here is the output of route add default on Solaris 2.6:
#route add default 10.10.10.10 10
add net default: gateway 10.10.10.10
(Hmmmmmmmm???)
To the IP address of the router.
You mean "_through_" the IP address of the router.
Tom
At 06:13 PM 11/9/99 , tkaczma@gryf.net wrote:
On Tue, 9 Nov 1999, Bruce Sterling Woodcock wrote:
Your default route SHOULD be a host route.
I somehow missed Bruce's message, but the NetApp only lets me set the default route in one way, and I certainly hope that there are no bugs in their code for doing that. It shows up as a net route, the default is a network, the gateway is a host. Like Tom says for Solaris.
That is open to interpretation, I guess. I've used systems that were fussy about this point and did not add a correct route if it was not a network route. It may be system administration through old wives tales, but I haven't run into a system yet where specifying the net option for a default route would not work or break something. I have found systems in which the reverse was true.
BTW, here is the output of route add default on Solaris 2.6:
#route add default 10.10.10.10 10 add net default: gateway 10.10.10.10(Hmmmmmmmm???)
To the IP address of the router.
You mean "_through_" the IP address of the router.
Tom
I somehow missed Bruce's message, but the NetApp only lets me set the default route in one way, and I certainly hope that there are no bugs in their code for doing that. It shows up as a net route, the default is a network, the gateway is a host. Like Tom says for Solaris.
This is what I meant. I thought someone was implying the default route should be to the entire network (like the broadcast address).
Bruce
On Tue, 9 Nov 1999, Bruce Sterling Woodcock wrote:
This is what I meant. I thought someone was implying the default route should be to the entire network (like the broadcast address).
Not specifying the "net" option seems to work on NACs so there is no issue. In fact, even using the "host" directive works "correctly". I guess NetApp chose to take make it easy for admins.
So, while a lot of us are at LISA, let's talk about something more cheerful.
Laterz; Tom
Bruce Sterling Woodcock wrote:
----- Original Message ----- From: tkaczma@gryf.net To: toasters@mathworks.com Sent: Tuesday, November 09, 1999 3:27 PM Subject: Re: Strange routing problem
On Tue, 9 Nov 1999, Eyal Traitel wrote:
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
route add net default 223.21.95.254 1
to be exact. Otherwise you're putting in a host route.
Your default route SHOULD be a host route. To the IP address of the router.
Nope. The default route is a network route by default. It is not necesary to put in the "net" keyword, the route command knows it is a network route.
# route add default 192.192.192.99 1 add net default: gateway 192.192.192.99 #netstat -rn
Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 127.0.0.1 127.0.0.1 UH 01207122 lo0 192.192.192.0 192.192.192.218 U 3 5180 hme0 224.0.0.0 192.192.192.218 U 3 0 hme0 default 192.192.192.99 UG 0 0
-Steve gremban@ti.com
Bruce
I've been over this a few times in my head, but it still seems like just a naming convention to me. I suppose in the table the default route is recorded as a network, since it is really for more than one address, but when you are specifying the command you're specifying a host, not a network. The fact that some modern systems rewrite this to use the gateway parameter with the net keyword is fine, but the old syntax has always worked, should continue to work, and I do not think will wind up adding a single host route (otherwise the "default" keyword would be being ignored). So I think Tom was wrong on that point. However, I also misread what Tom wrote (due to the different terminology conventions) and thought he was suggesting one would specify a network *parameter*, not a host *parameter*, when specifying a default route. And that's what I was trying to clear up.
Bruce
On Sun, 14 Nov 1999, Bruce Sterling Woodcock wrote:
However, I also misread what Tom wrote (due to the different terminology conventions) and thought he was suggesting one would specify a network *parameter*, not a host *parameter*, when specifying a default route.
That is exactly what I said. You're still misunderstanding it. I think what you should do to convince yourself is to enter a 'route add host default enter.router.ip.here 1' on certain systems and see what wonderous things happen.
Tom
I've been over this a few times in my head, but it still seems like just a naming convention to me. I suppose in the table the default route is recorded as a network, since it is really for more than one address, but when you are specifying the command you're specifying a host, not a network. The fact that some modern systems rewrite this to use the gateway parameter with the net keyword is fine, but the old syntax has always worked, should continue to work, and I do not think will wind up adding a single host route (otherwise the "default" keyword would be being ignored). So I think Tom was wrong on that point. However, I also misread what Tom wrote (due to the different terminology conventions) and thought he was suggesting one would specify a network *parameter*, not a host *parameter*, when specifying a default route. And that's what I was trying to clear up.
Bruce
Thanks.
Already changed, Eyal.
tkaczma@gryf.net wrote:
On Tue, 9 Nov 1999, Eyal Traitel wrote:
I had something a little similar I suspect... Try toggling your RIP by "routed off|on". You should also check that your /etc/rc contains something like:
route add default 223.21.95.254 1
route add net default 223.21.95.254 1
to be exact. Otherwise you're putting in a host route.
Tom
This could be an ARP cache problem. Check to make sure that the ARP cache on your switch has a longer expiration time than the ARP cache on your router.
Tom
On Mon, 8 Nov 1999, Mike Mueller wrote:
We've been having a strange routing problem with our 2 NetApps for the past month or so in which the NetApps cannot ping the Cisco router on their subnet (their default route). We have a F740 running 5.2.3 and a F540 running 5.1.2R2 and both are having this problem. The NetApps can also not ping (or connect with any other IP protocol) other hosts on other subnets. However, if a packet crosses the router to a host that the NetApp previously could not reach, then that host becomes reachable for a while. Other hosts on the same subnet as the NetApps do not have this problem, they can ping the router and other hosts on other subnets. However, the Cisco 2924 switch that the NetApps and other hosts are connected to also shows this same behavior. This has led us to suspect a problem with the Cisco switches or router, but we have pretty much eliminated any hardware problems. We have an interesting bridge-group configuration on the router to allow Sun Autoclients to boot from their server which is 1 hop away, and are also using Cisco Hot Standby Router protocol so it could be a weird interaction of these protocols that is confusing the 2924 switch. Still, why are the NetApps the only hosts that seem the be bothered?
The problem was causing "NFS server not responding" incidents lasting for up to 10+ minutes on our clients that were 1 router hop away from the NetApps until I wrote a script that runs on a Sun that pings all of these clients once a minute. There were no clues in the NetApps' or clients' logs.
Has anyone else ever seen a situation like this where the Netapp could not ping its default router?
Does anyone have any advice about using NFS across routers that can minimize or prevent the pauses that we observe on our clients?
Thank you,
Mike
I've seen the problem too. We run a static default route and no routed. We have Cisco switches and routers. The filer seems to be unavailable for a short while. The host side appears fine. The filer side appears fine. It hasn't happened so that I would notice in a long while.
-Michael Cerda
-
Alex French -
Bruce Sterling Woodcock -
Eyal Traitel -
G D Geen -
Michael Cerda -
Mike Mueller -
Pierre Maubert -
Steve Armijo -
Steve Gremban -
tkaczma＠gryf.net -
Tom McDonald