Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Jun 95 13:51:06 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        bde@zeta.org.au (Bruce Evans)
Cc:        bde@zeta.org.au, hlew@genome.Stanford.EDU, bugs@FreeBSD.ORG
Subject:   Re: 2.05R panics on boot
Message-ID:  <9506181951.AA18449@cs.weber.edu>
In-Reply-To: <199506180547.PAA15709@godzilla.zeta.org.au> from "Bruce Evans" at Jun 18, 95 03:47:18 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506181951.AA18449>