From owner-freebsd-stable@FreeBSD.ORG Sun Sep 4 19:25:11 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 65DF016A41F for ; Sun, 4 Sep 2005 19:25:11 +0000 (GMT) (envelope-from dinom@balstonresearch.com) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0730843D45 for ; Sun, 4 Sep 2005 19:25:10 +0000 (GMT) (envelope-from dinom@balstonresearch.com) Received: from [192.168.1.105] (pcp09554062pcs.verona01.nj.comcast.net[68.36.0.26]) by comcast.net (rwcrmhc11) with ESMTP id <2005090419251001300avk0ie>; Sun, 4 Sep 2005 19:25:10 +0000 From: "C. Michailidis" To: freebsd-stable@freebsd.org Date: Sun, 4 Sep 2005 15:28:23 -0400 User-Agent: KMail/1.8.2 References: <000d01c5ac73$0e4fbb50$6b2a15ac@SMILEY> <200508290609.42070.dinom@balstonresearch.com> In-Reply-To: <200508290609.42070.dinom@balstonresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200509041528.24038.dinom@balstonresearch.com> Subject: Sysinstall FS sizing defaults [was: Sysinstall automatic filesystem size generation.] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 19:25:11 -0000 On Monday 29 August 2005 06:09 am, we left the discussion here: >=20 > <...> Isn't it safe to make some of the default sizes a=20 > wee bit larger? That is, a 256mb /tmp and /var doesn't seem=20 > "appropriate" if you have one of these massive modern disk=20 > drives. For christ's sake, I'd gladly give up a GB or two of=20 > /usr so I could build openoffice without needing to consider=20 > that I may need an extra few megabytes in /var at the time of=20 > the system install. >=20 <...> >=20 > Wouldn't it be smart to remove the hardcoded default sizes=20 > altogether and dynamically generate them according to a=20 > reasonable function? > > Probably, but a template for something like this isn't simple unless > > it's created as part of a general profile-based installer that would > > inform sysinstall of the machine's purpose in life. =A0For example, a >=20 Since the original thread got hijacked by the soft-update/write-cache/reise= rfs/journalling crowd I've renamed the thread (LOL). Now, maybe it's just a waste of my time but... I started creating patches f= or sysinstall to provide rudimentary functionality of this nature. My init= ial goal is to provide a handful of options to the user after they've chose= n to automatically create their partitions (using the 'a' key during disk l= abelling). I'm pretty sure that other disk partitioners do this and I can'= t think of a reason why we (as FreeBSD users) shouldn't have it available t= oo. I've come up with the following profiles based on past discussion in this m= ailing list thread: Desktop Modern multimedia or development workstation. Normal sized root partition. Extra space will be allocated to the tmp and var partitions and the remainder of the slice will be allocated to the usr partition. Server Normal sized root and tmp partitions. A larger var partition will be created for server and log files and the remainder of the slice will be allocated to the usr partition. Monolith The entire slice will be allocated to the root partition. This labeling strategy insures that you won't run out of space on any single sub-partition. However, by splitting your data over multiple filesystems (i.e. choosing another option) it is more likely that the system will still come up after a catastrophic failure making it easier for you to restore from backup as necessary. Generic This will label the slice with traditional default partitions. You may choose this option if you are unsure of the ultimate use of the system. I cannot proceed with the implementation of the 'behind-the-scenes' code un= til finalizing this set of options. Thus, I am petitioning the list for fe= edback to this capricious endeavor. Ultimately, I envision each additional= profile/labeling strategy to be a slight variation on the "generic" (i.e. = current) implementation of auto-labeling; except of course for drastically = different strategies like "monolith". My thought is when a larger /var or = /tmp is called for by a profile, instead of using the hardcoded defaults - = the value used could be the larger of either 2 times the existing default o= r ~2 percent of the slice in question. In more concrete terms... xxx_default_size =3D (XXX_DEFAULT_SIZE*2 > space_free(label_chunk_info[here= ].c)*2/100) ? XXX_DEFAULT_SIZE*2 : space_free(label_chunk_info[here].c)*2/1= 00 =2E..or something to that effect would be added in a few places around line= 1535 of sysinstall's "label.c". I don't think any of the profiles should = change the default swap partition size determination. Although arguments f= or changing the default swap partition size may be interesting, I do not be= lieve any of the profiles should do this (laziness you know). ;-) If you have any suggestions, comments, or constructive criticisms I'd love = to hear them. I believe the utility of these patches will (largely) be det= ermined by the kind of feedback I receive. So... please, if you can think = of a profile you would desperately like to see or you notice some absurditi= es in the profiles I've come up with, do not hesitate to reply. Otherwise, I'll finish up the changes and offer the unified diffs for inclu= sion in your system. Thanks, Dino