From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 15:23:42 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 BD3B516A4CF; Tue, 28 Oct 2003 15:23:42 -0800 (PST) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE5643FE0; Tue, 28 Oct 2003 15:23:41 -0800 (PST) (envelope-from wegster@mindcore.net) Received: from mindcore.net (rdu163-100-105.nc.rr.com [24.163.100.105]) h9SNNWQT013569; Tue, 28 Oct 2003 18:23:34 -0500 (EST) Message-ID: <3F9EFA72.20508@mindcore.net> Date: Tue, 28 Oct 2003 18:23:30 -0500 From: Scott W User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <200310271326.23562.wes@softweyr.com> <20031028120520.A20792@hub.freebsd.org> <200310281512.07942.wes@softweyr.com> In-Reply-To: <200310281512.07942.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: current@freebsd.org cc: wes@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:23:42 -0000 Wes Peters wrote: >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. > > > This would also be useful for anyone doing any sort of benchmarking using data sets- I did a code port of LADDIS/SFS to Linux ages ago to do some NFS/SMB fileserver testing, and I can say, quite a LOT of entirely temporary data is generated... Scott