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:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 04 15:20:03 +0000 1995
>Closed-Date:    
>Last-Modified:  Mon Mar 20 17:53:32 +0000 2006
>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". 
>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

 

Home	PR Database Search