Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!psuvax1!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!psgrain!nntp.cs.ubc.ca!news.bc.net!newsserver.sfu.ca!sfu.ca!vanepp From: vanepp@fraser.sfu.ca (Peter Van Epp) Newsgroups: comp.os.386bsd.development Subject: Re: FreeBSD 2.0: someone please fix mount_pcfs Date: 20 Aug 94 21:36:29 GMT Organization: Simon Fraser University Lines: 46 Message-ID: <vanepp.777418589@sfu.ca> References: <32uvui$dov@Venus.mcs.com> <331b5v$q00@u.cc.utah.edu> <331v11$kjs@news.u.washington.edu> <335mao$20r@u.cc.utah.edu> NNTP-Posting-Host: fraser.sfu.ca terry@cs.weber.edu (Terry Lambert) writes: >In article <331v11$kjs@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes: ... >] I'm not sure I understand the problem. Why can't the OS figure out the >] geometry by reading the partition map? MS-DOS partitions end on cylinder >] boundaries, and so by looking at the partition map entry for DOS the >] dos partition, you can figure out the number of sectors and heads >] that the BIOS reported to DOS when DOS fdisk created the DOS partition. >Because this presumes that the C/H/S values are non-commutative, which >would not be the case in 1 out of 4 circumsatnces where there are two >partitions on the disk and the translated geometry values for H and S >offsets for both partitions had two or more common multiplicative >factors. If that were the case, you would not be able to determine if >the factor belonged to the C or to the H. Perhaps I'm dense, but I still don't see a problem here. You are trying to read a DOS partition. The entry for the DOS partition in the partition table has a starting cyl head record, and an ending cyl head record for the partition as well as an absolute block count from the start of the disk for the start and end block of the partition. The end of partition HR values will give you the same number of heads, and the number of sectors that DOS int 13 ah=8 will give you. It will not give you the number of cylinders that DOS thinks are there for the whole disk, but I don't see that you care for this application. It will give you what cylinders DOS believes it owns in terms of its partition and what geometry DOS thinks exists in that partition (which is undoubtably important to pcfs). Since the disk driver knows what it thinks the geometry is, it can presumably map the DOS partition (using the blocks from sector 0 start and end values) into a CHR in the untranslated geometry. Presumably you would have to provide a piece of glue code between the pcfs code and the disk driver that did the translation both ways. So pcfs works in DOS values when dealing with the data in the DOS partition, but the disk driver sees the mapping from the DOS CHR into the equivelent CHR in the untranslated disk geometry to do the actual I/O to disk. Given this the geometry in other partitions on the disk appears to me irrelevant. You appear to have all the information required to do this mapping between the BSD disk label/kernel (for the untranslated geometry) and the DOS partition entry in the partition table (for the DOS geometry). Am I (like the original poster) missing something obvious? Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada