Date: Sun, 20 Apr 1997 12:42:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jbryant@tfs.net Cc: bakul@torrentnet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: disklabel -- owner? Message-ID: <199704201942.MAA08401@phaeton.artisoft.com> In-Reply-To: <199704201804.NAA25189@argus> from "Jim Bryant" at Apr 20, 97 01:04:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > - 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. > > there is nothing broke with disktab... what can you add that disktab > does not already have? heck most of the fields of disktab are not > properly used to begin with, such important things such as latency > usually go ignored by whoever writes disktab entries; maybe due to > lack of info from the manufacturer... > > second, never assume that i want your partition info, i may partition > my disks differently... such things as m-o disks to zip disks may be > safe assumptions, but on true hard disks, i want seperate /, /tmp, > /var, /home, /usr, and sometimes seperate /usr/local... and the sizes > i pick for each may indeed be different from the sizes you pick... I partially agree. I believe there should be no disk database whatsoever... there should be a "rule of thumb" based on memory size to pick a default size for swap, and another fuzzy limit for picking seperate or common root/usr, and another for picking "additional slices". The idea of a disktab dates back to when disk geometry tunables had to be communicated to the kernel by the user reading a manual for the disk, and then typing in data from that manual, and then the tunables would actually increase performance. Except in specific old hardware cases, where the disk geometry can't be obtained from the disk, these days are long gone, and best forgotton. The sector count information should be retrieved by ioctl()'ing the device driver to get back a count, then applying the rule set to come up with most of what disktab/other would have had in it anyway. Surely, there are rules of thumb for generating disktab entries, right? In any case, the partitioning tool ought to support space allocation based on expected needs for the selected installation type so you don't get partially through the install, only to realize /usr is 10M too small and / is 10M too big. This requires resizing intended allocations down when others go up, etc.., but it's based on sector count more than anything, and doesn't requie moving around data on a living FS. > > - It should allow *moving* a partition or a slice. > > good idea, why not an extend or shrink utility too? For an existing FS? Because you would need to re-newfs the thing, for one, unless you rewrote JFS (I have a part of a start on that; the PPC host environment I'm using is AIX; it's not likely to be more than read-only and "mostly" working any time soon). Not a day at the beach. Extending is both less and more problematic. It's less because you can pretty much safely do it, but it's more because once you do it, you now have to unscrew cylinder group and other allocation policies to prevent unequal fragmentation, etc.. Again, not a picnic. > > - You may want to look at some DOS/Windows disk tools for ideas. > > well... unrm? how about a defragger? I think you'd probably need a "fragger" first, otherwise it will never have anything to do and will die of boredom. 8-). 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?199704201942.MAA08401>