Date: Fri, 14 Dec 2001 22:17:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: current@freebsd.org Subject: Re: mountd(8) leaving filesystems exported Message-ID: <3C1AEB07.5FE66AD7@mindspring.com> References: <200112150034.aa63895@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Dowse wrote: > > There are quite a few assumptions in mountd(8) about the layout of > the per-filesystem mount(2) `data' struct, which make the code quite > ugly. It uses a union to ensure that it supplies a large enough > structure to mount(2), but regardless of the filesystem type, it > always initialises the UFS version. > > One nasty bug is that the code for un-exporting filesystems checks > to see if the filesystem is among a list of supported types, but > the code for exporting doesn't. This list of supported filesystems > does not include ext2fs or hpfs, so you can successfully export > these filesystems, but they remain exported even when the /etc/exports > entry is removed and mountd is restarted or sent a SIGHUP, and no > errors are logged... > > The patch below should address this issue by checking the same list > of filesystems in both cases, and adding ext2fs and hpfs to the > filesystem list. It also avoids the need to assume that all xxx_args > have the export_args in the same place by storing the offsets in a > table. I am aware that there is work ongoing in the area of mount(2), > so maybe the patch is overkill at this time. Any comments? This is actually the wrong way to go about this. The problem is that the exported FSs exports are managed in the per FS mount code, and they really ought to be managed in higher level code (above the VFS layer, but still in the kernel). This is incidently what prevents us from having a SunOS-like "exportfs" command to manipulate export lists on the fly, without having to bounce things up and down. To fix this would probably require adding a new system call, or adding a mux entry to an existing multiplex system call. The real problem here is that network exportability should not be an attribute of the FS, but it is, due to the confusion over root vs. non-root mounts. The same argument could be used to justify moving the mount point overlay to higher level code, and, internally to each FS, treating everything as a "root" mount. To do this would mean making the mounted FS list entry, and passing it to the mount, and then adding a seperate VFSOP to record the "last mounted on" location for FSs which cared. Then all the common mount overlay code could be factored out, and all FSs then become capable of being used as root FSs, rather than needing special case code. I was really dissatisfied with the factoring out of the root vs. non-root mounts using the "NULL valued pointer" to detect a root mount in the FFS code, but I never got to complete the work that I started in that area (I'm the one who did that work originaly). -- Terry 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?3C1AEB07.5FE66AD7>