Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jan 2000 21:55:59 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Rod Taylor <rod@zort.on.ca>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Thoughts...
Message-ID:  <200001150555.VAA96077@apollo.backplane.com>
References:  <0001150016090H.04098@rbtBSD.intranet> <200001150524.VAA95920@apollo.backplane.com> <0001150041180I.04098@rbtBSD.intranet>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

:Hmm.. My main thoughts for this was the hoarding issue.  As the school would
:like to allow students to 'link up' via laptops and have them synchronized via
:the same mechanism.
:
:Their current solution is to copy a 1.8GB disk image across the network onto
:the drives and use that as a normal local disk.  The copy time takes several
:minutes.  If for some reason 50 people decided to do this at the same time you
:could see where some network lag would come from.

    There are lots of ways of syncing up that do not require sending the 
    entire image over the network every time.  Syncing is something you could
    do with an NFS mount quite easily, combined with something like cpdup
    (see /usr/ports/sysutils/cpdup).

    This way the user maintains everything on their local HD, and syncs-up
    when convenient.

    You can do this with or without a network boot.  It may be more convienient
    to do a network-boot to handle the case where the client's disk is totally
    munged and can't even boot itself.  Alternatively you could network boot
    the kernel and the initial startup and then switch over to the local 
    disk for the bulk of it (once you've determined that the local disk is
    reasonable), but that would mean the client cannot boot on its own 
    without the network.  Or you could provide a 'recovery' floppy that does
    the network boot and if the floppy isn't in the client it boots from
    its local HD.

:The other reason has to do with the laggy network and booting off it.  The
:things not even 10MB switched per station.  8 workstations share 10mbit hubs. 
:Netscape for example would take ages to load over NFS that way.  (Afterall, in
:a class like that they tend to do everything in unison).
:
:Mounting / under NFS on the other hand doesn't appear that it would be trouble.
:It's /usr/local/bin that could use a little local caching.
:...
:Rod Taylor
:Partner of Zort (zort.on.ca)
:--

    Using NFS for /, /usr, and /usr/local/bin over a slow 10BaseT network
    being shared with many other clients is going to depend heavily on the
    amount of memory the laptops have.  NFS is very good at caching binaries
    on the client if the client has sufficient memory.  If the client does not
    have sufficient memory then every time you run a binary it will have 
    to load it from the server.

    The NFS server will need enough memory to cache lots of vnodes in order
    to be able to handle synchronizing scans without eating its disk alive.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?200001150555.VAA96077>