> From: Polytropon <free...@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 <mahle...@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, ...





_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to