Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: FreeBSD NFS Client, Windows 2003 NFS server

12 views
Skip to first unread message

Harti Brandt

unread,
Dec 7, 2006, 3:15:15 AM12/7/06
to

Hi Warner,

On Wed, 6 Dec 2006, M. Warner Losh wrote:

MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients
MWL>against a Windows 2003 NFS server? What is the performance relative
MWL>to using a FreeBSD NFS server? What is the stability? Does locking
MWL>work? Does the Windows 2003 server have extensions that grok file
MWL>system flags?

I use this regularily (well, -CURRENT). I have no numbers, but performance
is ok. I have the home directories on a W2003k server and it 'feels' fast
enough.

The only problem I see is a lot of 'file server not reponding' and 'file
server up again' (with 2-3 seconds in between). This is usually when
saving a large mail from pine. Linux clients see the same problem, so I
suppose it is a problem on the SFU side. Locking seems to work. Problems
are with filenames that are illegal for NTFS - hosting a 2.11BSD source
tree on a W2003 NFS share does not work because of filenames containing
':' :-). I've not tested what other characters are illegal.

Another problem is that on the NTFS side there is no good way to backup,
copy, whatever the trees, because while NTFS handles Makefile and
makefile, no Windows tool can access both of them. Even worse thinks like
ADSM backup sometimes die with internal errors.

Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools
and cygwin all see different numbers which is rather annoying. The same is
with symbolic links.

The file flags are not supported by the server. There are no extensions
that I know of.

harti
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"

M. Warner Losh

unread,
Dec 7, 2006, 9:30:41 AM12/7/06
to
In message: <2006120709...@knop-beagle.kn.op.dlr.de>
Harti Brandt <hartmut...@dlr.de> writes:
:
: Hi Warner,

:
: On Wed, 6 Dec 2006, M. Warner Losh wrote:
:
: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients
: MWL>against a Windows 2003 NFS server? What is the performance relative
: MWL>to using a FreeBSD NFS server? What is the stability? Does locking
: MWL>work? Does the Windows 2003 server have extensions that grok file
: MWL>system flags?
:
: I use this regularily (well, -CURRENT). I have no numbers, but performance
: is ok. I have the home directories on a W2003k server and it 'feels' fast
: enough.
:
: The only problem I see is a lot of 'file server not reponding' and 'file
: server up again' (with 2-3 seconds in between). This is usually when
: saving a large mail from pine. Linux clients see the same problem, so I
: suppose it is a problem on the SFU side. Locking seems to work. Problems
: are with filenames that are illegal for NTFS - hosting a 2.11BSD source
: tree on a W2003 NFS share does not work because of filenames containing
: ':' :-). I've not tested what other characters are illegal.

This is excellent information. So building a ports tree would be,
ummm, problematic.

: Another problem is that on the NTFS side there is no good way to backup,

: copy, whatever the trees, because while NTFS handles Makefile and
: makefile, no Windows tool can access both of them. Even worse thinks like
: ADSM backup sometimes die with internal errors.

That's good information.

: Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools

: and cygwin all see different numbers which is rather annoying. The same is
: with symbolic links.

Also good information.

: The file flags are not supported by the server. There are no extensions
: that I know of.

This is the one I knew about! The others are far more important :-)

Warner

M. Warner Losh

unread,
Dec 7, 2006, 10:04:45 AM12/7/06
to
In message: <2006120709...@knop-beagle.kn.op.dlr.de>
Harti Brandt <hartmut...@dlr.de> writes:
: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients
: MWL>against a Windows 2003 NFS server? What is the performance relative
: MWL>to using a FreeBSD NFS server? What is the stability? Does locking
: MWL>work? Does the Windows 2003 server have extensions that grok file
: MWL>system flags?
:
: I use this regularily (well, -CURRENT). I have no numbers, but performance
: is ok. I have the home directories on a W2003k server and it 'feels' fast
: enough.

