Date: Fri, 15 Oct 2004 15:29:23 +0100 From: Peter Edwards <peadar.edwards@gmail.com> To: David Malone <dwmalone@maths.tcd.ie> Cc: Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: NFS + VM question Message-ID: <34cb7c8404101507297970e8dc@mail.gmail.com> In-Reply-To: <20041015124948.GA66898@walton.maths.tcd.ie> References: <200410141427.i9EERcTF056740@lurza.secnetix.de> <20041015124948.GA66898@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Oct 2004 13:49:48 +0100, David Malone <dwmalone@maths.tcd.ie> wrote: > On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > > On the other hand, the kernel should know that the mounts > > come from the same NFS source, so it might actually be able > > to handle it efficiently (i.e. share). But I really don't > > know. Any FreeBSD kernel hacker can enlighten me? > > Since the server could actually hand out different content depending > on the mount instance, I don't think the NFS client could make these > assumptions. If you try NFS mounting /usr a few times and then time > how long it takes to cat a cached file, you'll see this. > Maybe I'm missing something, but I'm not convinced that's true. NFS is "file-handle" centric: there's no real concept of a "mount point" at the server: the mount operation just gives you a handle to the root directory, so if the two mounts from a server give the same file handles to a client, then the results should be consistent. I'd go so far as to say It's even more general than that: a client mounting two different points of the server's filesystem locally could share filehandles if the server's directories intersected (or one was a proper subset of the other, which is more likely) This makes sense, given NFS's statelessness. Of course, given the way the _client_ filesystem code works, it's not going to take advantange of that particular quirk. It's almost certainly not worth doing it at this layer anyhow. (Having two local filesystems trying to share one vnode would be, em, awkward) > > If the memory isn't shared in this situation, is there a > > way to change the design so it can be shared? chroot and > > NFS are "musts", though. > > I don't think there is an easy way to get this caching to happen, > short of using hard links or some kind of union mount instead of > NFS. > "nullfs" sounds like just the job here. ie, mount the NFS filesystem once, then use nullfs to graft it into each chroot area: mount host:/usr /mnt mount -tnullfs /mnt /jail/1 mount -tnullfs /mnt /jail/2 Of course, there's more overhead than if you weren't using the extra nullfs layer, but the caching works as you want.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c8404101507297970e8dc>