Date: Tue, 16 Jan 1996 18:12:10 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, miff@spam.frisbee.net.au, hackers@freebsd.org Subject: Re: location of bad144 table Message-ID: <199601160742.SAA28537@genesis.atrad.adelaide.edu.au> In-Reply-To: <199601160549.QAA02316@godzilla.zeta.org.au> from "Bruce Evans" at Jan 16, 96 04:49:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
(dig my home address out of the cc:'s 8) Bruce Evans stands accused of saying: > > >It would appear that the bad144 program still uses the 'c' partition, or > > No. > > >divines the end of the disk in a fashion different from the kernel code. > > Maybe. It attempts to screw up by always reading the label directly off > the disk (like the -r option to disklabel), but this is supposed to be > handled by modifying the label sector as it is read and written. The problem (?) here is that the label _on_the_disk_ has the "right" geometry in it, but the in-core disklabel has been screwed with to use the geometry reported by the controller (which is bogus). In this specific case, 'disklabel wd0' reports 1023 cylinders (wrong) but 'disklabel -r wd0' reports 1022 cylinders (right because I put it there). > >At least, bad144 runs without a slew of error messages, whilst attempting > >to read the disklabel once bad144 has been run results in much unhappiness. > ^^^^^^^^^ bad sector table? 'disklabel wd0' generates a plethora of errors. I expect that this is because the bad sector table is being read on first open of the device. Yes, it's complaining about not reading the bad sector table properly. Sorry for being obscure. 8( > Can bad144 read what it wrote? Yes. (this is why my comment about initialising the table, bad144 complained about a bad magic number on the table, and then went on to complain about a pile of duplicate replacements (its interpretation of the disk virgin value I expect) > Bruce The other reason I was pondering the whole 'c' partition thing was to do with autogenerating labels for slabs (of sectors) on FAT slices; the 'c' partition isn't actually terribly relevant there but I wasn't quite sure how I should implement it. What I have currently looks like this : - at the end of dsinit() a new function is called. This function walks the list of slices that dsinit has just assembled and looks for BIGDOS slices. - for each BIGDOS slice, the function looks for slabs. Slabs names are currently read from a file on the FAT filesystem. I don't like this, and will be moving to having a directory (BSD.PAR probably) that contains files called 'a', 'b' and so on. There will be limits on this directory, most likely that nothing else can live there and that the directory entries to be used must be in the first cluster of the directory. (This is bad, and would be on the 'fix this' list) - each slab is checked for contiguity, and if contiguous, is added to a disklabel structure - If no 'b' slab is found, the code looks for a /386spart.par file, and uses this, subject to validation. - If any partitions were found, the label is attached to the slice. Now you're all welcome to flame the crap outa me for this approach, but I think that this is worth the effort. Anyway, the relevance here is "what to do with the 'c' partition" in such a label? Should it refer to the whole FAT partition? Should it point to a small file that can be used for other purposes? Should it be zeroed out? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601160742.SAA28537>