Date: Sun, 9 Dec 2001 01:33:40 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> 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: <20011209013340.D6171@cicely8.cicely.de> 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 Sat, Dec 08, 2001 at 02:11:16PM -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. I hate if Software writes on /var/tmp instead of /tmp. I don't need an fsck on /tmp because it's md/mfs based - or if you like for performance reasons newfs the partition at boot. /var/tmp should be used for files that should survive a reboot like vi.recover and nothing else. FreeBSD still ships with /usr/share/doc/smm/01.setup/paper.ascii.gz where /tmp is said to be MFS based and /var/tmp disk based. > 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 Not surprising with a softlink from /tmp to /var/tmp. > /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. There is more than that - think of /var/spool/lpd or /var/log. If you want it save then create a /var/mail and /var/spool partition. > 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!). The traditional directory is /var/users but I prefer /var/home. If you don't want a separate /home partition /var/users is the better choice. /home is the place for system wide home directories which are usualy non-local - therefor no need for a local partition. I agree that /usr/home is bad idea. > (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. Right - it's administered so if space go out the administrator can always mount additional space under /usr. That's the same reason I usually softlink /usr/ports to /var/ports as it can easily blow space. Uh Softlinks are remembered by some programms so /home softlink doesn't work perfect. It's the same reason I don't like software using /compat instead of /usr/compat. /var is my definition of whats left after creating /, /usr and what additionally needed. > 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. The auto-resizing part is realy a missing feature. > So despite your objections I am still leaning very heavily towards > wanting to include /var/tmp and /home as defaults for the Auto option. A home default is a good idea but I don't like it in / for the reasons above. It's also easier for a possible autoresize to add /var/users to /var instead of having a completely different path. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?20011209013340.D6171>