Gleaned from /usr/src/usr.sbin/sysinstall/label.c:
#define ROOT_DEFAULT_SIZE 256 #define USR_DEFAULT_SIZE 3072 #define VAR_DEFAULT_SIZE 256 #define TMP_DEFAULT_SIZE 256 #define HOME_DEFAULT_SIZE USR_DEFAULT_SIZE //yada yada #define ROOT_NOMINAL_SIZE 192 #define USR_NOMINAL_SIZE 512 #define VAR_NOMINAL_SIZE 64 #define TMP_NOMINAL_SIZE 64 #define HOME_NOMINAL_SIZE USR_NOMINAL_SIZE //yada yada * Attempt to auto-label the disk. 'perc' (0-100) scales * the size of the various partitions within appropriate * bounds (NOMINAL through DEFAULT sizes). These defaults are tiny... are we still living the 1970's? A 200+gb hardrive is now just over $100 (not exactly a small fortune). Isn't it safe to make some of the default sizes a wee bit larger? That is, a 256mb /tmp and /var doesn't seem "appropriate" if you have one of these massive modern disk drives. For christ's sake, I'd gladly give up a GB or two of /usr so I could build openoffice without needing to consider that I may need an extra few megabytes in /var at the time of the system install. Wouldn't it be smart to remove the hardcoded default sizes altogether and dynamically generate them according to a reasonable function? My initial thought is that scaling them up logarithmically (according to slice size) makes a lot more sense. For example, if the default root fs size where calculated during sysinstall runtime to be 32*ln(slice_size_in_mb), sysinstall would auto-label a 512 mb slice with a 199 mb root filesystem (roughly nominal) and a 200gb slice with a 390mb root filesystem (extra space since the slice can obviously afford it). Something similar would occur for /tmp and /var, the rest of the slice would go towards /usr. Did you ever see a 300 lb. bodybuilder with legs like pencils? It's pretty funny. Now imagine a 199gb /usr with a 256mb /tmp /var and /, look similar? This issue became apparent when I attempted to portupgrade OpenOffice and the process failed, indicating that there wasn't enough space in /var/tmp.... I have a 60gb disk drive and my /var and /tmp are a lousey 256mb?!?!? Ugh! Please don't jump down my throat on this one... I know, I know... I'm stupid, yes I should have labelled the disk by hand. I probably should have installed the entire system by some other incredibly painstaking method too, perhaps I should have etched the bits onto the disk with a needle, a spool of wire, a magnet, and a 9-volt battery - IDK. Forgive the chip on my shoulder, but I had to get that out of my system. I've posted to lists like this so often that I know there is a certain faction which is more than ready to blame the naive user (me) for any and every issue that creeps up. I can see it now.. "<BOF>No! No! No! You don't understand... the system is perfect as it is, the problem is that YOU are an idiot.<EOF>". Okay, I already know this. Please don't respond unless you have CONSTRUCTIVE input and/or criticism. Don't respond just to call me a dimwit - please provide meaningful content. Here's a decent rule of thumb: if your response is less that 20 words or 100 characters, try and love again. That being said... I understand that the automatically generated values by sysinstall are the "dumbest" settings you can ask for... but auto-allocating a maximum of 256mb for the root, var, and tmp filesystems (even if you have an incredibly large slice in the 100's of GB) seems to be BEYOND dumb. Perhaps I've just pointed out that I am, in fact, beyond dumb, lol! ;-) Anyway, If it's simply a matter of not having enough programming resources, I'd be more than happy to make the changes to sysinstall and offer the unified diffs. Just let me know your thoughts so that the changes may be relevant for all users. -Dino ********************************** The Dude: I could be just sitting at home with pee stains on my rug. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
