Bug 21675 - [patch] Better and more disktab entries for MO drives
Summary: [patch] Better and more disktab entries for MO drives
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-10-01 16:00 UTC by whs
Modified: 2017-12-31 22:37 UTC (History)
0 users

See Also:


Attachments
disktab.diff.gz (1.08 KB, text/plain)
2000-10-01 16:00 UTC, whs
no flags Details
disktab.diff (2.01 KB, patch)
2000-11-05 22:58 UTC, whs
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description whs 2000-10-01 16:00:01 UTC
Disktab entries for MO drives and a little info on how to use it. Very
useful, could also be put in sec 8.3 of the handbook.

Fix: This patch replaces an old entry (named after and IBM MO drive, but MO
disks can be used on any other MO drive) and adds 640MB formats.
Comment 1 whs 2000-11-05 22:58:33 UTC
Correction for the disktab diff (se was 2048 for a 512 byte medium in
the 230_max entry) and use of -m 0 in the newfs example. Plain diff (to
the original disktab entry of e.g. fbsd 3.3R or 4.1R) attached.

Wouter
Comment 2 Bruce Evans 2000-11-07 04:49:28 UTC
On Sun, 5 Nov 2000, W.H.Scholten wrote:

>  Correction for the disktab diff (se was 2048 for a 512 byte medium in
>  the 230_max entry) and use of -m 0 in the newfs example. Plain diff (to
>  the original disktab entry of e.g. fbsd 3.3R or 4.1R) attached.

See a recent thread about fixing disklabel(8) (actually about making
disklabel(8) easier to use).  There is no need for disktab entries
for drives that report their size to the driver, except possibly for
cloning a large number of identical drives with the same customized
label (the min* entries for floppies are a good example of this), but
customized labels belong in customized disktab files, not in the
standard one (the min* entries belong since they are used by the system
for building releases).

>  +# ---- 90 mm magneto optical disk formats (dedicated disk): ----
>  +# Prepare a disk as follows (e.g. using device da0):
>  +#	disklabel -B -w -r da0 mo230
>  +# or:
>  +#	disklabel -w -r da0 mo640
>  +# (the -B flag currrently doesn't work for 640 MB media).

The problem seems to be in disklabel(8).

>  +# and then:
>  +#	newfs -t 0 -u 0 -m 0 da0a
>  +# (t=0 and u=0 means the values from disklabel will be used for # tracks and
>  +# # sectors).

Are t and u worth forcing to the physical values for mo disks?  Are the
physical values actually physical?  I force t and u for floppies, but the
effects are mostly cosmetic (newfs doesn't really understand the weird
geometry of 1 track with 4096 sectors, especially on a disk with only
2880 sectors, and it prints confusing warnings which release engineers
have been ignoring for too long).

Bruce
Comment 3 whs 2000-11-07 15:57:45 UTC
Bruce Evans wrote:
> 
> On Sun, 5 Nov 2000, W.H.Scholten wrote:
> 
> >  Correction for the disktab diff (se was 2048 for a 512 byte medium in
> >  the 230_max entry) and use of -m 0 in the newfs example. Plain diff (to
> >  the original disktab entry of e.g. fbsd 3.3R or 4.1R) attached.
> 
> See a recent thread about fixing disklabel(8) (actually about making
> disklabel(8) easier to use).  There is no need for disktab entries
> for drives that report their size to the driver, except possibly for
> cloning a large number of identical drives with the same customized
> label (the min* entries for floppies are a good example of this), but
> customized labels belong in customized disktab files, not in the
> standard one (the min* entries belong since they are used by the system
> for building releases).

Well, as I said in my first report, this stuff could be put in the fbsd
documentation; there seems to be almost none. A problem is also bad
disktab entries that appear in various places and, not willing to dive
into the disklabel stuff, people (like me) try and they don't always
work, least not in current releases where disklabel seems more picky and
the error messages it spits out are unhelpfull to say the least (Weird:
writing such a label to a brand new disk works, writing it to a disk
that has been used before fails...). So, good examples are needed. Place
it in disktab or the docs (see also below about the 230_max/640_max
entries).

> >  +# ---- 90 mm magneto optical disk formats (dedicated disk): ----
> >  +# Prepare a disk as follows (e.g. using device da0):
> >  +#   disklabel -B -w -r da0 mo230
> >  +# or:
> >  +#   disklabel -w -r da0 mo640
> >  +# (the -B flag currrently doesn't work for 640 MB media).
> 
> The problem seems to be in disklabel(8).
> 
> >  +# and then:
> >  +#   newfs -t 0 -u 0 -m 0 da0a
> >  +# (t=0 and u=0 means the values from disklabel will be used for # tracks and
> >  +# # sectors).
> 
> Are t and u worth forcing to the physical values for mo disks?  Are the
> physical values actually physical?  I force t and u for floppies, but the

It makes a difference. If I don't use -t/-u then not all of the disk is
used with the 230_max/640_max disklabel entries. It's nothing to do with
physical formats, just using all available space on a disk (that's what
the 230_max/640_max entries are for, as the CHS format specified by the
drive does not use all available space).

Wouter
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:30 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped