Date: Wed, 11 Nov 1998 19:45:56 -0800 From: Mike Smith <mike@smith.net.au> To: Alfred Perlstein <bright@hotjobs.com> Cc: Brian Feldman <green@unixhelp.org>, current@FreeBSD.ORG Subject: FreeBSD NFS (was Re: Is it soup yet? FreeBSD NFS) Message-ID: <199811120345.TAA07333@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 11 Nov 1998 22:04:43 EST." <Pine.BSF.4.05.9811112154240.370-100000@porkfriedrice.ny.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> A recent Linux article suggests that Linux NFS will bipass the "mbuf" > layer, ie. the NFS code will directly reassemble packets into RPC requests > thereby saving _one_ copy of memory. This is really neat, but then makes > NFS dependant on the protocols which it is supposed to be independant of. The BSD kernel NFS code already does this; it contains some quite frightening macros which directly manipulate mbuf state. > Btw, Mike Smith's new ACCESS caching seems quite stable and i was > wondering if it had been commited. No, I haven't had time to commit it yet. I've been given a cleaner version by a contributor, and I'm still investigating cases where it's possible that the cached mode should be invalidated. I'd love to hear from anyone that can conclusively confirm that nfsnode structures are *always* obtained via nfs_nget when attached to a new vnode, or when the vnode is retargetted. The cache hit rates that have been reported have me wondering if they're not actually being maintained (in the name cache maybe?) across multiple references to the same file. After my exam tomorrow morning, I hope to be able to clear a few low-overhead tasks such as this from my stack. So far all the feedback I've received has been very positive; the though of reducing wire traffic for an NFS-mounted world build by several hundred MB is quite appealing. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.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?199811120345.TAA07333>