Date: Tue, 16 Jan 1996 20:20:19 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, msmith@atrad.adelaide.edu.au Cc: hackers@FreeBSD.org, miff@spam.frisbee.net.au Subject: Re: location of bad144 table Message-ID: <199601160920.UAA11687@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >It would appear that the bad144 program ... >> >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). No. As I said, the label on the disk is supposed to be screwed with to make it appear to be identical with the in-core one. bad144 shouldn't work if the number of cylinders is too high. It is broken (i.e., it works but shouldn't) here too: dd if=/dev/zero of=/tmp/fs1440 bs=1440k count=1 vnconfig -s labels -c /dev/rvn0 /tmp/fs1440 disklabel /dev/rvn0 # shows size of whole disk (/dev/rvn0) is # 2880 sectors, as expected disklabel -w -r vn0 floppy5 # install a wrong label to avoid a # chicken and egg bug (the correct label, # `floppy3', would give a C partition of # maximal size and reducing the disk size # wouldn't work because the size of the # open C partition would be reduced) disklabel vn0 # shows size of compatibility slice # (/dev/rvn0c) is 2880 sectors, as expected disklabel -r vn0 # shows size of compatibility slice is # is 2400 sectors, NOT as expected disklabel -e vn0 # fix geometry to 36 sectors/cylinder, # 80 cylinders, 2880 sectors/unit. # Now disklabel -r gives consistent results # (not shown here) disklabel -e vn0 # emulate a buggy ESDI drive with 79 real # tracks: reduce to 79 cylinders and 2844 # sectors/unit. # Also, increase size of C partition to # 2844 so that bad144 can read the # "last" # track. # Now disklabel -r gives inconsistent # results again (not shown here). bad144 vn0 2>&1 |less # check that there is no bad144 table. # Bug: bad144 sees that there is no table # but it continues anyway and prints 126 # bogus spare sectors. bad144 vn0 1234 # initialize bad sector table with bogus # serial number 1234 bad144 vn0 # check that there is a bad144 table at # the right place. # It's at the wrong place (sector 2829 # = 2844 - 15. Should be at 2880 - 18. # 15 is because I forgot to change 15 # to 18 in the geometry. 2844 is because # of the coherency bug. >> >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( Almost all of the `disklabel vn0's above cause a kernel printf to tell you that the label isn't quite right :-). >> 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) Despite checking 2 magic numbers (one of them 0, so not very valuable), it always continues. In 4.4lite[2], both magic numbers are 0. I changed one of them back to the old value. --- >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. I don't think it 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? Don't use BSD labels for non-BSD partitions. The double layering of partitioning is only good for compatibility. Just use a slice for each slab. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601160920.UAA11687>