Sysinstall automatic filesystem size generation.

[Matthias Buelow]

C. Michailidis wrote:

>Effectively, we are taking a known variable that may fluctuate
>greatly (disk size) and completely ignoring it during installation.
>Pretty dumb, no?  Obviously, this leaves a bad taste in my mouth.
>Take it to an extreme and maybe I can convert you to my team.
>Imagine installing to a disk that is 500 terabytes in size...
>wouldn't it be odd (to say the least) for sysinstall to allocate
>some infinitesimally small fraction of the disk to /tmp?  Isn't
>/tmp just a place to store temporary files?  Isn't there the
>*possibility* that you are using your system correctly and yet still
>want to store a large temporary file?

>From my experience, 256MB is usually more than enough for /tmp. The
/tmp directory isn't typically used to store arbritrary huge datasets
but is used only by system utilities, scripts, etc., for storing
(small) temporary files. The /tmp directory is often a (virtual-)
memory-backed filesystem, and on some systems this is the default
setting (Solaris, NetBSD 2), so a developer cannot assume in any
case that /tmp will be large.

Furthermore, the operating system occupies only a small portion of
my large hard drive in my workstation, for example. The rest is
occupied by, uhm, user files. It doesn't make sense to scale up the
basic filesystems by orders of magnitude relative to disk size.  I
do agree however, that 256mb might be a bit small for / or /var.
Maybe cap those at 1GB (/) for the default settings. The /usr
filesystem should be at least 5-6GB for a typical workstation setup,
if space permits, but probably not more than 10GB.

mkb.

P.S.: Please instruct your mail program to wrap lines at about 72
characters, as is conventional. You have lines >700 characters in
there, and I had to manually reformat the quoted text, which is
annoying.