[9fans] using opendisk on a sd partition

["Michael Teichgräber" <mt@wmipf.in-berlin.de>]

Hi,

when opening a partition file of an sd disk with  `opendisk',
what am I supposed to get in disk->(c h s) -- the c/h/s value
of the underlying disk visible as `data', or rather a value
where `c' corresponds to the size of the partition (not of
the whole disk)?

If I have a disk interface containing `ctl', `data' and a
`plan9' partition, I get for instance c/h/s=8/16/32 when using
opendisk on `data', but c/h/s=7/16/32 using `plan9'.
[Initially I tried to disk/format a partition created by
disk/mbr on a very small disk, and noticed that the fat system
created did not cover the whole partition. To my surprise,
calling format with `-v' reported that smaller number of `c' above.]

Looking at partitiongeometry in libdisk/disk.c, values for
h and s are derived from the partition table of `data' (if
such a file is present).  Disk->c is calculated by dividing
the previously determined size of the opened file (disk->secs)
by h and s, so obviously this must result in different values
when doing opendisk("plan9") resp. opendisk("data").

http://9fans.net/archive/2000/10/140 describes a fix that was
introduced to allow the use of disk/* programs on partitions
containing uninitialized or invalid partition bootsectors. The
main part is the trick, that the pbs of `data', i.e. the mbr,
is loaded first, rather than the partition's own, perhaps
uninitialized, pbs.

The method how disk->c is calculated, remained the same:
disk->secs/((h+1)*s) -- meaning the number of cylinders covered
by the partition. For partitions spanning whole cylinders,
this value would be accurate, but it would be too small
for partitions that don't start (or end) at a cylinder boundary, like
often the first one, or partitions created by prep.

Maybe the number of cylinders of the whole disk is of no much
use when using opendisk on a partition, but, since the concept of
`c/h/s' in most(?) cases is related to a whole disk, wouldn't
that make more sense than a probably too small per-partition value
(which could, if needed, also be recalculated using disk->secs)?

Michael