From owner-freebsd-bugs Sun Jun 18 12:58:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA00600 for bugs-outgoing; Sun, 18 Jun 1995 12:58:04 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA00594 for ; Sun, 18 Jun 1995 12:58:03 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA18449; Sun, 18 Jun 95 13:51:06 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506181951.AA18449@cs.weber.edu> Subject: Re: 2.05R panics on boot To: bde@zeta.org.au (Bruce Evans) Date: Sun, 18 Jun 95 13:51:06 MDT Cc: bde@zeta.org.au, hlew@genome.Stanford.EDU, bugs@FreeBSD.ORG In-Reply-To: <199506180547.PAA15709@godzilla.zeta.org.au> from "Bruce Evans" at Jun 18, 95 03:47:18 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.ORG Precedence: bulk > >So can DOS access more than 504MB per partition on SCSI drives? > > Yes, up to 8GB, provided the BIOS supports it (I haven't figured out how > to make my U34F or BT445C support more than 1024MB - they always use the > 64H 32S geometry). Modern EIDE BIOSes also support up to 8GB. Disk > managers are only required for old BIOSes. I think the key word there is "per partition". The answer is 2G, with 32k clusters. The DOS theoretical limit is 4G with 64k clusters, but in practice this introduces a conflict with the file truncation command (which is a standard write of 0 bytes at the truncation offset). The conflict arises from the inability to specify a transfer in excess of 65535 bytes, since the 0 is reserved, and thus a failure to transfer the full 64k (which you would do using a 0 token or a +1 to the requested amount). Now the DOS partitions themselves are limited by the 24 bit sector locator (C:10/H:8/S:6) on a translated geometry drive, limiting the representable geometry of the drive to 8G (assuming full translation). DOS, however accesses drives via DOS file system. > >Oh well.... I guess the only alternative is to swap the hard drive cables > >and redo the master/slave jumpers... :-( > > How would that help? You would still need Ontrack somewhere to use more > than 504MB for DOS on the big drive. Putting Ontrack somewhere apparently > affects everywhere. By manyally installing the OnTrack (assuming he has the disks) onto the second drive, he will cause BSD to see the OnTrack and (hopefully) react accordingly on the second drive. In point of fact, I would rather see the pfdisk output (as described in the previous post) before he goes ahead with this approach. There may be an unrecoverable (at present) BSD limitation that would prevent this from working. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.