Date: Wed, 20 Mar 1996 10:12:36 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, amigus@cs.mun.ca, questions@freebsd.org Subject: Re: Diskless FreeBSD Message-ID: <199603192342.KAA02833@genesis.atrad.adelaide.edu.au> In-Reply-To: <199603192308.QAA25141@phaeton.artisoft.com> from "Terry Lambert" at Mar 19, 96 04:08:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > > I don't know _why_, I suspect that the NFS swap code doesn't/won't/can't > > extend the file, but I haven't been bothered enough by it to try to find out. > > How can an NFS client know whether the server is zero-filling the > pages or not? Huh? The NFS swapfile, in the eyes of the NFS server, is just a file that some client is scribbling all over. It's nothing special. The problem is just that if the file isn't as big as the client expects it to be, for some reason the client dies. Zero-filling here is a total non-sequiter. > Typically, I'd say it can't extend the file because, like mmap, the > vnode/extent used for cache mapping images (even for swap files) > references the length from the mapping structure, not from the in > core vnode. In other words, the kernel is told (via the config file) that it has a 20M swap arena, but the map to the swapfile to back that arena is flawed because the extent for the file is constrained to the size of the file itself. Makes sense I gues. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603192342.KAA02833>