Hi Nathan Whitehorn! On Sun, 21 Aug 2011 11:53:22 -0500; Nathan Whitehorn wrote about 'Re: 9.0-BETA1 installer glithcies (i386)': >> (3) "Auto" creates one big / partition + SWAP. It looks very not-BSD >> way (disk is only 8Gb, it is virtual machine). > This is designed to ease resizing on VMs as well as to kill the > default-/-is-too-small problem forever. There was a great deal of > discussion about this several months ago; no one made a final proposal > for changing it. Actually, it's simple: make / be able to survive 5 years from now (a reasonable age before major upgrade). So, the size needs to be predicted. http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.svg says that hard disks sizes grow according to Moore's Law, 10 times per 5 years. The FreeBSD kernel sizes grow slower, though. As of src/usr.sbin/sysinstall/label.c CVS log: rev 1.161: / 1 Gb in Jul 2010 rev 1.149: / 512 Mb in Aug 2005, formulas for other pertitions provided, / 256 Mb if RAMsize/harddisk size gives another value rev 1.106: / 120 Mb in Apr 2001 ...added by tens of Mbs before, not doubled So it doubles or fourths every 5 years, thus, to reserve, let's set / to 2 or 4 Gb in 2011. Also don't create /tmp partition but rather do: lrwxr-xr-x 1 root wheel - 12 9 Jan 2010 /tmp -> /var/tmp/tmp drwxrwxrwt 9 root wheel sunlnk 1024 23 Aug 16:55 /var/tmp/tmp Actually, this is just most simple short-term solution for auto-sizing. For long-term, it should be considered to merge / and /usr with separate partitions for ports, local, and so on, that's easy on ZFS. I have on 7.x: Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1.4G 1.1G 253M 81% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 4.4G 3.9G 66M 98% /home /dev/ad0s1e 6.8G 4.4G 1.9G 70% /usr/local /dev/ad0s1d 1.9G 1.4G 412M 77% /var devfs 1.0K 1.0K 0B 100% /var/named/dev lrwxr-xr-x 1 root wheel 13 29 ΔΕΛ 2009 /usr/obj -> local/BSD/obj lrwxr-xr-x 1 root wheel 15 29 ΔΕΛ 2009 /usr/ports -> local/BSD/ports lrwxr-xr-x 1 root wheel 13 29 ΔΕΛ 2009 /usr/src -> local/BSD/src but that will cause another long boring bikesched without clear final proposal :-) So for 9.0R it is simpler to take short-term approach. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight_at_mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]Received on Tue Aug 23 2011 - 08:03:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:17 UTC
