From owner-freebsd-arch Sun Dec 9 11:44:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A2E237B405 for ; Sun, 9 Dec 2001 11:44:11 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB9Jhc438335; Sun, 9 Dec 2001 11:43:38 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 11:43:38 -0800 (PST) From: Matthew Dillon Message-Id: <200112091943.fB9Jhc438335@apollo.backplane.com> To: Nate Williams Cc: Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> <15379.43805.336137.177646@caddis.yogotech.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :I disagree. They may not be optimal, but they are acceptable. It is far easier to present a rich set of partitions and allow the user, in a few flicks of the keys, to delete the ones he doesn't want then to present a minimalist set of partitions and require the user to then screw around with them if he wants more (he'd also have to delete & recreate the overlarge /usr and then create the additional ones). Frankly I don't see how the minimalist set could possibly be better. It requires far more work and understanding of the system. You may like the minimalist defaults, but I sure as hell don't, and many other people don't either. My way encompasses a much larger crowd (including encompassing your requirements if you don't mind two flicks of the keyboard to 'restore' it back to what you had before). :> It creates relatively unsafe partitions - for example, :> leaving /var/tmp on /var where /var itself is ALREADY too small for :> a number of ports, including our printing mechanism and vmware. : :Completely disagreed. /var/tmp doesn't need to be any bigger *IF* you :don't symlink /tmp into /var/tmp. (Which I still think is a *REALLY* :*REALLY* *BAD* idea, but unfortunately I'm certain this will become the :point to argue about, because I think this is the basis for most of your :othe changes. :() This is nonsense. Many programs operate directly on /var/tmp. In fact, considering how small /tmp often is (being on / if you screw around with it), many programs, and users, wound up not having a choice. Not to mention the fact that having /tmp on / by default is unncessarily dangerous in regards to a crash. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message