From owner-freebsd-current Wed Nov 11 21:14:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA25655 for freebsd-current-outgoing; Wed, 11 Nov 1998 21:14:40 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles205.castles.com [208.214.165.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA25650 for ; Wed, 11 Nov 1998 21:14:38 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id TAA07333; Wed, 11 Nov 1998 19:45:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811120345.TAA07333@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alfred Perlstein cc: Brian Feldman , current@FreeBSD.ORG Subject: FreeBSD NFS (was Re: Is it soup yet? FreeBSD NFS) In-reply-to: Your message of "Wed, 11 Nov 1998 22:04:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Nov 1998 19:45:56 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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