Date: Sun, 20 Apr 1997 19:52:09 -0600 From: Warner Losh <imp@village.org> To: hackers@freebsd.org Subject: Re: disklabel -- owner? Message-ID: <E0wJ8H3-00013d-00@rover.village.org> In-Reply-To: Your message of "Sun, 20 Apr 1997 09:27:58 EDT." <199704201327.JAA09993@chai.plexuscom.com> References: <199704201327.JAA09993@chai.plexuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199704201327.JAA09993@chai.plexuscom.com> Bakul Shah writes: : Doing it (mostly) _right_ is going to take time as you have to deal : with a lot of low level details.... Or else it can end up being : just different rather than an easy to use, idiot-proof program to : handle all your low level disk needs. Yes. I agree. That's why I've never actually done anything about this. : - Such a program should also handle newfs, disk scanning (to check : for bad blocks), update some parameters such as ARRE on scsi mode : pages etc. I like this idea. However, it is a v2.0 feature. : - It should try to infer some common things by looking at disk : blocks. Sort of like what file() does. I'm not sure I understand what this means. I mean what would I look at and do based on that? : - It should do some sanity checks. For IDE disks it should : cooperate with the BIOS in so far as possible. I never want to : see an `operating system not found' message right after an : install! Agreed. : - It should *explain* various actions and consequences of such : actions. A built-in FAQ would be handy. I'm not sure I understand this completely. : - It should allow you a practice run on a normal file. It should : also leave an audit trail so you can later try to figure out what : you did. It should also allow you to `replay' and modify a : previous run. I like this idea. : - It should be able to make use of a disk database -- not disktab : but something that describes the properties of various disks. : Sort of like a termcap, MIB or PPD. It will likely use disktab. However, they will only be considered hints rather than hard and fast rules. disktab does describe properties of various disks. However, I want to have something that looks like o root needs to be at least 20M, but no larger than 32M and about 2% of the whole disk. o /usr should be about 20% of the disk, not smaller than 100M or larger than 350M. o /var should be 20% of the disk. Add extra inodes here. o /home should eat the rest of the disk (ala the SunOS 'hog' parititon). But table driven so that others can have other rules of thumb. The above, btw, are bogus for many reasons. They are just an example of the ideas I'd like to have. Most of the disktab stuff would be ignored. I'd look just at the sizes and such. : - It should be easy to extend as disk manufacturers are going to : add some new kind of disk sooner or later, which will require : adding some code goop. No code should be required. Anything like this would be table driven. : - It should allow *moving* a partition or a slice. Beyond the scope of my time for some time to come, unless someone wants to fund this at my usual rate :-) : - You may want to look at some DOS/Windows disk tools for ideas. Yes. I've seen them. : May be what is needed is a frontend script that calls a number of : low level tools, each good at one thing. If so, then the tools need to be *MUCH* better than the ones we have right now. They are too crusty, imho. The bottom line is I'd like to take a new disk, point this tool at it and have it do the right thing. that's v1. I'd also like to be able to point it at a disk farm and say things like "OK, I'm moving /tmp to this disk, and also I wanna have a fairly large user area, what do you recommend?" and have it put a 100M /tmp and the rest be for /usr12 or whatever. There are those that say that ccd religion should be part of this too, and they are likely right. However, I wanna get something simple done for v1.0. To make Michael Smith happy, I'm going to try to do this with tcl and Tk with glue utilities as needed. Thanks for the suggestions. I'm hoping that once I punch a hole through the wall of this problem, that the pent up frustration will help expand the hole into a nice doorway that could eventually be integrated back into sysinstall, or its heirs, userpers or follow on programs. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0wJ8H3-00013d-00>