From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 15:12:35 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF8BC16A4CE; Tue, 28 Oct 2003 15:12:35 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E25BB43FB1; Tue, 28 Oct 2003 15:12:34 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id C62D19BEA7; Tue, 28 Oct 2003 15:07:43 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: current@freebsd.org, David O'Brien , wes@freebsd.org Date: Tue, 28 Oct 2003 15:12:07 -0800 User-Agent: KMail/1.5.2 References: <200310271326.23562.wes@softweyr.com> <20031028120520.A20792@hub.freebsd.org> In-Reply-To: <20031028120520.A20792@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310281512.07942.wes@softweyr.com> cc: current@freebsd.org Subject: Re: newfs by fstab directory name? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 23:12:35 -0000 On Tuesday 28 October 2003 12:05, David O'Brien wrote: > On Mon, Oct 27, 2003 at 01:26:23PM -0800, Wes Peters wrote: > > At work we do a lot of dynamic filesystem creation, so we added the > > ability to specify the 'special file' argument to newfs via the > > fstab mount point directory. Please see the attached patch. If > > nobody objects, I'll commit this in a couple of days. > > Not objecting, but I don't follow how the change is to be used. > Can you post an example? Sure. Example from /etc/fstab: /dev/ad0s1d /tmp ufs rw 2 2 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1e /spool ufs rw,noauto 0 0 The disk space on /spool is managed by the "application" and isn't guaranteed to be on-line or even existent when the "system" portion loads and starts the application. This space is entirely transient data that doesn't need to be saved across reboots. When the application starts, it checks to see if /spool is clean; if so it just mounts it, if not it newfs's it and then mounts it. This space isn't necessarily always "da0s1e" but it is always "/spool" across different hardware platforms. We prefer to: newfs /spool rather than . {some file full of shell variables describing the hardware} newfs $SPOOL_PARTITION because the former is slightly more concise. We had a local patch to do this in our 4.x code base, but it seemed a general enough change that others might find it useful as well. I recall ecountering this same problem at DoBox so it appears to be a general problem for disk-based appliances, at least if you want to support differing hardware. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com