Date: Fri, 17 Jan 1997 12:17:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mount -o async on a news servre Message-ID: <199701171917.MAA08867@phaeton.artisoft.com> In-Reply-To: <Mutt.19970116225257.j@uriah.heep.sax.de> from "J Wunsch" at Jan 16, 97 10:52:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701171917.MAA08867>