FreeBSD NFS Client, Windows 2003 NFS server

[Harti Brandt]

On Thu, 7 Dec 2006, M. Warner Losh wrote:

MWL>In message: <20061207090026.I17220 at knop-beagle.kn.op.dlr.de>
MWL>            Harti Brandt <hartmut.brandt at 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