From owner-freebsd-arch Fri Dec 7 20: 0: 6 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 A453337B405; Fri, 7 Dec 2001 20:00:03 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8403P00383; Fri, 7 Dec 2001 20:00:03 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 20:00:03 -0800 (PST) From: Matthew Dillon Message-Id: <200112080400.fB8403P00383@apollo.backplane.com> To: Robert Watson Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: 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 :While we can discuss the merits of doing this for the -STABLE branch, I :for one will be quite happy to see this be the case for -CURRENT, where :storing three complete sets of kernels and modules (kernel.new, :kernel.old, and kernel.dontworryaboutmeiamsafe) consumes vast amounts of :disk space with the various debugging symbols, et al. The sysinstall code is virtually identical between -stable and -current. I'm developing these patches under -stable but will obviously test & commit under -current before MFCing to stable. :BTW, we keep suggesting people would be foolish to use anything other than :MFS/md for /tmp (and maybe other variations on tmp), but our sysinstall :doesn't support doing this "automagically". I'm not sure what the right :vehicle is for that in sysinstall, but it would be nice to see. Another :interesting problem with the current partition layout is the extremely :small size of /var, on which we find /var/tmp, which is used for package My patch adds a /var/tmp. 128M for the moment. We can discuss it. The main thing is that my patch adds a framework by which we can more easily fit the partitions onto an (almost) arbitrarily small or large disk. I also added a /home, because it's just not a good idea to put people's home directories in the same filesystem as /usr where a user might fill up the partition. I strongly disagree with MDing /tmp. It's a hugely bad idea. The absolute safest thing to do is to make /tmp a softlink or a null-mount to /var/tmp (though I'm still not sure how good an idea it is to have a null-mount in the default system considering their history of instability). -Matt :unpacking before installation. For large packages, such as KDE, LaTeX, :and friends, this can be a big problem, as well as for vmware which likes :to drop huge paging files into /var/tmp. Combining these various :temporary spaces into a single md partition sized to something appropriate :might make sense. This is seperate issue from the root partition, of :course, but something we might want to look into a strateg for. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message