Date: Sat, 8 Dec 2001 14:11:16 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jordan Hubbard <jkh@winston.freebsd.org> Cc: Garance A Drosihn <drosih@rpi.edu>, "Louis A. Mamakos" <louie@TransSys.COM>, Sheldon Hearn <sheldonh@starjuice.net>, Kirk McKusick <mckusick@beastie.mckusick.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: <200112082211.fB8MBGm18685@apollo.backplane.com> References: <49294.1007846108@winston.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm. Well, I have to disagree somewhat. 'A'uto isn't useful if the user has to think too much about it, and there is nothing preventing the user from deleting the partitions he doesn't want. /var/tmp and /home are fairly standard partition names... nothing new in my book. I certainly didn't invent them! In particular, these two partitions greatly increase the safety of the system... I can't count the number of times I've seen fsck *fail* on /var/tmp after a crash and was thankful that /var/tmp wasn't on /var. Not only that, but blowing-out /var/tmp is relatively easy to do even on a single user system. The last thing you want to see is a full /var/tmp causing your mail system to throw up rocks because it's on the same partition as /var. There is absolutely no sane reason to combine /var and /var/tmp together. The same thing goes for /home, though in /home's case the reasoning is somewhat more ephermal. You get the same safety factor in regards to having a greater chance of recovering /usr after a crash if /home isn't sitting in /usr (/usr/home) (or sitting in root for that matter!). (remember why /var was separated from /usr in the first place?). But you also have the added benefit of making /usr a managed space, limited to X amount (e.g. 3GB) and placing the remainder of your free space in /home. It makes far less sense to place the remainder of your free space in /usr. This setup works equally well as a default for both single and multi-user systems and also works fairly well for power-user and developer systems, and for most special-purpose systems except large special-purpose mail spools and repositories (which typically need a huge /var). It works far better as a default then simply creating /, /usr, and /var. In that light perhaps what we need to do is have an auto-resizing feature, so if the user deletes an auto-created partition sysinstall automatically resizes the auto-created partitions before it to fill up the space. So if the user hits 'A' and doesn't want /var/tmp, they simply delete /var/tmp and /var gets its space. And if they don't want /home they simply delete it and /usr gets its space. I think this is a much easier mechanism for the user then requiring him to select which Auto-profile to use. So despite your objections I am still leaning very heavily towards wanting to include /var/tmp and /home as defaults for the Auto option. -Matt :To put it another way, I like the idea of more intelligent dynamic :sizing for the existing set of default filesystems and would support :that without reservation since the current set of default filesystems :(/, /usr, /var) was rather deliberately chosen to represent the lowest :common denominator of what a user might want *regardless* of the :mission profile of the machine (OK, /var is currently too small for :some missions, but that's orthogonal since we're not talking about the :sizes, we're talking about the default set). : :I've also avoided addressing this feature for as long as I have :because I knew that going to the next logical step would involve a lot :more than just beefing up certain defaults and adding a few more :filesystems to the mix - that would have been easy. The minute you :take that easy out you also start making the configuration less :generic and more mission specific, even if the mission is defined by :your own biases as to what "generic" means. If you're going to go :down that road at all then you might just as well admit from the start :that what you need are multiple canned mission profiles and not just a :single set of defaults which feel best to you but will probably just :annoy a lot of other people. :... 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?200112082211.fB8MBGm18685>