Just checking to see if anyone else is alive here... ;-) ObInventory: got an F220, getting two F210's and an F230. :)
Brian Tao penned:
Just checking to see if anyone else is alive here... ;-) ObInventory: got an F220, getting two F210's and an F230. :)
Hi Brian,
My F330 was delivered yesterday, and set up today (thanks Jeff West!).
For the folks who've been on the list for a while, our bid process did go through successfully. It's just like Christmas around here, except without the annoying relatives!
Regards,
David K. Drum david@more.net
In enteract.private.lists.toasters, David Drum david@more.net wrote:
Brian Tao penned:
Just checking to see if anyone else is alive here... ;-) ObInventory: got an F220, getting two F210's and an F230. :)
Hi Brian,
My F330 was delivered yesterday, and set up today (thanks Jeff West!).
Me too. :)
After a lengthy negotiation process, we finally have a F230 and a F540. It is amazing how fast these systems can get put into service! We got our F230 last Tuesday and our F540 last Friday.
We use the F230 as a file server for a bunch of FreeBSD machines, and the F540 as the news spool for an UltraSparc 2 reader machine running Solaris 2.5.1 (eventually, we hope, a pool of UltraSparcs, though we are keeping the active and history files on local disk for now). The Ultra will eventually connect directly to the NetApp via full duplex fast Ethernet (until another Ethernet card frees up for the Ultra, there is a switch in between).
I would be very interested to hear from other people using NetApps for news spools for any advice on optimally configuring the NetApp for this purpose.
e.g., no snapshots, increase the number of inodes, no atime update, disable NFS over TCP, ...?
Thanks!
-- Jennifer Dawn Myers, jdm@enteract.com System Administrator, EnterAct, L.L.C. http://www.enteract.com/ Customer Support: 773/248-8511
On Wed, 11 Jun 1997, Jennifer Dawn Myers wrote:
e.g., no snapshots, increase the number of inodes, no atime update, disable NFS over TCP, ...?
We are currently using NFS over TCP for news purposes. Is that a bad thing?
We are currently just using the NetApp box for some binaries groups. Our settings are:
===== OPTIONS ===== autosupport.doit WEEKLY_LOG autosupport.enable on autosupport.mailhost mailhost autosupport.noteto ccaputo@alt.net autosupport.to ccaputo@alt.net autosupport.from autosupport df_2gb_lim off httpd.admin.enable on httpd.enable off httpd.log.max_file_size 2147483647 httpd.rootdir XXX httpd.timeout 900 httpd.timewait.enable off ip.path_mtu_discovery.enable on minra off mount_rootonly on nfs.big_endianize_fileid off nfs.per_client_stats.enable off nfs.tcp.enable on nfs.v3.enable on no_atime_update on nosnap off nosnapdir off pcnfsd.enable off raidtimeout 4294967295 raid.reconstruct_speed 4 raid.scrub.enable on root_only_chown on telnet.hosts * wafl.maxdirsize 10240
===== SNAP-SCHED ===== 0 0 0 0
For security reasons our NetApp is assigned to private address space (10.x.x.x, RFC1918) so it can't been seen from the rest of the net. If you are exposed to the net, you might to do that. Any client machines would also need to be using 10.x.x.x addresses in addition to their normal reachable addresses.
Our raidtimeout is set to max since we don't ever want the machine to stop running, after it loses a disk. We'll just get it a new disk quickly. Having it stop is not an option.
To NetApp - Make these things cheaper so we can buy more. Their really good, but a dollar a meg is too high when the non-raid market is at $0.1 per meg. Also, make it so those extra PCI slots can be used for more SCSI cards, even on the low end machines. When you can't do things like this it really makes the company seem like it is driven by marketing droids obsessed only with competing with Auspex.
Chris
On Wed, 11 Jun 1997, Jennifer Dawn Myers wrote:
e.g., no snapshots, increase the number of inodes, no atime update, disable NFS over TCP, ...?
We are currently using NFS over TCP for news purposes. Is that a bad thing?
Not necessarly. Do you have a reason for needed tcp such as your are doing long haul networking?
However there are a lot of things that can go wrong with tcp that can't with udp (there are lots of very broken tcp implementations in this world: not ours of course:-) I would sugest disabling tcp and see what happens. If things stay the same or get better just leave it that way. If not you had tcp turned on for a reason.
Sean
We are currently just using the NetApp box for some binaries groups. Our settings are:
===== OPTIONS ===== autosupport.doit WEEKLY_LOG autosupport.enable on autosupport.mailhost mailhost autosupport.noteto ccaputo@alt.net autosupport.to ccaputo@alt.net autosupport.from autosupport df_2gb_lim off httpd.admin.enable on httpd.enable off httpd.log.max_file_size 2147483647 httpd.rootdir XXX httpd.timeout 900 httpd.timewait.enable off ip.path_mtu_discovery.enable on minra off mount_rootonly on nfs.big_endianize_fileid off nfs.per_client_stats.enable off nfs.tcp.enable on nfs.v3.enable on no_atime_update on nosnap off nosnapdir off pcnfsd.enable off raidtimeout 4294967295 raid.reconstruct_speed 4 raid.scrub.enable on root_only_chown on telnet.hosts * wafl.maxdirsize 10240
===== SNAP-SCHED ===== 0 0 0 0
For security reasons our NetApp is assigned to private address space (10.x.x.x, RFC1918) so it can't been seen from the rest of the net. If you are exposed to the net, you might to do that. Any client machines would also need to be using 10.x.x.x addresses in addition to their normal reachable addresses.
Our raidtimeout is set to max since we don't ever want the machine to stop running, after it loses a disk. We'll just get it a new disk quickly. Having it stop is not an option.
To NetApp - Make these things cheaper so we can buy more. Their really good, but a dollar a meg is too high when the non-raid market is at $0.1 per meg. Also, make it so those extra PCI slots can be used for more SCSI cards, even on the low end machines. When you can't do things like this it really makes the company seem like it is driven by marketing droids obsessed only with competing with Auspex.
Chris
+--- In our lifetime, sean@netapp.com (Sean W. O'Malley) wrote: | | However there are a lot of things that can go wrong with tcp that can't | with udp (there are lots of very broken tcp implementations in this | world: not ours of course:-) I would sugest disabling tcp and see | what happens. If things stay the same or get better just leave it that | way. If not you had tcp turned on for a reason.
Unless you have Suns. If your Sun runs Solaris 2.5 and up, turn nfs over tcp off, for your sanity.
I turned it off on the netapp as well as forcing the sun's to mount with proto=udp. Just for that extra level of sanity. Having all your boxes stop responding since the NetApp stops "talking" with the Suns is a bad thing.
The boxes rock, aside from that.
Alexei
NFS over TCP might be slower. I have had several customer issues where they were seeing many "NFS Server Not Responding" messages on their client, and remounting via UDP fixed it.
It turns out that most of these customers were on UDP previously, and somehow remounted (via a reboot without appropriate vfstab file) and the TCP default could not handle what the UDP had done.
I also just did a quick "mkfile" test from Sun to Sun. I had a /udp and a /tcp mount. mkfile on 10 meg files was about 5% faster on UDP. That was from a Solaris 2.5.1 client to a Solaris 2.5 server. No Network Appliance file server was involved. You should try this yourself. I simply did "time mkfile 10M foo" each time. The numbers were quite consistent.
I don't have any conclusions from this. Try experimenting with it and note performance differences. Depending on your network, the TCP could be better, but I tend to be skeptical about it, and if a customer can afford UDP over TCP I usually recommend it.
Chris Caputo wrote:
On Wed, 11 Jun 1997, Jennifer Dawn Myers wrote:
e.g., no snapshots, increase the number of inodes, no atime update, disable NFS over TCP, ...?
We are currently using NFS over TCP for news purposes. Is that a bad thing?
We are currently just using the NetApp box for some binaries groups. Our settings are:
===== OPTIONS ===== autosupport.doit WEEKLY_LOG autosupport.enable on autosupport.mailhost mailhost autosupport.noteto ccaputo@alt.net autosupport.to ccaputo@alt.net autosupport.from autosupport df_2gb_lim off httpd.admin.enable on httpd.enable off httpd.log.max_file_size 2147483647 httpd.rootdir XXX httpd.timeout 900 httpd.timewait.enable off ip.path_mtu_discovery.enable on minra off mount_rootonly on nfs.big_endianize_fileid off nfs.per_client_stats.enable off nfs.tcp.enable on nfs.v3.enable on no_atime_update on nosnap off nosnapdir off pcnfsd.enable off raidtimeout 4294967295 raid.reconstruct_speed 4 raid.scrub.enable on root_only_chown on telnet.hosts * wafl.maxdirsize 10240
===== SNAP-SCHED ===== 0 0 0 0
For security reasons our NetApp is assigned to private address space (10.x.x.x, RFC1918) so it can't been seen from the rest of the net. If you are exposed to the net, you might to do that. Any client machines would also need to be using 10.x.x.x addresses in addition to their normal reachable addresses.
Our raidtimeout is set to max since we don't ever want the machine to stop running, after it loses a disk. We'll just get it a new disk quickly. Having it stop is not an option.
To NetApp - Make these things cheaper so we can buy more. Their really good, but a dollar a meg is too high when the non-raid market is at $0.1 per meg. Also, make it so those extra PCI slots can be used for more SCSI cards, even on the low end machines. When you can't do things like this it really makes the company seem like it is driven by marketing droids obsessed only with competing with Auspex.
Chris
+--- In our lifetime, Kenneth Whittaker kenw@netapp.com wrote: | | NFS over TCP might be slower. I have had several customer | issues where they were seeing many "NFS Server Not Responding" | messages on their client, and remounting via UDP fixed it.
Taking the affected interface down and back up sometimes helps. At least for a few minutes.
Isn't the problem rooted in that the NetApp will roll back the tcp sequence number, thus any packets it sends out are discarded by the clients? This is at least the behaviour that I have observed when this has occured, over fddi.
I just want to make sure that the issues are not getting muddled. Speed has nothing to do with the tcp "stopping" issue.
tcp vs udp speed is a whole different ball of wax. If you can guarantee that your network link is reliable, then udp is rather nice. If you have to ensure that the data gets there, then tcp is a better fit.
So far, speed on the NetApp has not become an issue. It simply is blazing.
Alexei
To NetApp - Make these things cheaper so we can buy more. Their really good, but a dollar a meg is too high when the non-raid market is at $0.1 per meg. Also, make it so those extra PCI slots can be used for more SCSI cards, even on the low end machines.
Although marketing certainly has input, the space restrictions also come from engineering droids. During normal operation the smaller machines could certainly handle more disk, but the time required for something like RAID reconstruction could get dangerously long.
It's actually a bit funny, because there have been times when marketing has pushed on engineering to allow larger capacities, but engineers have pushed back because they wanted to tune RAID reconstruction more before allowing letting capacity grow. (I think paranoia is a good thing in an engineer.)
I don't mean to imply that there's no marketing input to the capacities of the different systems, but that's certainly not the whole story!
When you can't do things like this it really makes the company seem like it is driven by marketing droids obsessed only with competing with Auspex.
Hey! It's not just our marketing guys who are obsessed. :-)
Seriously though, I've worked hard to avoid an obsession with Auspex at NetApp, because I don't believe it's healthy. We compete much more often with Sun than with Auspex, since Sun has a much broader product line and a much, much larger market share. I think it would be bad for our customers if Ausepx were our primary focus.
On the other hand, I don't mind being obsessed with competition in general, because I think that's what makes products improve.
Dave "Paranoid and Obsessed" Hitz
-
alexei＠deepthroat.cimedia.com -
Brian Tao -
Chris Caputo -
David Drum -
hitz＠netapp.com -
Jennifer Dawn Myers -
Kenneth Whittaker -
sean＠netapp.com