Date: Mon, 21 Apr 1997 11:16:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imp@village.org (Warner Losh) Cc: hackers@freebsd.org Subject: Re: disklabel -- owner? Message-ID: <199704211816.LAA13873@phaeton.artisoft.com> In-Reply-To: <E0wJ8H3-00013d-00@rover.village.org> from "Warner Losh" at Apr 20, 97 07:52:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : - 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. Actually, I *don't* like this. I think that bad block handling should be done as a seperate layer for logical-to-physical address translation, and stacked in devfs. This has an advantage that the bad block handling can apply to everything, instead of being just on a per-slice basis (but you could still stack it on a per slice basis if you wanted). I'd call such a logical-to-physical translation layer a "media perfection layer". BAD144 is just one type of media perfection. Running the SCSI stuff through software aids in things like maintaining spindle sync across disks in a stripe set... for that matter, a stripe set is a class of logical-to-physical mapping. > : - 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. Me neither; if it needs a FAQ, it's got a user interface design error that should be corrected instead of patched with a FAQ (this goes for everything for which FAQ's are available). > : - 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. Hmmmm... I still think the idea that disks have peculiar properties, other than how many sectors are available, is a bad meme to propagate. Everything that is not related to partition layout *should* be retrievable from the device via ioctl(), or it's not useful. Mostly it's not useful, since we have ZBR and can't make use of rotational information on any modern drives. > However, I want to have something that looks like [ ... rule set ... ] > 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. Yes; the disktab entries are presumably generated via a rules set, and we can presumably regenerate them on the fly by allpying the same rules set. If we can't, then disktab is internally inconsistant and should be done away with anyway. Either way, it should be a goner. > 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. Any chance you can seperate the UI from the actual code that does the work so that we aren't stuck with TCL on the install floppy? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704211816.LAA13873>