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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001150555.VAA96077>