Date: Sat, 27 Apr 2002 22:13:17 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Brian Candler <B.Candler@pobox.com> Cc: "Andrew P. Lentvorski" <bsder@allcaps.org>, freebsd-fs@freebsd.org, freebsd-net@freebsd.org Subject: Re: NFS clearing attribute cache in nfs_open Message-ID: <Pine.NEB.3.96L.1020427220257.64976C-100000@fledge.watson.org> In-Reply-To: <20020427152718.A16634@linnet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Apr 2002, Brian Candler wrote: > > If you are really > > into clusters with low-latency, you might want to look into something like > > NFS V4 (Is anybody working on that on FreeBSD, anymore?), AFS, CODA, or > > something more specialized. Those networked filesystems have a > > bidrectional characteristic and cached state protocols so that they can > > minimize communication. > > Will do. For a diskless bootup I think I am restricted to either NFS or > ramdisk for the root filesystem though. > > Is it possible to replace the root filesystem with a different one after > the system has started? The trick I've played in this situation is the one I think you're alluding to with the ramdisk comment above -- I pxeboot a kernel, but have the loader also pull over an mfsroot containing the root filesystem to md/ffs mount. I then mounted other filesystems via NFS. A trick I've played a few times, and I know is popular at certain large web-based providers, is to then pull down the rest of the OS to a local file system at that point, and use that for /usr (etc). Depends how much boot latency you can accept vs. run-time latency. For crash boxes, I tend to lean to the completely-NFS direction, for some other boxes I've used mixed local/mfs/nfs. I tend not to use chroot() to change the rootfs, but I imagine you could do that if you wanted. One important observation is that newfs can be orders of magnitude faster than fsck, and scales much better with disk size. Rather than allow a machine that's pretty stateless to fsck, just rebuild the box. :-) Our pxeboot loader (and normal loader) are incredibly flexible, and make it easy to do a whole ton of different kinds of things. For both experimentation and production service, they can dramatically lower admin costs by making OS roll forward/back and stateless systems a reality. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" 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.3.96L.1020427220257.64976C-100000>