From owner-freebsd-hackers Fri Jan 17 11:34:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA21542 for hackers-outgoing; Fri, 17 Jan 1997 11:34:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA21529 for ; Fri, 17 Jan 1997 11:34:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08867; Fri, 17 Jan 1997 12:17:12 -0700 From: Terry Lambert Message-Id: <199701171917.MAA08867@phaeton.artisoft.com> Subject: Re: mount -o async on a news servre To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 17 Jan 1997 12:17:12 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "J Wunsch" at Jan 16, 97 10:52:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Yes, 99.5 % of all disks claimed by the `sd' driver are non-removable. > > > It's often convenient to remember that the number of blocks appeared > > > in the boot message (and thus, in /var/log/messages), for later > > > reference. > > > The only reason "it's often convenient" is that tools like disklabel > > don't ioctl() the device to ask it for the information. > > UTSL. disklabel(8) can do this for you. Still, people are somtimes > happy to know that they can dig up this sort of information in the > syslog. > > If you're not among them, don't think everybody would instantly agree > with you. What good is the geometry information, except to rotational and seek latency operations on very old devices? You may be right that people would disagree with this. Let them write a tiny program to do the ioctl, and call it in their /etc/rc file, then. Or a PERL script, now that PERL is onerously mandatory as a layered system component anyway. The only things a user gives a damn about are: o How many bytes do I have available o How do I give the bytes to a particular OS They don't care about sectors, or cylinders, or any of that crap. So that crap should not be exposed in the user interface for the benefit of old fogies who can't learn how to run a disklabel without a disktab (I am an old fogie, but unlike other old fogies, my brain has not frozen in time). If users cared about cylinders (or if the tools cared about cylinders for them), then we wouldn't have users installing their OS out of range of the BIOS's ability to boot the blasted thing. As far as a partitioning tool goes, I'd be happy to have a nice colored content slider where I could move the slider left or right (I could even do this in a text version, using arrow keys) to decide how much of what goes where: Editing: DOS Primary Partition Table Partitions: 3 total out of 4 possible * = can't boot this partition Color ID Description Bytes Color ID Description Bytes |1| 05 DOS 262144 |5| |2| 06 DOS extended 196608 |6| |3| A5 FreeBSD 458752 |7| |4| |8| Remaining space: 131072 Total space: 1048576 ,-----------------------------------------------------------------------------. | 1 | 2 | 3 | | `-----------------------------------------------------------------------------' ^ | ------------------------------------------------------------------------------- Use '+'/'-' to pick what to edit Use 'Enter' to edit "ID" or "Bytes" Use ','/'.' to move 512 bytes Use '<'/'>' to move 5120 bytes Use 'A' to add a partition Use 'Del' to delete a partition Use 'S' to save Use 'Esc' to not save Clearly, the 512/5120 would vary by partition type; for instance, the value for DOS would reflect up/down a cylinder boundry, even though the disk geometry is not exposed. Also, clearly, this will only work on partitions which have not been recognized to contain a valid FS and which have a recognized ID. Attempting to edit otherwise will result in an "Are you sure?" confirmation dialog. An * would be displayed preceeding the byte count for partitions above physical cylinder 1024. For more than 8 partitions, I could: 1) pan the "Color/ID/Descrition/Bytes" table 2) blink the slider and get two more lines, remove the seperator line for the help and get aonther one, and collapse the total/remaining to one line to get another, and remove the blank line between the total/remaining an the table for another, and invert the "Color/ID/Description header and remove the blank line above it, using the inversion as the seperator. Note that this will fit on a 24 line display... Also, it should be obvious that I can iteratively apply this to DOS partitioning, DOS extended partitioning, and BSD "partitioning", ignoring the underlying implementation in favor of a picture. The BSD "partitioning" would be, for this example, another table just like this one, but with a "Total space" of 458752 bytes... I don't see a need for exported knowledge of the geometry. Be willing to learn for tools like "Partition Magic", even if they are "not invented here". In any case, it's a bug for the kernel to print an error when it can't detect the geometry of removable media that isn't inserted. You can argue that this isn't a bug. In which case I will argue that it is a bug for the kernel to *not* print an error when it can't detect the geometry of a floppy disk that isn't inserted (since it is a functionally identical device, differing only in amount that can be stored). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.