Date: Sun, 9 Dec 2001 11:01:21 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Jordan Hubbard <jkh@winston.freebsd.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <Pine.NEB.3.96L.1011209105522.85510A-100000@fledge.watson.org> In-Reply-To: <50872.1007888210@winston.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Dec 2001, Jordan Hubbard wrote: > > /var/tmp and /home are fairly standard partition names... nothing > > new in my book. I certainly didn't invent them! In particular, > > Well, from my perspective you might as well have invented /var/tmp, at > least, since that's a filesystem I *never* create. I either move /var > entirely off of / (with no sub-mounts) or I leave it there, depending on > the mission profile of the machine. /home, yeah, *sometimes* I make > /home its own filesystem and sometimes I have it linked to /usr/home or > /vol1/local/homedirs or somesuch. You see my point? We're already in > disagreement that there's anything "standard" about those two at all > since our "standard practices" vary considerably, and that's just the > two of us disagreeing. Add several hundred thousand more people to the > mix and now you have a lot of people expending keystrokes they didn't > have to before, deleting these two new and entirely gratuitous creations > of (A)uto. Well, I have to agree with Jordan here. This went from a discussion of how the current sizing in (A)uto for the current layout was inadequate to a discussion of everyone's personal favorite layout, and how it's the only one anyone should ever put in (A)uto. I think both these discussions have their merits, needless to say, but it does seem like a lot of teeth are being dug in pretty deep over something that we all need to just disagree on anyway. What we should probably be doing is two-phase: (1) make sure our current Auto does something useful in terms of sizes, and (2) discuss what a reasonable default layout might be. The primary problems I run into with today's (A)uto for many users are that the temporary directories and root partitions are too small for currently deployed software. I think Matt's commit to -CURRENT resolves this problem. What I would like to see is a delay before MFC: Matt proposed a one week MFC, but I think actually waiting several weeks would be prefered. > Why tie new mechanism and new policy together, I say. Introduce the > more powerful default sizing mechanism as a general improvement first > and then go to the next level and introduce proper profiles, don't just > add two pet filesystems from your list and consider that particular > problem somehow solved. Sure, sounds good to me. I regularly deploy systems with several different layouts, including: Big root, swap partition 128Mb or 256Mb root, swap partition, /usr, /var, MD-backed /tmp and /var/tmp, /home, and /data (A)uto's defaults from 4.4-RELEASE, modulo larger root, and /tmp symlinked to /usr/tmp. The recurring theme there is really the larger root, and special handling of temporary directories. In 4.3, we shipped a number of packages that could be installed using the default layout, because /var/tmp was too small. That's easy to fix. I think what people do need to do in such a discussion is recognize that (a) their experience isn't everyone's experience, and as a result (b) their optimum configuration isn't the same as everyone else's. (A)uto probably simply needs to be "decent" for expected needs for the next few years in terms of temporary space usage, expected bloat of software, and package installs. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011209105522.85510A-100000>