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.
In the last episode (Aug 28), C. Michailidis said:> 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.For anything over a 9gb disk, I just make one big / partition. If you sub partition, you'll always end up filling one (either /var or /tmp quickly or /usr eventually) and wish you had picked different sizes. -- Dan Nelson dnelson@allantgroup.com
On Sunday 28 August 2005 11:37 pm, you wrote:> I don't really understand what you're so worked up about: if you don't > like the defaults, don't use them.Come on now, Dave. I know that you don't really mean this. You are not a zombie, are you? After all, 'like' is an analog, subjective term. There are various grades of likability. For example, I may like something a lot, I may like it just a bit, I may loathe it, or I may love it. I'm sure you can understand that it is not unreasonable to 'like' the default functionality, yet still see room for improvement in it. Right? In the real world, the mantra "don't use, what you don't like" cannot transcend boundaries, no improvements are ever made, and only a finite number of alternatives will ever be available. This is fine for some people, others make an effort to improve the situation. Of course this is much more of a philosophical issue that a technical one. I suppose I'm "worked up" because I am passionate about things that I really DO like - such as FreeBSD. Therefore, if I see something which I believe could use improvement, I take action to try and make that improvement happen. Although I greatly appreciate your response, I was hoping to receive a more technical perspective regarding people's thoughts on the alleged shortcoming. If your opinion is "I think the current functionality is fine" then so be it. Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... "Can the auto-configuration mechanism stand to be improved?". Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? When I looked at the code, it struck me that the 'defaults' aren't so much defaults as they are maximums for the default usage. It is my opinion that the typical end-user should not need to consider the nearly infinite number of ways to configure his or her filesystems. There is a 'best-practice' recommended by experts (e.g. create /, /var, /tmp, /usr) and it presumably should suit the majority of situations encountered. One day, in the near future, a new FreeBSD user will receive a disk drive as a gift that has a capacity in the terabyte range. They will then (unwittingly) proceed to do a very typical, default installation of FreeBSD, and end up with a 256MB /tmp! I'm actually sad to hear that you think this is acceptable. In fact, I think it is this kind of attitude that keeps open-source systems from being accepted by the population at large. Does your average fireman, police officer, accountant, doctor, lawyer, etc. want to think about how they will be laying out their filesystems when the reality is that a reasonable and typical layout could be done automatically?> But if you want to change it so the defaults are computed automatically, > submit a PR with your patches.I really wouldn't have a problem doing this. However, before I even begin thinking about implementing something, I'd like feedback from the community to insure that my reasoning is correct. This should help maximize the utility of the patches as well as the likelyhood that they are actually imported into the tree. For example, I thought that I heard sysinstall was being completely re-written by a Google-summer-of-code sponsored project, I may just be confusing this with something else. It would be an awful waste of time to implement a change twice or to completely botch something for mere lack of knowledge (especially when there is a vast pool of human knowledge to draw from such as this mailing list) Remember, the sysinstall program is used by almost every FreeBSD user to perform an installation... it isn't a piece of code you want to simply 'hack' at. I'm sure you have heard of the stories where a missing semicolon caused a 10 million dollar rocket to explode or a vital telecom network to black-out for hours (if not days) on end. I've lived through these types of stories and it has forced me to be much less capricious when I sit down to write a piece of code. As they say... "a stich in time, saves nine". -Dino *********************************** Walter Sobchak: GOD DAMN IT! Look, just because we're bereaved, that doesn't make us saps!
On ?? 17/08/29, at 12:30, C. Michailidis wrote:> [...] > 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.I can sympathize. I've been caught by bad partition sizes. But I never take the default sizes. In particular, I check the size of /var and its sub-partitions carefully. (Seems like nobody uses / tmp that heavily anymore, but /var/tmp gets hit a lot, and /var/log may need to be relatively huge, depending on what the system is doing, etc.) A partition "wizard" (I hate that term, but you know what I mean.) that would coach new users and remind old users about the effects of freeBSD layout on partition sizes would, I'm sure, be welcome, if you want to take the trouble. Mind you, simple ruled apportionment would not be sufficient. We would like to have sets of rules, one for a pure web server, one for a basic home-user websurfing, e-mailing, letter-writing coffee-table-top, several for different kinds of firewalls and bridges, ... And what about older disks, where cylinder sizes, number of reported heads, etc. were meaningful? No, that's probably not relevant except for RAIDs. (As long as I'm making demands on your time, why not think big? ;^) Anyway, it could be a useful project, but you'll want to recognize there's a lot of stuff hiding under the surface there. Joel Rees <rees@ddcom.co.jp> digitcom, inc. ???????? Kobe, Japan +81-78-672-8800 ** <http://www.ddcom.co.jp> **
From: C. Michailidis>[sysinstall FS sizing defaults]> > <...> 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?Probably, but a template for something like this isn't simple unless it's created as part of a general profile-based installer that would inform sysinstall of the machine's purpose in life. For example, a "workstation or Windows replacement" would need several extra GB in /usr whereas a server would get away with a much smaller /usr, but need those extra file-systems for logs, spools and other data. There are, however, some basic constants: If /usr, /var and /home are on another file-system, / doesn't need to be more than 150-200 MB. There just isn't that much in the root file-system. Assuming the default log retention and no spooling, /var will likely never grow past 50MB. Adding a mail, web, db or log server or increasing log retention will go well past that mark, but then such servers should have subordinate file-systems to handle the extra data. What comes with the OS will take less than 300MB in /usr. /usr/src and /usr/obj eat around 500 MB each. /usr/local eats around 1 GB for most servers and 3 GB on a desktop. /usr/X11R6 is empty if X isn't installed, the base Xorg server package is a few hundred MB and a desktop can need several GB. /usr/ports should have 1-2 GB just for distfiles on a desktop built from ports and 3 GB for work if you're building something huge, like KDE. I size /usr/ports to 6 GB on my desktop machines.