Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Oct 1999 18:38:43 -0600 (MDT)
From:      Lou GLASSY <glassy@caesar.cs.montana.edu>
To:        freebsd-questions@freebsd.org
Subject:   freebsd as a departmental smb/nfs fileserver
Message-ID:  <Pine.NEB.4.05.9910151832470.18231-100000@caesar.cs.montana.edu>

next in thread | raw e-mail | index | archive | help


dear all, hello-

I have a few wonderings about FreeBSD...

   I am a college unix systems administrator.  In the near future,
   one of the departments I work for is planning to get new
   fileserver(s) to replace their current AlphaServer 2100 5/300 running DUX.
   The kind of system I'm recommending will be one or more 
   i386-type systems with lots of memory and disk, and possibly
   multi-cpu if that's wise.

   Because I am familiar with *BSD-type operating systems from an 
   admin point of view, and because my experience to date with 
   the reliability of at least one BSD-derivative (NetBSD), 
   I am advocating we go with a *BSD-based solution for our 
   fileserving needs.  A number of friends at ISPs have used
   both NetBSD and FreeBSD under combat conditions, and have 
   reported very favorably on how these systems perform under load,
   so I am comfortable recommending either.

[1] Is anyone running FreeBSD as a departmental fileserver in a 
    university environment?  The kind of load I'm looking at is 
    pretty modest -- let's say 50 unix systems as nfs clients, 
    and up to 100 windows systems as smb clients, concurrently.
    The kinds of things users do during peak load times are 
    writing code via the familiar edit-compile-bomb-cycle.
    I know about the ftp.cdrom.com setup, and am wondering
    if FreeBSD does fileserving as well as it does ftp serving... :-)

[2] If you do use FreeBSD as a fileserver, is having a second
    CPU advantageous?  If a second CPU is really a win,
    then I can push for the new server box to be a dual cpu unit.

[3] My understanding at the moment is that FreeBSD uses a Big Lock
    to ensure only one kernel thread/CPU combination is active at
    at a time.  Is this correct?  (If it is, then it doesn't seem
    like multiple CPUs really will be that big of a win; if this
    isn't correct, then I have News for the person who told me 
    this... :-)

    Why [2] and [3] are of interest, is that right now, the 
    SMP question is the one visible difference I see that could 
    make FreeBSD a better fit than my other alternative (NetBSD),
    which does not have SMP support at this time.  The primary
    advantages of NetBSD for me, are simply that I've used it 
    for a while, and that I can run NetBSD comfortably on all 
    my current unix client systems (say, 30 AXP + 30 i386 boxes)
    With FreeBSD as a server, I still have to run DUX or something
    else (NetBSD) on my AXP clients.  With NetBSD
    as a server, I can run the same OS on the unix clients + server(s),
    which makes the admin tasks a little more straightforward.


Thanks kindly in advance for any information / perspectives
you can give me-

	lou.

--
Catfish:    I just saved our company $100,000!
Monkey 347: Wow..!  What did you do?
Catfish:    I just went to a site on the web and downloaded a ready-made
            Mission Statement for Megasoft!
347:        (clenching his jaws)  Do you mean the last three weeks of 
            mind-numbing meetings about "Envisioning Our Corporate Future"
            were totally useless?
Catfish:    (smirking)  That's right.  These ones off the web are so good,
            you can't tell them from the real thing!
347:        (HWACK!)  Hey 346, I've got this unconscious catfish in 
            my cubicle.  Will you help me haul him back to the Accounting
            Office?

        -- from "The Adventures of Code Monkey #347"




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.4.05.9910151832470.18231-100000>