NetBSD Problem Report #698
From gnats Wed Jan 4 15:09:34 1995
Received: from pain.lcs.mit.edu (pain.lcs.mit.edu [128.52.46.239]) by sun-lamp.cs.berkeley.edu (8.6.9/8.6.9) with ESMTP id PAA02856 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Wed, 4 Jan 1995 15:09:33 -0800
Message-Id: <199501050004.LAA27386@bilbo.dn.itg.telecom.com.au>
Date: Thu, 5 Jan 1995 11:04:54 +1100
From: sjg@zen.void.oz.au
Reply-To: sjg@netbsd.org
To: gnats-bugs@NetBSD.ORG
Subject: /sbin/umount should support umount_*
X-Send-Pr-Version: 3.2
>Number: 698
>Category: bin
>Synopsis: mount uses mount_* for external fs types, umount should too.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: darcy
>State: closed
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Jan 04 15:20:03 +0000 1995
>Closed-Date: Sun Jun 26 06:46:54 +0000 2016
>Last-Modified: Wed Jul 06 18:50:01 +0000 2016
>Originator: Simon J. Gerraty
>Release: 1.0
>Organization:
Zen Programming....
>Environment:
System: NetBSD bilbo.dn.itg.telecom.com.au 1.0 NetBSD 1.0 (FIREWALL) #5: Tue Dec 20 15:31:28 EST 1994 root@bilbo.dn.itg.telecom.com.au:/src/sys/arch/i386/compile/FIREWALL i386
>Description:
When implementing a new remote filesystem type, the mount_<type> facility
supported by /sbin/mount is extremely useful.
However, it would be even better if /sbin/umount provided the same feature.
I note that SunOS's /usr/etc/umount appears to have this facility.
I can certainly add the functionality to umount if you like.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed
State-Changed-By: cgd
State-Changed-When: Wed Jul 12 02:25:52 EDT 1995
State-Changed-Why:
analyzed.
the same statement is true of:
newfs (!! should take a -t to determine type, pass all args on,
default to type == ffs if no -t given. probably safe
to require that 't' should be first arg. maybe 'T'
for compatibility with current arguments?)
fsck (top-level program should parse fstab, be responsponsible
for picking file systems to check (i.e. pass number stuff),
and farmint out responsibilities to per-fs programs;
current fsck should be fsck_ffs.)
dumpfs (same comments as newfs, mostly, i think.)
additionally, dump and restore should have equivalents for other file systems,
as should clri and tunefs, and the current programs should be renamed to
reflect their FFS-ness.
Responsible-Changed-From-To: bin-bug-people->cgd
Responsible-Changed-By: cgd
Responsible-Changed-When: Wed Jul 12 02:25:52 EDT 1995
Responsible-Changed-Why:
"mybug!"
Responsible-Changed-From-To: cgd->bin-bug-people
Responsible-Changed-By: cgd
Responsible-Changed-When: Sat Aug 19 05:55:17 EDT 1995
Responsible-Changed-Why:
unclaim.
State-Changed-From-To: analyzed->feedback
State-Changed-By: fair
State-Changed-When: Thu Mar 11 02:48:55 PST 1999
State-Changed-Why:
what other things are required for an unmount besides calling the syscall?
Given that some of the items in here have been acted upon, but most haven't
in the four years this PR has been open, I'd say this issue was not pressing
enough to warrant action. Unless feedback arrives to the contrary, this PR
should be closed.
From: "Simon J. Gerraty" <sjg@quick.com.au>
To: gnats-bugs@netbsd.org, gnats-admin@netbsd.org
Cc: sjg@quick.com.au, fair@netbsd.org
Subject: Re: bin/698
Date: Sun, 06 Jun 1999 23:44:18 +1000
Is it perhaps the case that feedback should be sent to gnats-bugs
rather than gnats-admin? If so, the fact that mail requesting
feedback includes gnats-admin but not gnats-bugs in the cc or reply-to
list should be considered a bug.
Clarification either way would be handy.
--sjg
> Date: Sun, 06 Jun 1999 23:35:44 +1000
> From: "Simon J. Gerraty" <sjg@zen.quick.com.au>
>
> I have no idea why the following does not appear in the records for
> this PR - I'm beginig to think that much of the feedback I've sent
> over the years has landed in the bit bucket.
>
> --sjg
> ------- Forwarded Message
>
> Delivery-Date: Mon, 15 Mar 1999 00:55:34 +1100
> Received: (from uucp@localhost) by zen.quick.com.au (8.8.8/8.7.3) id AAA11087; Mon, 15 Mar 1999 00:55:33 +1100 (EST)
> Message-Id: <199903141355.AAA11087@zen.quick.com.au>
> Received: from localhost(127.0.0.1), claiming to be "zen.quick.com.au"
> via SMTP by localhost, id smtpd11083a; Sun Mar 14 05:55:26 1999
> To: fair@netbsd.org
> cc: sjg, gnats-admin@netbsd.org
> Subject: Re: bin/698
> In-reply-to: Your message of "11 Mar 99 10:51:46 -0000."
> <19990311105146.21958.qmail@mail.netbsd.org>
Date: Mon, 22 Nov 1999 00:53:30 -0800
From: "Erik E. Fair" <fair@clock.org>
To: "Simon J. Gerraty" <sjg@quick.com.au>
Cc: gnats-bugs@netbsd.org
Subject: 698
Yes, in order to have feedback automatically recorded in a PR, one
puts the PR number in the subject of a message, and the message must
be sent to gnats-bugs@netbsd.org
gnats-admin@netbsd.org is nominally read by a human or three, but it
gets the *full* transaction set of all GNATS PRs, and as such, it is
difficult for a human to reliably determine if a particular letter
has been recorded in a particular PR or not.
So, w.r.t. PR 698, why should there be an
umount_{ffs,nfs,null,union,etc}, other than symmetry with mount? What
does there need to be done to unmount any of the filesystem that we
now support, besides calling unmount(2)?
curious,
Erik <fair@clock.org>
P.S. please reply to gnats-bugs@netbsd.org.
Date: Tue, 23 Nov 1999 01:56:21 +1100
From: "Simon J. Gerraty" <sjg@quick.com.au>
To: gnats-bugs@netbsd.org
Cc: fair@clock.org, sjg@quick.com.au, tech-kern@netbsd.org
Subject: Re: PR 698
[cc'd tech-kern in case anyone has any better ideas]
> So, w.r.t. PR 698, why should there be an
> umount_{ffs,nfs,null,union,etc}, other than symmetry with mount? What
> does there need to be done to unmount any of the filesystem that we
> now support, besides calling unmount(2)?
Firstly umount_* need only exist if there is something meaningful for
it to do. Take snfs as an example (http://www.quick.com.au/Products/sNFS.html)
This filesystem implements NFS over SSL. The client snfsc does the
talking to the remote machine and tells the kernel to mount an "NFS" fs
using a handle that points at its own socket. This is a pretty
standard way of implementing "interesting" filesystems without need
for the client OS to support anything but NFS over udp.
In the case of snfs there is no portmap involved - snfsd runs
under inetd and won't grok anything that does not arrive over the
encrypted channel.
This means that on NetBSD, while you can arrange for mount /foo to
work - by invoking mount_snfs, umount /foo will _not_ work as the only
thing the kernel knows about is an NFS mount, and umount(8) because it
"knows" NFS, attempts to send an MOUNTPROC_UMNT rpc to the server -
which is doomed to fail.
On systems like SunOS, Solaris etc which record the mount options
somewhere outside the kernel and will invoke umount_snfs things work
much better.
I understand why NetBSD stores the stuff in the kernel and agree that
it is better. But we still lose due to the lack of info stored. On
NetBSD you simply find the pid of the snfsc process and kill it -
shuts down the connection to the server and then dags around until it
can extricate itself from the kernel. It would be wonderful if all
umount(2)'s took an option to say - "for heaven sake, no further
operations are going to work so just forget about this mount point!"
:-)
I don't claim to know what the correct solution is btw but
one approach I thought of was to add a couple of fields to struct
statfs. Hmm I see that f_fstypename[] is already there (its been some
years since I looked), which may be part of what I want, but I can't
find where the values for f_type are defined - which I presume is what
the kernel cares about?
Ie. if f_type were set to indicate NFS and f_fstypename could be set
to indicate the real fs type, then the correct umount_foo could be
found. If that is not the correct use of those fields, then perhaps a
new field is needed.
If we also had say f_mntopts[MNAMELEN] to record the mount options
needed to ensure that umount_foo could do its thing (just the snfsc
pid would do for umount_snfs) then we'd be in business. Note that the
content of f_mntopts[] need only be meaningful to umount_foo.
Of course one then needs a means of getting the extra info into the
kernel.
We'd need to either:
1. add an extra arg to mount(2) which could be null.
2. add a struct statfs* (which could be null) to struct nfs_args etc.
3. make the arg passed to mount(2) something like:
struct dummyfs_args {
struct statfs *sfs;
void *data; /* the real data for sfs->f_type */
};
there may well be a better option that I've not thought of.
I'd expect that each of the above has disadvantages.
Hope that helps.
--sjg
Date: Mon, 22 Nov 1999 10:03:21 -0500
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: "Simon J. Gerraty" <sjg@quick.com.au>
Cc: gnats-bugs@netbsd.org, fair@clock.org, tech-kern@netbsd.org
Subject: Re: PR 698
> It would be wonderful if all umount(2)'s took an option to say -
> "for heaven sake, no further operations are going to work so just
> forget about this mount point!" :-)
You mean, like umount -f / MNT_FORCE?
Note that MNT_FORCE has been buggy in the past; I've done a fair bit
of work to clean it up, but i'm willing to believe that there are some
bugs lingering.
- Bill
Date: Tue, 23 Nov 1999 02:09:25 +1100
From: "Simon J. Gerraty" <sjg@quick.com.au>
To: sommerfeld@orchard.arlington.ma.us
Cc: gnats-bugs@netbsd.org, fair@clock.org, tech-kern@netbsd.org
Subject: Re: PR 698
> > It would be wonderful if all umount(2)'s took an option to say -
> > "for heaven sake, no further operations are going to work so just
> > forget about this mount point!" :-)
>
> You mean, like umount -f / MNT_FORCE?
Yes. I dearly wish Solaris had that :-)
--sjg
State-Changed-From-To: feedback->suspended
State-Changed-By: sjg
State-Changed-When: Sat Feb 5 19:01:06 PST 2000
State-Changed-Why:
I think I know what needs to be done to address this - but
won't have any time to work on it for quite a while.
Responsible-Changed-From-To: bin-bug-people->sjg
Responsible-Changed-By: sjg
Responsible-Changed-When: Sat Feb 5 19:01:06 PST 2000
Responsible-Changed-Why:
I might as well fix it myself.
State-Changed-From-To: suspended->feedback
State-Changed-By: darcy
State-Changed-When: Sun Feb 16 11:34:29 PST 2003
State-Changed-Why:
This has been around for over 8 years. I think that either someone should
submit the required changes or we should just close this. Another can always
be reopened when there is actual code available.
From: "Greg A. Woods" <woods@weird.com>
To: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
gnats-admin@gnats.netbsd.org
Cc: darcy@netbsd.org, Mail/@proven.weird.com
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 01:07:26 -0500 (EST)
D'Arcy wrote in feedback:
> This has been around for over 8 years. I think that either someone
> should submit the required changes or we should just close this.
> Another can always be reopened when there is actual code available.
That reasoning is both bogus and dangerous.
No bug report should ever be closed just because there's no code to fix
it available. The whole point of a bug report like this is to remind
someone to write the code in the first place! Please don't go closing
bug reports without doing anything about them just to get rid of old PRs
-- there is no valid rationale for that whatsoever. There's nothing bad
about old PRs sitting open when they still need eventual attention,
especially not in a volunteer project.
If what you meant to say was that you didn't think this PR is valid then
say that instead.
(Personally I think this PR is quite valid, and BTW, I also think it's
best to put this info in the kernel and once upon a time I even had some
stuff written up about something like this for SySvR4 but I seem to have
lost it.)
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
From: "D'Arcy J.M. Cain" <darcy@NetBSD.org>
To: "Greg A. Woods" <woods@planix.com>,
gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
"Greg A. Woods" <woods@weird.com>, gnats-admin@gnats.netbsd.org
Cc:
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 07:59:06 -0500
I don't think I was actually saying that they should be closed just because
they are old. That's why out of 10 from 1995 that I started with 9 are still
open. What I do want, though, is to stimulate discussion. Nothing is going
to be closed unless it is either dealt with or there is a concensus that the
issue no longer (or never did) exists.
--
D'Arcy J.M. Cain <darcy@netbsd.org>
http://www.NetBSD.org/
From: "Greg A. Woods" <woods@weird.com>
To: darcy@NetBSD.org
Cc: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
gnats-admin@gnats.netbsd.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 14:04:12 -0500 (EST)
[ On Wednesday, February 26, 2003 at 07:59:06 (-0500), D'Arcy J.M. Cain wrote: ]
> Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
>
> I don't think I was actually saying that they should be closed just because
> they are old. That's why out of 10 from 1995 that I started with 9 are still
> open. What I do want, though, is to stimulate discussion. Nothing is going
> to be closed unless it is either dealt with or there is a concensus that the
> issue no longer (or never did) exists.
Good! OK, I'm glad we're on the same page about that! :-)
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
Responsible-Changed-From-To: sjg->darcy
Responsible-Changed-By: darcy
Responsible-Changed-When: Thu Mar 13 13:40:34 PST 2003
Responsible-Changed-Why:
Further to discussions on developers, I am taking responsibility for
making sure that this PR gets closed.
State-Changed-From-To: feedback->open
State-Changed-By: perry
State-Changed-When: Thu Apr 3 17:50:12 PST 2003
State-Changed-Why:
Since we are not currently awaiting feedback from the submitter,
it is more properly listed as "open".
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
too.
Date: Sun, 26 Jun 2016 05:59:55 +0000
Apparently commits don't forward to PRs below 10000 any more (to try
to reduce accidents, which is reasonable, but annoying in this case...)
------
From: "David A. Holland" <dholland@netbsd.org>
To: source-changes@NetBSD.org
Subject: CVS commit: src/sbin/umount
Date: Sun, 26 Jun 2016 03:40:39 +0000
Mail-Followup-To: source-changes-d@NetBSD.org
Module Name: src
Committed By: dholland
Date: Sun Jun 26 03:40:39 UTC 2016
Modified Files:
src/sbin/umount: umount.c
Log Message:
If an external unmount program of the form "umount_TYPE" exists
(e.g. umount_ffs, umount_nfs, etc.) exec it instead of calling
unmount(2).
Closes PR 698.
Note that the original plan for the PR also involved adding a generic
facility to store an alternate FS type name in the kernel to use when
unmounting. This was intended to support filesystems implemented as
loopback nfs servers, where the visible mount would be of type "nfs"
pointing at localhost; in that case one would want to be able to
provide an additional string in order to run an unmount program that
would both remove that mount and also shut down the loopback nfs
server daemon.
However, in the 21+ years since the PR was filed, loopback nfs servers
have gone out of favor (for good reasons) so I don't see any need to
worry about this case at present, especially since the PR has been
hanging around this long anyway. (If anyone still has a loopback nfs
server that they want to use a custom unmount program with, file a new
PR and assign it to me and I'll deal with it specifically in the nfs
mount args structure, which unmount already knows how to retrieve and
examine.)
It is my understanding that filesystems implemented with fuse (which
has displaced the loopback nfs server model) can already set the FS
type field so no further work is needed to allow them to use a custom
unmount program. If this is not the case, please let me know and I'll
attend to it.
There is no longer any need that I see to provide a general facility
for storing an alternate filesystem type name.
(One might also ask whether there's any real need for this
functionality at all any more; this is a fair question, but (a) the
change is small and (b) there are certainly cases when doing FS
research where you want a custom unmount program; been there & done
that.)
To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/sbin/umount/umount.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David A. Holland" <dholland@netbsd.org>
To: source-changes@NetBSD.org
Subject: CVS commit: src/sbin/umount
Date: Sun, 26 Jun 2016 03:59:11 +0000
Mail-Followup-To: source-changes-d@NetBSD.org
Module Name: src
Committed By: dholland
Date: Sun Jun 26 03:59:11 UTC 2016
Modified Files:
src/sbin/umount: umount.8
Log Message:
Document external unmount programs. PR 698. Bump date.
To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.16 src/sbin/umount/umount.8
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 26 Jun 2016 06:46:54 +0000
State-Changed-Why:
fixed, finally (modulo the provisos in the commit message)
From: "Simon J. Gerraty" <sjg@juniper.net>
To: <gnats-bugs@NetBSD.org>
Cc: <darcy@NetBSD.org>, <gnats-admin@NetBSD.org>, <netbsd-bugs@NetBSD.org>,
<sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 29 Jun 2016 15:00:30 -0700
David Holland <dholland-bugs@NetBSD.org> wrote:
> Log Message:
> If an external unmount program of the form "umount_TYPE" exists
> (e.g. umount_ffs, umount_nfs, etc.) exec it instead of calling
> unmount(2).
>
> Closes PR 698.
Thanks.
> (One might also ask whether there's any real need for this
> functionality at all any more; this is a fair question, but (a) the
> change is small and (b) there are certainly cases when doing FS
> research where you want a custom unmount program; been there & done
> that.)
Indeed - the case that prompted this PR, was NFS running over SSL to
userland NFS server. Mount requests authenticated by X509 certs and/or
2 factor authentication.
Performance was poor (putting it mildly) but not an important
consideration.
AFAIK the system is still in use today ;-)
From: David Holland <dholland-bugs@netbsd.org>
To: "Simon J. Gerraty" <sjg@juniper.net>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
too.
Date: Thu, 30 Jun 2016 01:14:57 +0000
On Wed, Jun 29, 2016 at 03:00:30PM -0700, Simon J. Gerraty wrote:
> Indeed - the case that prompted this PR, was NFS running over SSL to
> userland NFS server. Mount requests authenticated by X509 certs and/or
> 2 factor authentication.
> Performance was poor (putting it mildly) but not an important
> consideration.
>
> AFAIK the system is still in use today ;-)
If so, do we need nfs to provide the option of using an alternate
filesystem type string?
--
David A. Holland
dholland@netbsd.org
From: "Simon J. Gerraty" <sjg@juniper.net>
To: David Holland <dholland-bugs@netbsd.org>
Cc: <gnats-bugs@netbsd.org>, <sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Thu, 30 Jun 2016 09:50:57 -0700
David Holland <dholland-bugs@netbsd.org> wrote:
> If so, do we need nfs to provide the option of using an alternate
> filesystem type string?
That could help - should allow umount to find and
invoke an appropriate umount_* app.
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: darcy@NetBSD.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
too.
Date: Tue, 5 Jul 2016 16:05:24 +0000
On Thu, Jun 30, 2016 at 05:00:01PM +0000, Simon J. Gerraty wrote:
> David Holland <dholland-bugs@netbsd.org> wrote:
> > If so, do we need nfs to provide the option of using an alternate
> > filesystem type string?
>
> That could help - should allow umount to find and
> invoke an appropriate umount_* app.
Can you point me at what this thing is and exactly what it does (and
doesn't) do?
--
David A. Holland
dholland@netbsd.org
From: "Simon J. Gerraty" <sjg@juniper.net>
To: <gnats-bugs@NetBSD.org>
Cc: <darcy@NetBSD.org>, <gnats-admin@NetBSD.org>, <netbsd-bugs@NetBSD.org>,
<sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 6 Jul 2016 11:45:11 -0700
David Holland <dholland-bugs@NetBSD.org> wrote:
> > That could help - should allow umount to find and
> > invoke an appropriate umount_* app.
>
> Can you point me at what this thing is and exactly what it does (and
> doesn't) do?
It was never open sourced and I've not looked at it since about '98 so a
bit rusty...
An external file is used to track the port (and pid) used for each mount
point - in fact the pid is all we really need, since the client was
designed to unmount itself atexit() so one way or another an unmount
request typically resulted in sending SIGTERM to shuffler process:
:
# NAME:
# umount_snfs - umount an snfs filesystem
#
# DESCRIPTION:
# This script simply looks for the appropriate process in
# 'sclnts' and kills it. The 'snfsc' process does the rest.
# This is only necessary on 4.4BSD and other systems which do
# not support umount_*.
#
# AUTHOR:
# Simon J. Gerraty <sjg@quick.com.au>
#
That arrangement was sufficiently simple (and main use was on
SunOS anyway), that the lack of umount_* wasn't a huge issue.
As noted the snfsc client process (the RPC shuffler)
can simply be killed to have it cleanup:
/* DESCRIPTION:
* This is an RPC shuffler for passing NFS RCP's via TCP or SSL.
* If we decide we need to exit - error or request (SIGTERM) we
* dag around until we manage to unmount the fs from the kernel.
*
one way or another we end up at
cleanup()
{
do_unmount(80); /* save us first */
if (!UnmountRPCdone) {
char res = 0;
/* do an umnt RPC so server will close down */
syslog(LOG_DEBUG, "sending MOUNTPROC_UMNT %s...",
SnfsMntedDir);
clnt_call(MntClp, MOUNTPROC_UMNT,
xdr_dirpath, &SnfsMntedDir,
xdr_void, &res, TIMEOUT);
}
syslog(LOG_DEBUG, "exiting...");
}
>Unformatted:
Core has decided on the direction for this PR. From the minutes of the Core
meeting of 20060316:
* version mount syscall
* each foo_args struct will have a version field, and an fstype
* store the fstype in foo args [first few args are common]
* support separate mount programs
* don't store the pid internally
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.