Date: Mon, 10 Dec 2001 15:31:09 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Louis A. Mamakos" <louie@TransSys.COM>, Sheldon Hearn <sheldonh@starjuice.net>, Kirk McKusick <mckusick@beastie.mckusick.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <p05101009b83ac3d05b41@[128.113.24.47]> In-Reply-To: <200112080349.fB83nWU00292@apollo.backplane.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <p05101006b83737546907@[128.113.24.47]> <200112080349.fB83nWU00292@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:49 PM -0800 12/7/01, Matthew Dillon wrote: > Ok, I've finally gone and done it... cleaned up the sysinstall > 'Auto' option. Boy, and don't you just regret that! :-) > The jist of it is that I have added a bunch of DEFAULT and NOMINAL > partition sizes. DEFAULT is the target 'A'uto tries to achieve, > but if the disk is not large enough it will loop and scale the > auto partitions down based on a fraction of NOMINAL to DEFAULT. I > added "vn" to libdisk (not in this patch, just so I could test) > and did some tests and it appears to work quite well. (Note: if > using the VN device for testing you have to use file-backed rather > then swap-backed because sysinstall gets really confused when the > sector size is not 512). This all sounds very good to me. I think you've done the project a bit of a favor by trying to do this, and stirring up the discussion. > I also added two more 'typical' partitions: /var/tmp, and /home. I > have not done anything with /tmp yet but I recommend that we have > sysinstall create a softlink /tmp -> /var/tmp. > > I also fixed auto mode to not create more then 4G of swap. > > Auto now attempts to create the following partitions: > > / 128M > swap 2 x phys memory, 32MB minimum > /var 128M > /var/tmp 128M > /usr 3G max > /home all remaining space > > Of course, these are all #defines so we can argue about them > separately from comments on the patchset itself. Well, as you perhaps expected, I think most of the rest of the 328 messages in this thread are arguing about the #define's you happened to pick... :-) I think that is inevitable. We have had a frozen list of partitions and sizes for many years, and a list that everyone could agree was bad. They might not say it that way, but every time the default partitioning was discussed, it seemed that there wasn't anyone who actually USED the defaults. I know there must be some, but it always seemed to me that the vast majority of people would chime in with their own favorite layouts. I have my own favorite layout, which looks nothing like the above. I will not argue for my own favorite layout, because my layout is meant for a multi-boot system (switching between 4.x-stable and 5.x-current). Clearly that is not the right layout for "the average dumb user". I say that deliberately, since expert wizard users aren't going to be using ANY auto-partition defaults you come up with, unless you come up with exactly the defaults that they are already using. I do not like the idea of /tmp being a softlink into /var/tmp. I would prefer that to be a directory on /, so it will be there when one boots in single user mode. Please note that here I am giving a specific reason for my objection, and not just saying "Well, gee, *I* would *like* it some other way than what you happened to pick". Other than that, I could live with all of the above, particularly after including your additional change to auto-resize-on-delete. For the average user, they will be much better off with the above selections than with what sysinstall had been doing. While there has been a lot of arguing against your particular choices, I did not notice many people who argued that the CURRENT auto-partition behavior is better than what you proposed. From other messages in this thread, I think that your changes have inspired Jordan to work on some alternate ideas, and maybe those alternate ideas will be even better. Certainly that is possible, so I'd like to wait to see how those turn out. Still, I think *any* work on this area is long-overdue, and thus it's good to see it happening, even though we're probably going to beat ourselves up bloody trying to come up with the right defaults... :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101009b83ac3d05b41>