Date: Tue, 05 Sep 2000 07:40:47 -0700 From: "Kevin Oberman" <oberman@es.net> To: Siegbert Baude <siegbert.baude@gmx.de> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@FreeBSD.ORG> Subject: Re: Problems with slice setup in Fujitsu disk Message-ID: <200009051440.e85EelU13423@ptavv.es.net> In-Reply-To: Your message of "Sun, 03 Sep 2000 02:57:52 %2B0200." <39B1A210.999400BF@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sun, 03 Sep 2000 02:57:52 +0200 > From: Siegbert Baude <siegbert.baude@gmx.de> > Sender: owner-freebsd-questions@FreeBSD.ORG > > > Also, like many large disks, the number of > > sectors per track increases as you move to the outside of the disk > > from 286 to 502. The result is that it's really impossible to do CHS > > addressing. > > This is physically true, but your HD controller will hide this to your OS (at > least all disks I know work this way). You will have a constant number of > sectors (in LBA mode normally 255) over the whole disk logically. I am running LBA and the total number of sectors on the disk is not divisible by 255. And, when I boot up in verbose mode, I see that disk seems to have 63 sectors/track with 16 heads. ad2: 13029MB (26684784 sectors), 26473 cyls, 16 heads, 63 S/T, 512 B/S This will result in a disk capacity that is a multiple of 1008 sectors. And, this is exactly what I see. 26687808 is divisible by 1008 and the remaining space is < 1008, so it gets left behind. I suspect that it is all working as expected. It's too bad that even in LBA mode, the some part of the system insists on behaving like I have CHS addressing, as that wastes almost 400 KB. In any case, I am starting to feel that this is all a red herring and that my problem is with disk ad2, even though I can't find a problem with it. But the error logged by the kernel, "dscheck(#ad/0x20010)", makes me thing that the real problem is with disk ad2. I really would like to be able to decode those messages. > I wouldnīt agree with the latter. Partition tables and disklabels > are just numbers on the disk, which arenīt changed by the way a > driver is accessing. According to my experience, problems are > buried in the disklabels. Do you have another partition manager > software to verify your partition tables? I used for example Linux > fdisk (there is also a mini Linux distro fitting on a single floppy) > or Ranish Partition Manager (booted from a DOS floppy). I never > found an error in the partition tables, but had done dumb things to > my disklables. Is it possible to redo the whole procedure, > i.e. zero the first two sectors of your disk and redoing your fdisk > by hand from some existing system on a different HD? Using fdisk > manually will allow every correction you want, before it actually > writes anything to disk. I prefer this to some automagic, I donīt > understand. Yes, I can move all of my data over to ad0 and try setting up the ad2 disk from scratch. But I'd prefer to have a better idea of what's happening before I take this sort of step. > I really am running out of ideas, what happened to your disk. Some > weeks ago I put some questions on the list regarding the way the > kernel is recognizing disk mapping on boot time (as these are wrong > values for my disks) and fdisk behaving on extended partitions. But > got no answer, maybe because the questions were too long, or it was > the wrong list. So for now I donīt really understand whatīs going > on in the ata driver. Looked into the source, but got only some > limited answers due to my lack of C experience. I'm thinking of re-stating it in a shorter form. Maybe that will get someone more familiar with the disk drivers attention. > > But to be fair, I never noticed any errors in the use of my disk, so > the kernel and drivers can handle this situation somehow. Hope this > is at least a cold comfort. Other than my inability to use dd(1) to duplicate partitions, I have had no problems, either. It's just that dd(1) seems to be far the best tool for the job! Thanks again for your assistance and suggestions, R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009051440.e85EelU13423>