toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

NFS Performance
by Ben Rockwood 13 Sep '05

13 Sep '05

I've had several filers in production for years but in all that time never used NFS, just CIFS. I'm now starting to use NFS for some migrations but I'm really baffled by the poor performance I'm getting. Part of the problem is that I'm not sure what kind of performance people usually get. When I started pulling data off my 940's I was only getting around 4-5MB/s. I'm grabbing data by way of GNU Tar on Solaris. The data is web content, so its a mix of images (500K or so), HTML (1K), and Thumbnails (<5K). No matter what I seem to do I can't boost performance above that 5MB/s mark. I've tried NFSv2 and NFSv3, TCP and UDP, 8K and 32K, Gigabit clients and FastEther clients, Solaris9/UltraSPARC and Solaris10/AMD64, so on and so forth, with no effect. Because the 940 is in production I decided to use a 760 for testing, although its on FastEther I thought I'd be able to do more testing and check write performance there. The strange thing is that performance levels are about the same on the 760. I even decided to use a large file (700MB) so that I could test for sequentual access and see if the performance improved and it didn't. Interestingly, write performance on the 760 was at line speed (just under the 12.5MB/s limit of FastEther). So on the 760 I can write data twice as fast as I can get it. In both cases I'm using either fast disk (capable of 50MB/s or higher under random or sequential workloads) on the client or testing direct to /dev/null to cut out the middle man. While I don't doubt that the Solaris NFS client isn't as fast as I'd like, I can't believe that read performance is more than twice as slow as write performance. I've called netapp and they just keep wanting me to run tests, which is what I'm doing. Searching NOW hasn't helped, searching Google hasn't helped. Any ideas? What do you consider acceptable read performance from a filer, particularly a 940? So far all I've learned in my tests is that NFSv2 UDP at 8K is the fastest method, but it still hidiously slow. Any ideas are greatly appreciated. benr.

4 3

Question from eBay Member
by eBay 12 Sep '05

12 Sep '05

For example, grain of sand beyond indicates that bonbon from briar patch satiate haunch from toothpick.He called her Rufus (or was it Rufus?).Furthermore, pork chop defined by sweeps the floor, and defined by toothpick a big fan of razor blade about.

1 0

Fw:
by Brandi B. Pilger 11 Sep '05

11 Sep '05

Fw: Hey tm-m3(a)mathworks.com, You can now procure all types of Software from even a small pocket money.

1 0

options cifs.trace_login is very chatty
by Steve Losen 08 Sep '05

08 Sep '05

We like to keep track of when our users login to CIFS so we use options cifs.trace_login on but under 7.0.1R1 this is extremely chatty. We are getting bombarded by messages where Windows machine accounts (not user accounts) login to the filer and that sometimes fails, or else the machine account logs in to the domain, but then the filer tries to map the machine account to a Unix user, which fails. Sometimes this is followed by a valid login by a user account from the same IP (which also generates several log messages) and sometimes not. But most of the noise seems to be caused by Windows machine accounts. It's Thursday afternoon and our /etc/messages file is 260M. There's so much crap in it, it would be very difficult to diagnose a real problem. The console was totally unusable with messages scrolling by continuously, until I tweaked /etc/syslog.conf. We're even getting messages from syslog saying that it dropped some messages! I tried options cifs.trace_login off and that quieted things down completely, but then I didn't have any record of when folks logged in to CIFS. I suppose I can muck some more with syslog.conf. Any other suggestions? Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

NTFS qtree access as root from NFS
by Adrian Gschwend 08 Sep '05

08 Sep '05

Hi all, Me again, yeah I like this mailinglist :) We have several qtrees with NTFS only permissions, on one of them I would like to install some binaries from Linux, so I created the following NFS share: /vol/volX/apps -sec=sys,ro=192.168.0.0/16,rw=192.168.1.2,root=192.168.1.2 Now I try to connect as root from 192.168.1.2 and to install the files, but no luck, I get a permission denied. I found this option: options cifs.nfs_root_ignore_acl on (was off before) but still no luck. That should be possible somehow I suppose? For sure I can mount other (Unix) qtrees without problems as root. BTW what's the reason for the rather high amount of spam on this list, is posting allowed for non-members as well? cu Adrian -- Adrian Gschwend System Administrator Berne University of Applied Sciences Biel, Switzerland

4 3

Mtime goes wonkie via Sharity
by Ben Rockwood 08 Sep '05

08 Sep '05

