Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Dec 2001 20:00:03 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        "Louis A. Mamakos" <louie@TransSys.COM>, Sheldon Hearn <sheldonh@starjuice.net>, Kirk McKusick <mckusick@beastie.mckusick.com>, freebsd-arch@FreeBSD.ORG
Subject:   Re: Using a larger block size on large filesystems 
Message-ID:  <200112080400.fB8403P00383@apollo.backplane.com>
References:   <Pine.NEB.3.96L.1011207214719.57264G-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112080400.fB8403P00383>