Date: Sun, 19 Nov 2000 18:41:37 -0600 (CST) From: FreeBSD <freebsd@KIWI-Computer.com> To: Greg Lehey <grog@lemis.com> Cc: Jason Spencer <jspencer@epsb.net>, stable@FreeBSD.ORG Subject: Re: Dedicated disks, et al. Message-ID: <200011200041.SAA30068@KIWI-Computer.com> In-Reply-To: <20001120095815.H58333@echunga.lemis.com> from Greg Lehey at "Nov 20, 2000 09:58:15 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> The problem is the bogus MBR that the DD writes confuses some > >> BIOSes and causes your disks to be non-bootable. So why don't we fix the bogus MBR so that we can still do DD? I'll offer to help. > This is really a problem that can be fixed. The argument currently is > that it's almost impossible to calculate the correct data, but that's > not true: if you can create a partition table, you can calculate it. Speaking of which, I should present an example. DD is "bad" for more reasons than just BIOS recognition. In response to the broken boot0 which got onto the 4.1-R CD, I downloaded the 1024-byte boot0 and overwrote the 512-byte which was shipped. At one time I accidentally wrote over a DD with boot0, thus losing the disklabel (only). The only thing I could do to fix the problem was to write a program which scanned the disk looking for valid superblocks, extract the valid partition offsets/lengths as well as CHS info, etc. and then create a new label which I wrote back on top of boot0. What I thought "dangerous" meant was that if you try to do what I did, you'll wipe your label. It would seem that a fix to make DD work for BIOSes would also allow the label to fit after boot0. So fix the bogus MBR... I also don't see the problem with the MBR, as even a DD has the 4 "slices" listed correctly, just that the entire drive is allocated as a single slice. > A real bandaid approach would be to create a correct partition table > and then mangle it to make the whole disk dedicated. Isn't this what is being done? The only difference I can see is that in non-DD mode the first few "partition map" sectors and the last sectors on the disk are unallocated, whereas in DD every sector is allocated. The problem I have with eliminating DD mode is that those last sectors never get used. My understanding is that they aren't used because the "DOS" partition map uses CHS numbers to point to the partitions instead of LBA. Those CHS numbers are hacked around until they better "fit" the drive (i.e. losing quite a few sectors at the end of the drive), thus allowing complete access to most of the sectors, rather than cutting off at ~8.4 GB. > >> The 4 slot table already is there in DD mode. It just happens to > >> contain completely bogus data. > > But it doesn't take up additional space. A real Microsoft layout > sacrifices the first "track" and up to a megabyte or so at the end of > the disk. I thought m$ fdisk only allocated cylinders so that you lose up to a cylinder at the end of the disk. Note that if you have a dedicated drive of FAT32, it uses all the sectors on the drive, not sacrificing the last <1 cylinder... IIRC. > It's only dangerous in the sense that it might not work. Once it > works, it will continue to work at least until you change the hardware > to which the disk is connected. I'd like to know which hardware (i.e. the BIOS) a DD won't work for. I've used pretty varied systems and they all seem to work with mixed DD and non-DD drives... > > One of my swap partitions shows up as a raw device and the other doesn't. > > I assume you're running -STABLE, in which case that's a benign > configuration error: they're both raw devices. Take a look at your > fstab and fix the "raw" device entry (rad2s1b -> ad2s1b). IS the "raw" entry the bad one? If so, then someone should change the /etc/rc code which enables swapping to a swapfile: #ptat -s Device 1K-blocks Used Avail Capacity Type /dev/da0s1b 7904 24 7880 0% Interleaved /dev/rvn0b 32640 0 32640 0% Interleaved Total 40544 24 40520 0% ... it should be "vn0b" instead of "rvn0b"??? --Rick C. Petty, aka Snoopy rick@kiwi-computer.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011200041.SAA30068>