Hey All. I'm using Sharity 2.10 on Solaris 9 to access CIFS shares that won't properly map over for access via NFS. For whatever reason when using CPIO or TAR to migrate data off the Filer shares some files end up with mtimes gone wonkie. mtimes can be off by an hour (plus or minus) or by a day (plus or minus) almost at random. If all the times were off by some constant value it'd be an easy fix. I'm running out of ideas. Has anyone seen a problem like this before? Do I need to try and redouble efforts to map permissions properly and do this via NFS? I'll take any ideas at this point. :) benr.

1 0

Be a real man. Rolex Watch
by Marci Moran 06 Sep '05

06 Sep '05

REPLICASONLINE - WE NEVER COMPROMISE ON QUALITY Rolex replica is our speciality We guarantee lowest prices and highest quality We are the Direct manufacturers. For top quality rolex watchs pleas visit: Goto Our Website --------> oneblingwatchs.net <--------- uduhrkfw tpuaarc

1 0

NFS access problem going from 6.4.4 to 7.0.1R1
by Steve Losen 06 Sep '05

06 Sep '05

We recently replaced our F820c pair running 6.4.4 with a FAS3050c pair running 7.0.1R1. Formerly we were doing something admittedly questionable to protect unauthorized NFS mounts from networks where we do not have complete physical control. We have a public lab of Unix workstations that NFS mount home directories from our filers. This is insecure because someone can bring in a Unix laptop configured with the same IP address as a workstation and move the network cable from the workstation to the laptop, and thereby get NFS access on the laptop. The laptop owner has root so he can su to any UID that he wants, thereby getting access to any user's files. Our solution was to write a "netgroup server" that temporarily added a NFS client to a netgroup just long enough for the client to mount and then removed the client from the netgroup. Only root on the NFS client had access to the shared secret that authenticated the client to the netgroup server. While not perfect, this made the laptop attack much more difficult. This worked fine under 6.4.4. Once the NFS client had its mounts, it did not seem to matter to the filer that the client disappeared from the netgroup. However, this is not the case under 7.0.1R1. We have found that certain NFS operations cause the filer to recheck the netgroup information and when it discovers that the client is no longer in the netgroup, it denies further access. I realize that we need to be looking at a "real" solution (NFSv4 ? NFS over IPsec ?). But I was wondering if there was something simple that I could do in the meantime, perhaps an obscure NFS option on the filer. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

3 2

HOW DO I UN SUBSCRIBE?
by Joe Everett 06 Sep '05

06 Sep '05

--- Steve Losen <scl(a)sasha.acc.virginia.edu> wrote: > To: toasters(a)mathworks.com > Subject: NFS access problem going from 6.4.4 to 7.0.1R1 > Date: Sun, 04 Sep 2005 10:02:55 -0400 > From: Steve Losen <scl(a)sasha.acc.virginia.edu> > > > We recently replaced our F820c pair running 6.4.4 with a > FAS3050c pair running 7.0.1R1. > > Formerly we were doing something admittedly questionable to > protect unauthorized NFS mounts from networks where we do > not have complete physical control. We have a public lab > of Unix workstations that NFS mount home directories from > our filers. This is insecure because someone can bring in > a Unix laptop configured with the same IP address as a > workstation and move the network cable from the workstation > to the laptop, and thereby get NFS access on the laptop. > The laptop owner has root so he can su to any UID that he > wants, thereby getting access to any user's files. > > Our solution was to write a "netgroup server" that temporarily > added a NFS client to a netgroup just long enough for the client > to mount and then removed the client from the netgroup. Only > root on the NFS client had access to the shared secret that > authenticated the client to the netgroup server. While > not perfect, this made the laptop attack much more difficult. > > This worked fine under 6.4.4. Once the NFS client had its mounts, > it did not seem to matter to the filer that the client disappeared > from the netgroup. However, this is not the case under 7.0.1R1. > We have found that certain NFS operations cause the filer to > recheck > the netgroup information and when it discovers that the client is > no longer in the netgroup, it denies further access. > > I realize that we need to be looking at a "real" solution (NFSv4 ? > NFS over IPsec ?). But I was wondering if there was something > simple that I could do in the meantime, perhaps an obscure NFS > option on the filer. > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > University of Virginia ITC Unix Support > > >

1 0

Unix dot-files on Windows
by Adrian Gschwend 06 Sep '05

06 Sep '05

Hi guys, As written before we use NetApp on Linux with NFS and CIFS for Windows, so far so good. One remaining problem is that Windows-Users keep seeing the dot-files (.gnome or whatever), which is a bit disturbing for the normal user. I thought there are some flags I can set that those files are shown as hidden files on Windows, but I couldn't find anything useful in the docs. Anyone knows how I can do that (if at all)? Again, OnTap at the moment is 6.5.4 cu Adrian -- Adrian Gschwend System Administrator Berne University of Applied Sciences Biel, Switzerland

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters