From owner-freebsd-hackers Sun May 10 17:07:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA01513 for freebsd-hackers-outgoing; Sun, 10 May 1998 17:07:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01453; Sun, 10 May 1998 17:06:56 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA00372; Sun, 10 May 1998 17:06:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd000351; Sun May 10 17:06:35 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA29608; Sun, 10 May 1998 17:06:35 -0700 (MST) From: Terry Lambert Message-Id: <199805110006.RAA29608@usr05.primenet.com> Subject: Re: exporting an MFS partion? Anyone? To: gurney_j@resnet.uoregon.edu Date: Mon, 11 May 1998 00:06:35 +0000 (GMT) Cc: dyson@FreeBSD.ORG, luigi@labinfo.iet.unipi.it, jwd@unx.sas.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19980510021714.59821@hydrogen.nike.efn.org> from "John-Mark Gurney" at May 10, 98 02:17:14 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ok, another kernel option that we need to document in LINT... so far > I have: > PCI_QUIET > NO_SCSI_SENSE > EXPORTMFS This last should be non-optional. The real problem with this specific case is that the NFS export handling code is implemented per FS. This has to do with the split root/non-root mount model, if you trace it down. What is needed is: o short term make the "EXPORTMFS" non-optional o long term Use the same export (and mount) code in each FS. Specifically, the mount code needs to lose all knowledge of whether or not the mount is a root or non-root mount. A VFS_MOUNT should result in a populated mount structure *without* any "covered vnode" mapping whatsoever. The vnode "covering" (ie: the act of mounting an FS onto a mount point) should be in common code, above the VFS layer, which deals with vnode pointer manipulations. Note: the mount point traversal code is already in the upper level code in namei(). The covering, at the time a covering occurs, is then responsible for doing the NFS export. That is, it is in the upper level mapping code. The last remaining piece is a VFS_SETMP() VFS OP to set the "last mounted on" field in the superblock of FS's that support the concept. This is also called from the covering code. Common code means that everything works or nothing works; once one thing works, then everything works, and everything is maintained in sync. for the rest of time (fewer per-FS issues, fewer places for bugs to hide). There should probably be a seperation of the idea of a remount into a seperate unmount/mount, and put that at the upper level, as well. This would let soft updates become a mount option that can be specified with a "mount -u", for example. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message