From owner-freebsd-stable@FreeBSD.ORG Tue May 10 23:10:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5944C16A4CE for ; Tue, 10 May 2005 23:10:44 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E22F43D81 for ; Tue, 10 May 2005 23:10:43 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 42687F2000514676 for freebsd-stable@freebsd.org; Wed, 11 May 2005 01:10:42 +0200 Received: (qmail 4607 invoked by uid 1001); 10 May 2005 23:10:40 -0000 Date: Wed, 11 May 2005 01:10:40 +0200 From: Erik Trulsson To: Billy Newsom Message-ID: <20050510231040.GA4494@falcon.midgard.homeip.net> Mail-Followup-To: Billy Newsom , freebsd-stable@freebsd.org References: <4280353B.8050306@leadhill.net> <42803B66.3070200@alumni.rice.edu> <428044C2.80208@leadhill.net> <428052CB.2000704@alumni.rice.edu> <428132B0.4060104@nlcc.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428132B0.4060104@nlcc.us> User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: nfs bug & df: Can I lock up my kernel and overflow this buffer? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 23:10:44 -0000 On Tue, May 10, 2005 at 05:16:16PM -0500, Billy Newsom wrote: > Jonathan Noack wrote: > >> Anyone tried that sort of stuff in fstab? I'm a little skeptical. > > > > I use "that sort of stuff" and have for a long time. Here's one of my > > fstab lines: > > > > optimator:/usr/home /usr/home nfs rw,-3,-T,-r=32768,-w=32768 0 0 > > > > It's obvious you don't believe me but why are you unwilling to try it > > yourself? > > Well, because this fails to work on the commandline: > > #mount -o -s -x 2 -T dell:/nfs /dellbak > > I tried tons of different ways, never could get mount to do that, so I > gave up on fstabbing options. Note that mount(8) (as well as mount_nfs(8)) says about the -o flag that "Options are specified with a -o flag followed by a comma separated string of options." If you try writing it as the manpage says, i.e. like mount -o -s,-x=2,-T dell:/nfs /dellbak it should work fine. > > Since the above mount command wouldn't even work, I figured I could > forget about putting those same options (which mount calls illegal) in > the fstab file. That's where the man pages only go so far. Without the > examples you give, I was pretty sure that it was pointless to get fstab > options to do what mount wouldn't. > > What it boils down to is that mount is fine with these options in fstab, > but barfs when doing them on the commandline. That was so > couter-intuitive, I went around it for the sake of getting things done. It works fine on the commandline, you just got the syntax for the commandline wrong. > > FreeBSD man pages are nice and all, but without a textbook siting by > with some examples, it can be difficult. I learned Unix pretty much ad > hoc, so I find that examples (such as you gave) are worth much more than > man pages now that I know most of the basics. Man pages often have some examples, but learning things only from manpages can indeed be a bit difficult. > > Thanks. > > But what I did discover is that if I mount the same nfs resource > multiple times, I get multiple, identical mounts (using fstab options, > or commandline, either one). I have to umount each one serially. How > is this a feature? It is a feature in that the system does exactly what you asked it to do. This is usually less painful than systems that try to guess what you actually meant. > What good does it do me if I mount the same nfs > drive to the same place n times? None that I can think of, which doesn't mean that there is no use for it. > Won't that eventually cause a deadlock > as n increases beyond a few hundred or thousand? -- especially when the > NFS server goes down? Probably not a deadlock, but possible a resource starvation - so don't do that. > Shouldn't the second and subsequent mounts either > fail or not be attempted due to a sanity check? > > #mount /usr > mount: /dev/ad0s1f: Device busy > Exit 1 > > That seems reasonable for /usr. But as I stated before, NFS resources > nevere apparently become "busy", and there is no sanity check to prevent > mulitiple simultaneous mounts of identical file systems on identical > file trees. -- Erik Trulsson ertr1013@student.uu.se