[9fans] using opendisk on a sd partition

[9fans] using opendisk on a sd partition

[Michael Teichgräber]

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

Re: [9fans] using opendisk on a sd partition

[Russ Cox]

If you are calling opendisk on a non-"data" file, I would not
expect the c/h/s numbers to be meaningful at all.

I don't know that any of the programs except fdisk cares
about the c/h/s numbers, and in that case it is using the "data" file.

Russ

Re: [9fans] using opendisk on a sd partition

[Michael Teichgräber]

It seems that disk/format is using the c/h/s values under
a certain condition. If type is `hard' and you provide the -f
option (which I did following some examples), disk->c/h/s will
have an influence on the size of the created fat system:

	if(t->sectors == 0 && strcmp(type, "hard") == 0) {
		t->sectors = disk->s;
		t->heads = disk->h;
		t->tracks = disk->c;
	}

	...

	if(fflag){
		disk->size = t->bytes*t->sectors*t->heads*t->tracks;
		disk->secsize = t->bytes;
		disk->secs = disk->size / disk->secsize;
	}

I'm wondering whether `fflag' somehow is used with different
meanings in format.c. The first is explained for `-f' in the
man-page: don't low-level format a floppy, for other devices
it's a no-op. Moreover, in the context above it seems to
be used as `is-a-file' flag: The code makes sure that the
size-related members of `disk' are set to proper values, in case it
is perhaps a file that is too small to contain an image of the
selected fd type. Some lines later the file would be expanded
to meet disk->size. Perhaps the condition above should read

	if(disk->type == Tfile){

then -f resp. fflag would really be a no-op for non-floppy
devices (and disk->c would be ignored, while h and s still
are stored into the fat parameter block).

Michael