Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Dec 2001 16:57:25 +1030
From:      Greg Lehey <grog@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Jordan Hubbard <jkh@winston.freebsd.org>, 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:  <20011209165725.D83634@monorchid.lemis.com>
In-Reply-To: <200112082211.fB8MBGm18685@apollo.backplane.com>
References:  <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday,  8 December 2001 at 14:11:16 -0800, Matthew Dillon wrote:
>     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.

Auto isn't much use if it makes the wrong decision.  I can't really
see how it can make the right decision, given the various usages you
can have.

>     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.

It's clear that you and I have very different opinions on
partitioning.  I'm not trying to convince you, but it seems to me that
for exactly that reason, the user should hear the arguments (yours,
mine or somebody else's) and make up his own mind.  sysinstall can
give him the choice.

Greg
--
See complete headers for address and phone numbers

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?20011209165725.D83634>