headers
matthew green | 1 May 2003 03:46
Picon
Favicon

re: nfsd performance?


   i have just the setup, and an ultra1 as the file server, so i may be able
   to run some tests against sol8 or 9. [not sure if those are the best choices
   for ultra1 to compare against netbsd or freebsd, but at least they both come
   with a freeware cd... :)]

it would be useful to know how netbsd performs as an NFS server 
compared to solaris.  solaris NFS server performs pretty well in
my experience...

.mrg.
Permalink | Reply | 4 comments |
headers
Jonathan Stone | 1 May 2003 04:04
Picon

Re: nfsd performance?

>it would be useful to know how netbsd performs as an NFS server 
>compared to solaris.

Depends what solaris is running on and what netbsd is running on.
Many of the `knobs' (tunable or otherwise) on NetBSD (and FreeBSD too)
havent changed since CSRG was running on HP 68030 workstations, or
maybe SS1/decstation3100-vintage risc boxes.  

One day, if I find time, I should write up a list of the tuning I do
when running SpecSFS-like workloads on NetBSD and FreeBSD.  Increasing
ipintrq depth; socket-buffer size; limits on client and server
nfs-helper threads; client-side per-mountpoint readahead; all that
stuff.  (Thanks to Thor Lancelot Simon for pointing some of these
out). I find these make a huge difference when using multiple fast
clients and servers (gig-e, multi-gigahertz CPUs, gigs of memory).

Even so, if you consider multiprocessors, I suspect Solaris has a big
edge for mid- to high-end systems (say, Dell with multiple qlogic
2340s and a rackfull of spindles.)
Permalink | Reply | 1 comment |
headers
matthew green | 1 May 2003 04:45
Picon
Favicon

re: nfsd performance?


   >it would be useful to know how netbsd performs as an NFS server 
   >compared to solaris.

   Depends what solaris is running on and what netbsd is running on.

i agree.  ozan was talking about using an ultra1 which is a slow
machine.  the benefit on NFS server performance here will likely
be effect here than a faster machine that already has lots of
spare CPU to burn...

.mrg.
Permalink | Reply | 0 comments |
headers
Wojciech Puchar | 1 May 2003 09:04

re: nfsd performance?

>
> it would be useful to know how netbsd performs as an NFS server
> compared to solaris.  solaris NFS server performs pretty well in
> my experience...
>
i know only linux and NetBSD nfs..

and the latter performs excellent, especially after last patch for page
loaning (full 100Mbps on pentium 133 with IDE disk)
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 1 May 2003 13:57
Picon

Re: nfsd page loaning

> > i made a patch to make nfsd use page-loaning for READ requests.
> > can anyone please review it?
> > (it includes a fix to make UBC pay attention for loaned pages.)

if no one objects, i'll commit this next weekend.

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 1 May 2003 14:17
Picon

STT_NOTYPE

hi,

after ksyms changes, ddb shows weird backtrace for me
because ksyms_getname skips symbols with STT_NOTYPE like Xintr_legacy1.
i don't know what STT_NOTYPE is, though..

YAMAMOTO Takashi
Permalink | Reply | 1 comment |
headers
YAMAMOTO Takashi | 1 May 2003 16:27
Picon

Re: nfs vs pagedaemon

> > > the change you checked in isn't quite correct, though.
> > > if someone does a physio write (via vnd) to an NFS file from a mapping of
> > > the same file at a different offset, you'd set PG_NEEDCOMMMIT on the
> > > pages from the mapping instead of the pages for the range being modified
> > > (which might not even exist on the client).
> > 
> > i see.  so, adding check of pg->offset is enough?
> 
> it looks like that would take care of it, yea.
> (and on second thought, physio would take a different path and avoid
> any problem here, but writes via a vnd block device would still need this.)

physio via /dev/drum has the same problem, hasn't it?

> it would be easier to tell that the nfs_strategy() code is correct if it were
> told more explicitly when it's ok to use the commit mechanism, though.

do you think that B_PAGEIO can be useful for something other than nfs?
if not, isn't it better to push such knowledges into nfs itsself?

YAMAMOTO Takashi
Permalink | Reply | 1 comment |
headers
Matt Thomas | 1 May 2003 17:18

Re: STT_NOTYPE

At 05:17 AM 5/1/2003, you wrote:
>hi,
>
>after ksyms changes, ddb shows weird backtrace for me
>because ksyms_getname skips symbols with STT_NOTYPE like Xintr_legacy1.
>i don't know what STT_NOTYPE is, though..

Symbols that didn't have a

.type foo, <at> function

in the assembly file.  I'd suggest adding those...

--

-- 
Matt Thomas               Internet:   matt <at> 3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message
Permalink | Reply | 0 comments |
headers
ozan s. yigit | 1 May 2003 17:38
Picon

Re: nfsd performance?


| >it would be useful to know how netbsd performs as an NFS server 
| >compared to solaris.
| 
| Depends what solaris is running on and what netbsd is running on.

both on ultra1. for a number of reasons (huge disk array, both 4+8mm drives)
it is the best box i have for a file server. it will do nothing but nfs.

oz
Permalink | Reply | 0 comments |
headers
David Laight | 1 May 2003 18:48
Picon

should readdisklabel be changed to return 'const char *'?

The prototype of readdisklabel() is currently:
(in sys/disklabel.h)

char *readdisklabel(dev_t, void (*)(struct buf *),
            struct disklabel *, struct cpu_disklabel *);

However since almost all the returned strings are literals
it should really be:

const char *readdisklabel(dev_t, void (*)(struct buf *),
            struct disklabel *, struct cpu_disklabel *);

Any objections to me committing this?
(yes, it affects a whole shedload of files..)

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 5 comments |

Gmane