From owner-freebsd-current Fri Jan 14 22: 0: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6680214EEC for ; Fri, 14 Jan 2000 21:59:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA96077; Fri, 14 Jan 2000 21:55:59 -0800 (PST) (envelope-from dillon) Date: Fri, 14 Jan 2000 21:55:59 -0800 (PST) From: Matthew Dillon Message-Id: <200001150555.VAA96077@apollo.backplane.com> To: Rod Taylor Cc: freebsd-current@FreeBSD.ORG Subject: Re: Thoughts... References: <0001150016090H.04098@rbtBSD.intranet> <200001150524.VAA95920@apollo.backplane.com> <0001150041180I.04098@rbtBSD.intranet> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message