Date: 31 Oct 2000 18:19:04 -0500 From: Randell Jesup <rjesup@wgate.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Warner Losh <imp@village.org>, arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep Message-ID: <ybuog00k39z.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: John Baldwin's message of "Tue, 31 Oct 2000 11:31:23 -0800 (PST)" References: <XFMail.001031113123.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@FreeBSD.ORG> writes:
>> Before anyone asks, the biggest difference between my diskprep and
>> Matt's recent changes are that diskprep doesn't introduce a new api
>> into the kernel and doesn't pollute disklabel with functions it
>> traditionally hasn't done. Matt's changes put functionality into
>> edisklabel and the kernel.
>
>Actually, I would think that creating a virgin disklabel would be
>part of disklabel's job. After all, doesn't it make sense to use
>the disklabel program to create/edit disklabel's?
Yes. And it should. Right now disklabel (and many of the other
disk tools) are basically dusty decks - many of their defaults date back
several eons. Look at the default partitioning that's set up (the values
in /etc/disktab and the way it's used), etc. The last time an HD was added
to disktab was 1993 and it was a 100MB Conner. The documentation for fdisk
hasn't changed since 1996. Sysinstall sets the default newfs args to "-b
8192 -f 1024", even though there's a CVS note from 1999 that says
The default is still "-b 8192 -f 1024" but my experiments show that
"-b 16384 -f 4096 -c 100" is a more sensible value for modern
disksizes.
-b 8192 and -f 1024 (and -c 16) are still the defaults in newfs. You
get my drift - most of these defaults are wildly out-of-whack for even
vaguely semi-modern hardware. Admins need to tune all sorts of things
in order to get good setups - the defaults are insane. Fsck has all sorts
of brain damage when it comes to certain types of corruption requiring
someone to intimately understand ufs inode structures and on top of that
how to edit them in-place with crufty tools.
I don't feel we should just add more and more layers on top of
badly out-of-date tools. Fix the tools. Update the defaults. Add options
that are needed. Don't create Yet Another Semi-known Way to do something.
We have enough of those already.
IMHO
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
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?ybuog00k39z.fsf>