Date: Thu, 7 Dec 2006 16:53:58 +0100 (CET) From: Harti Brandt <hartmut.brandt@dlr.de> To: "M. Warner Losh" <imp@bsdimp.com> Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server Message-ID: <20061207163626.N17220@knop-beagle.kn.op.dlr.de> In-Reply-To: <20061207.080007.1720215207.imp@bsdimp.com> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Dec 2006, M. Warner Losh wrote: MWL>In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> MWL> Harti Brandt <hartmut.brandt@dlr.de> writes: MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file MWL>: MWL>system flags? MWL>: MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast MWL>: enough. MWL> MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but MWL>when we do a full build of our system from scratch it takes 10 hours MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be MWL>even slower. Ok. I did a very short test (no time to do much more). Read performance with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. Client is something around 1GHz with a 100Mbps link. Fileserver is a double proc Xeon with a 1Gbps link. The Server has a load of around 30% (from the antivirus scanner). 72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a Gigabit link to test with. If you want I could try to do a buildworld. MWL>: The only problem I see is a lot of 'file server not reponding' and 'file MWL>: server up again' (with 2-3 seconds in between). This is usually when MWL>: saving a large mail from pine. Linux clients see the same problem, so I MWL>: suppose it is a problem on the SFU side. MWL> MWL>So building large binaries might be a problem? Hmm. I just discovered, that these messages are gone since approx. two weeks. No idea why! MWL> MWL>: Locking seems to work. MWL> MWL>Does "seems to work" mean it really does work, or does SFU just do the MWL>old trick of saying 'ok, your lock worked'? I just did the following test: tty0 # lockf /nfs/foo sleep 100 tty1 # lockf /nfs/foo sh -c 'while true ; do echo -n '.' ; sleep 1 ; done' When I interrupt the lockf on tty0 with ^C, the process on tty1 starts to print dots. So I suppose it actually works. MWL> MWL>: Problems MWL>: are with filenames that are illegal for NTFS - hosting a 2.11BSD source MWL>: tree on a W2003 NFS share does not work because of filenames containing MWL>: ':' :-). I've not tested what other characters are illegal. MWL> MWL>That would be a problem for hosting a ports tree on the NTFS nfs MWL>partition, no? I suppose so. Interestinly enough the SFU documentation says, that these file names are actually allowed, so this seems like a bug. MWL>: Another problem is that on the NTFS side there is no good way to backup, MWL>: copy, whatever the trees, because while NTFS handles Makefile and MWL>: makefile, no Windows tool can access both of them. Even worse thinks like MWL>: ADSM backup sometimes die with internal errors. MWL> MWL>That's ugly. Yes. While NTFS can handle lower/uppercase, the access layer between NTFS and applications make 'a'=='A'. My plan here is to mount the NFS share on a UNIX host and make the backups from there. MWL>: Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools MWL>: and cygwin all see different numbers which is rather annoying. The same is MWL>: with symbolic links. MWL> MWL>Symblic links point elsewhere? or have different destinations? Does MWL>it matter absolute or relative? NTFS has no symbolic links, so they are implemented above in the application layer (SFU or the cygwin libraries). Obviously everybody implements them differently. So if you create a symbolic link on the NFS share. Then cygwin on the server just sees a short data file. MWL>: The file flags are not supported by the server. There are no extensions MWL>: that I know of. MWL> MWL>Same problem with FreeBSD to FreeBSD NFS. harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061207163626.N17220>