We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but
when we do a full build of our system from scratch it takes 10 hours
over NFS vs 1 hour on a local disk. We're worried that if we were to
try to do heavy NFS traffic to a Win2003 server with SFU this would be
even slower.

: The only problem I see is a lot of 'file server not reponding' and 'file
: server up again' (with 2-3 seconds in between). This is usually when
: saving a large mail from pine. Linux clients see the same problem, so I
: suppose it is a problem on the SFU side.

So building large binaries might be a problem?

: Locking seems to work.

Does "seems to work" mean it really does work, or does SFU just do the
old trick of saying 'ok, your lock worked'?

: Problems

: are with filenames that are illegal for NTFS - hosting a 2.11BSD source
: tree on a W2003 NFS share does not work because of filenames containing
: ':' :-). I've not tested what other characters are illegal.

That would be a problem for hosting a ports tree on the NTFS nfs
partition, no?

: Another problem is that on the NTFS side there is no good way to backup,
: copy, whatever the trees, because while NTFS handles Makefile and
: makefile, no Windows tool can access both of them. Even worse thinks like
: ADSM backup sometimes die with internal errors.

That's ugly.

: Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools
: and cygwin all see different numbers which is rather annoying. The same is
: with symbolic links.

Symblic links point elsewhere? or have different destinations? Does
it matter absolute or relative?

: The file flags are not supported by the server. There are no extensions
: that I know of.

Same problem with FreeBSD to FreeBSD NFS.

Harti Brandt

unread,
Dec 7, 2006, 11:02:33 AM12/7/06
to
On Thu, 7 Dec 2006, M. Warner Losh wrote:

MWL>In message: <2006120709...@knop-beagle.kn.op.dlr.de>
MWL> Harti Brandt <hartmut...@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

Vince

unread,
Dec 7, 2006, 11:04:17 AM12/7/06
to
M. Warner Losh wrote:
> In message: <2006120709...@knop-beagle.kn.op.dlr.de>

> Harti Brandt <hartmut...@dlr.de> writes:
> : MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients
> : MWL>against a Windows 2003 NFS server? What is the performance relative
> : MWL>to using a FreeBSD NFS server? What is the stability? Does locking
> : MWL>work? Does the Windows 2003 server have extensions that grok file
> : MWL>system flags?
> :
> : I use this regularily (well, -CURRENT). I have no numbers, but performance
> : is ok. I have the home directories on a W2003k server and it 'feels' fast
> : enough.

>
> We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but
> when we do a full build of our system from scratch it takes 10 hours
> over NFS vs 1 hour on a local disk. We're worried that if we were to
> try to do heavy NFS traffic to a Win2003 server with SFU this would be
> even slower.

>
> : The only problem I see is a lot of 'file server not reponding' and 'file
> : server up again' (with 2-3 seconds in between). This is usually when
> : saving a large mail from pine. Linux clients see the same problem, so I
> : suppose it is a problem on the SFU side.
>
> So building large binaries might be a problem?
>
> : Locking seems to work.

>
> Does "seems to work" mean it really does work, or does SFU just do the
> old trick of saying 'ok, your lock worked'?
>
> : Problems
> : are with filenames that are illegal for NTFS - hosting a 2.11BSD source
> : tree on a W2003 NFS share does not work because of filenames containing
> : ':' :-). I've not tested what other characters are illegal.
>
> That would be a problem for hosting a ports tree on the NTFS nfs
> partition, no?

>
> : Another problem is that on the NTFS side there is no good way to backup,
> : copy, whatever the trees, because while NTFS handles Makefile and
> : makefile, no Windows tool can access both of them. Even worse thinks like
> : ADSM backup sometimes die with internal errors.
>
> That's ugly.

>
> : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools
> : and cygwin all see different numbers which is rather annoying. The same is
> : with symbolic links.

>
> Symblic links point elsewhere? or have different destinations? Does
> it matter absolute or relative?
>
> : The file flags are not supported by the server. There are no extensions
> : that I know of.

