From owner-freebsd-current Sun Dec 9 10:50:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id D334937B416 for ; Sun, 9 Dec 2001 10:50:44 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id TAA03571 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:50:43 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fB9Ik6H56560 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:46:06 +0100 (MET) (envelope-from j) Date: Sun, 9 Dec 2001 19:46:06 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011209194606.I97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <20011209102129.F97235@uriah.heep.sax.de> <44735.1007899299@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44735.1007899299@verdi.nethelp.no>; from sthaug@nethelp.no on Sun, Dec 09, 2001 at 01:01:39PM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As sthaug@nethelp.no wrote: > There are very good reasons NOT to use DD mode if you use certain > types of Adaptec SCSI controllers - they simply won't boot from DD. Never seen. All my SCSI controllers so far booted from my disks (obviously :). I figure from Peter's comment in that piece of code that the original (386BSD 0.0 inherited) DD mode fake fdisk table apparently had some poor (faked) values inside that could upset some BIOSes. That's bad, and IMHO we should fix what could be fixed, but without dropping that feature entirely (see below). Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. > Aside from that, FreeBSD needs to have *one* recommendation for > disks, anything else creates too much confusion. DD mode has never been a recommendation. It is for those who know what it means. I'm only against the idea to silently drop support for it... fdisk tables are something that has been designed in the previous millenium, and i think nobody is going to argue about it that they are rather a mis-design from the beginning (or even no design at all, but an ad-hoc implementation). Two different values for the same (which could become conflicting, thus making disks unportable between different controllers), not enough value space to even remotely cover the disks of our millenium, enforcement of something they call `geometry' which isn't even remotely related to the disks' geometry anymore at all, far too few possible entries anyway, ... FreeBSD is in a position where it doesn't strictly require the existence of such an obsoleted implementation detail, so we should users leave the freedom of decision. Again, it has never been the recommendation (well, at least not after 386BSD 0.0 :), and i normally wouldn't recommend it to the innocent user. But we should not break it either. > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you > used DD. [...]) As much as i personally prefer DD mode: that's an urban legend. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message