/ almost out of space just after installation

[Richard Mahlerwein]

--- On Sat, 10/10/09, Polytropon <freebsd at edvax.de> wrote:

> From: Polytropon <freebsd at edvax.de>
> Subject: Re: / almost out of space just after installation
> To: "Chad Perrin" <perrin at apotheon.com>
> Cc: freebsd-questions at freebsd.org
> Date: Saturday, October 10, 2009, 2:04 PM
> On Sat, 10 Oct 2009 11:36:08 -0600,
> Chad Perrin <perrin at apotheon.com>
> wrote:
> > Someone mentioned giving the `home` directory its own
> partition.  I think
> > a separate partition for /usr/home, mounted within
> /usr, is a great idea.
> > It would help substantially with system rebuilds,
> backups, and using
> > separate drives for `home`, because that's where the
> majority of the
> > stuff you want to keep between installs will
> reside.  Basically
> > everything else within /usr (with the possible
> exception of
> > /usr/local/etc) is just what happens when you install
> and configure your
> > system in the first place.
> 
> If you can estimate disk requirements good enough, or
> simply
> have huge hard disks that can compensate any requirements,
> there's
> no problem giving /home a separate partition. There's no
> need
> to put the mountpoint into /usr, because /home could
> "physically"
> exist; in the "home in usr" setting, /home is just a
> symlink to
> /usr/home.
> 
> Personally, I often put /home on a separate partition,
> simply
> because of comfortability. If I can't say enough about how
> /usr
> and /home will grow, I go with the default approach. I
> sometimes
> even use the "one big /" setting.
> 
> One advantage of /home as a separate partition is that you
> can
> easily use dump to create a backup - you simply backup the
> whole
> partition. You could have a directory, let's say
> /home/settings,
> where you keep duplicates of /etc, /usr/local/etc and other
> files
> that contain settings you consider worth being backed up.
> 
> 
> -- 
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...

I agree completely.  I also go a step farther and put most other things that I consider user data in there.  Like Subversion repositories and non-user-specific Samba shares (E.g. "public" type shares).  I do not generally want /tmp on memory, though.  While it can be fun and quite a festive thing, I have far too many systems too limited in RAM to want to do this (my current "production" system at home is 512 MB of RAM, my "play" box is 256 MB).  The only time I can really think I'd want /tmp to be in RAM is if I already had too much RAM for the needs of the box - otherwise, just give me the RAM...

While I'm reasonably happy rolling my own FS sizes, I would be even happier if I didn't have to.  As long as we're doing the wish list, I'd guess for this (all numbers significantly flexible):

Drive < 16 GB = keep current layout?

Drive > 16 and < 40 GB = 
/ = 1 GB
swap = 1.5x RAM 
/tmp = 2 GB
/var = 2 GB
/usr = remaining space

Drive > 40 GB = 
/ = 1 GB
swap = 1.5x RAM 
/tmp = 2 GB
/var = 2 GB
/usr = 1/2 of remaining space, min 20 GB, max 35 GB
/home = everything else.

And, as long as this is a wish list, how about...

1) When I create, I would love to not to *always* have to backspace over like 17 digits every time to type something short like "16G".  Can we just make it operate in MB or something instead of blocks?  Does anyone need smaller than 1 MB divisions now?  
1.1) If it would take a decimal point, I'd be fine with GB, for that matter.  (For compatibility, allow either , or . as decimal.)
1.2) Or if there was just a quick key to delete all 14 digits of "number of blocks left" at once.

2) When I 'auto' size, I end up deleting most except / and swap partition and remaking (it is just habit I 'a'uto before I think, and no harm in it) except the last few times I've done it, as I deleted all the other partitions, / kept expanding from the default (512 MB?) until it was 1.5 GB.  So I had to deleted them ALL and start over.  Bug or Feature?

3) Ability to resize any partition directly, if there's empty space left.  So if I have 30 GB of my 400 GB drive already decided upon, and I decide that I want /var to be 5 GB instead of 2 GB, I would love to be able to just highlight it and press some key to "Resize" and it would just move the rest of them up to fit.

Of course, Just because this is a bike shed doesn't mean I will get upset if any or even all of this is too much to implement and doesn't make it in any revision of sysinstall.  It's just a wish list.  In fact, I may pull open the code myself... though I've heard it's pretty nasty...

-Rich