>
> Same problem with FreeBSD to FreeBSD NFS.
>

Just out of interest since cygwin was mentioned, has anyone tried out
the cygwin NFS server rather than the SFU one? If it were combined with
cygwin's "managed mount" mode it should in theory support ':' or other
similar names that are normally illegal on windows, although they
wouldnt be accessible from windows from what i remeber. Also I seem to
remember things were always rather slow when I used to use cygwin, so it
might not be worth it in terms of speed. Sorry if this is getting a
little offtopic.

Vince
> Warner

Bruce Evans

unread,
Dec 7, 2006, 9:31:50 PM12/7/06
to
On Thu, 7 Dec 2006, M. Warner Losh wrote:

> We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but
> when we do a full build of our system from scratch it takes 10 hours
> over NFS vs 1 hour on a local disk.

I have a report that lost dotdot caching seems to be responsible for
most of the enormous slowness of nfs under FreeBSD (for building a
large non-FreeBSD system), but I think this is only one of several
slowness factors, and building things in parallel is an adequate
workaround in all cases that I tried (mainly building kernels and
worlds).

> We're worried that if we were to
> try to do heavy NFS traffic to a Win2003 server with SFU this would be
> even slower.

The slowness in FreeBSD's nfs seems to be mostly in the client (except
network latency is in the network). The client doesn't cache things
very well, so it generates a large number of RPCs so the total latency
= (per-RPC-latency * number-of-RPCs) is enormous if the per-RPC latency
is just large.

Bruce

Harti Brandt

unread,
Dec 8, 2006, 3:23:40 AM12/8/06
to
On Thu, 7 Dec 2006, Harti Brandt wrote:

HB>On Thu, 7 Dec 2006, M. Warner Losh wrote:
HB>
HB>MWL>In message: <2006120709...@knop-beagle.kn.op.dlr.de>
HB>MWL> Harti Brandt <hartmut...@dlr.de> writes:
HB>MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients
HB>MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative
HB>MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking
HB>MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file
HB>MWL>: MWL>system flags?
HB>MWL>:
HB>MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance
HB>MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast
HB>MWL>: enough.
HB>MWL>
HB>MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but
HB>MWL>when we do a full build of our system from scratch it takes 10 hours
HB>MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to
HB>MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be
HB>MWL>even slower.
HB>
HB>Ok. I did a very short test (no time to do much more). Read performance
HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write
HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec.
HB>
HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a
HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30%
HB>(from the antivirus scanner).
HB>
HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a
HB>Gigabit link to test with.
HB>
HB>If you want I could try to do a buildworld.

Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h
on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad.

harti

M. Warner Losh

unread,
Dec 8, 2006, 4:06:50 AM12/8/06
to
In message: <2006120809...@knop-beagle.kn.op.dlr.de>
Harti Brandt <hartmut...@dlr.de> writes:

So we're talking 33% slower here rather than 90% slower that I see for
my entire product build. So the speed is similar to what I've seen
over NFS here...

Warner

Bruce Evans

unread,
Dec 9, 2006, 1:09:58 AM12/9/06
to
On Fri, 8 Dec 2006, Harti Brandt wrote:

> On Thu, 7 Dec 2006, Harti Brandt wrote:

> HB>Ok. I did a very short test (no time to do much more). Read performance
> HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write
> HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec.
> HB>
> HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a
> HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30%
> HB>(from the antivirus scanner).
> HB>
> HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a
> HB>Gigabit link to test with.
> HB>
> HB>If you want I could try to do a buildworld.
>
> Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h
> on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad.

Hmm, with such slow machines, network/nfs latency shouldn't be much of a
problem. Makeworld of a ~5.2 world with a Turion X2 2GHz takes 14:24m here.
About 1m of this time is extra for nfs. It took a bit of work to reduce
the nfs overhead from a few minutes (about 5?) to only 1.

Bruce

0 new messages