/ almost out of space just after installation

[Richard Mahlerwein]

> From: Polytropon <freebsd at edvax.de>
> Subject: Re: / almost out of space just after installation
> Date: Saturday, October 10, 2009, 4:00 PM
> On Sat, 10 Oct 2009 12:28:08 -0700
> (PDT), Richard Mahlerwein <mahlerrd at yahoo.com>
> wrote:
> According to your suggestion:
> 
> > Drive > 16 and < 40 GB = 
> > / = 1 GB
> > swap = 1.5x RAM 
> 
> I know that there was the idea of saying "swap = 2 x the maximum
> of RAM you could put into the box", but is this approach still
> valid today?

Unknown, but since most servers support more RAM than you are likely to put in them*, I think it would make more sense to set swap to 2x the largest _likely_ amount of RAM (assuming the 2x rule IS good in a general sense).  I seem to recall the reason for the 2x was a combination of reasons, but it seemed the most important internally was because the memory management routines in place when the rule was created were built to be most effective at that particular ratio.  This was many, many years ago, and heaven knows I could be totally wrong ... so some research may be warranted.

*The HP DL380 G6s we've been buying now support something like 128 GB.

> > Drive > 40 GB = 
> > /var = 2 GB
> 
> There could be a different requirement, especially when
> someone wants to run
>     a) an anonymous FTP server (/var/ftp subtree)
>     b) database operations (/var/db subtree)
> and have the /var sizes grow very fast. Of course, there's no
> problem putting databases and FTP stuff somewhere under
> /home (which is in /usr in your example).

Excellent point.  I was trying to stay away from usage patterns, though, and just stick with predetermined items like "how much space do I have available?".  Once you get past that, you have an order of magnitude more things to consider, IMO.  

I think the most commonly increased partition would be /var.  Again, I think something reasonably simple like being able to delete the last partition (we'll assume /home at the moment), then just "resize" /var to be bigger, let all the intermediary partitions slide "up" and then recreating /home to be whats left now would be simple and may work to handle these cases more cleanly. 

> > 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? 
> 
> There is an easier approach, I'd call it "overwrite with first
> keystroke". This is common for many dialog libraries, such as
> in Midnight Commander. 

That would be stellar.  I hadn't even realized it but so many things (in all *sorts* of places!) use that method.  A quick glance at the code that seems to be responsible for the keystroke handling (/usr/src/gnu/lib/libdialog/lineedit.c) seems to indicate it's fairly stateless - it doesn't seem to know things like if the dialog still has the oroginal input values in it or if you've already typed something.  Also, changes here may affect all sorts of things (since it's as far from /usr/src/usr.sbin/sysinstall/ as you can get, tree-wise).

> Maybe Meta-Backspace (Esc, then Backspace) would
> be available to erase the whole content of the input field
> as you suggested in 1.2.

This would be fairly easy to implement, I think.  Unfortunately, I would feel horrible for implementing something like this when there's so many serious bugs in sysinstall.
http://www.freebsd.org/cgi/query-pr-summary.cgi?text=sysinstall
I wonder if the delete key, when pressed at the end of the input, would do?  Seems like a magic key, but on the other hand, it also seems pretty innocuous.  

I'm still thinking that using MB or GB as the default might be easier.

> Maybe this is a nice item for a dialog wishlist for
> sysinstall. :-)

I couldn't agree more.  Does anyone really know what the plans for either sysinstall or a replacement is?  There's a ton of bugs in it...

> -- 
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...