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>