Re: 3100/80: 4G disk limit?

[Johnny Billquist <bqt%softjar.se@localhost>]

The 21-bit block addressing is just in the boot rom of *some* 3100 
models. I don't even think the /80 is among those. But as soon as the 
system have booted, you are not limited to that anyway, since then we're 
not using the boot rom drivers, but the ones in NetBSD.
So I can't see any reason the hardware would be a part of this.
Sounds very much more like a software problem.

Besides, 4G is not even an obvious limit anywhere. When we go to the 
10-byte (or larger) SCSI commands, the block addresses are 32 bits, 
which means the limit would be about 2TB.

But in software we are talking about disk addressing in bytes, so then 
4G is an obvious point where it can break.

  Johnny

On 2026-04-25 22:45, Mouse wrote:
> I've got a 3100/80.  It seems to work just fine booted diskless.  I
> found it already had a disk in it
>
> sd0 at scsibus0 target 1 lun 0: <SGI, SEAGATE ST31230N, 0532> SCSI2 0/direct fixed
> sd1: 1010 MB, 3992 cyl, 5 head, 103 sec, 512 bytes/sect x 2070235 sectors
>
> but the diskless root area I had is 2+ gigs.  So I added another disk
> to it, at ID 0; it now has
>
> sd0 at scsibus0 target 0 lun 0: <IBM, DCAS-34330, S60B> SCSI2 0/direct fixed
> sd0: 4134 MB, 8205 cyl, 6 head, 171 sec, 512 bytes/sect x 8467200 sectors
> sd0: sync (160.0ns offset 15), 8-bit (6.250MB/s) transfers, tagged queueing
> sd1 at scsibus0 target 1 lun 0: <SGI, SEAGATE ST31230N, 0532> SCSI2 0/direct fixed
> sd1: 1010 MB, 3992 cyl, 5 head, 103 sec, 512 bytes/sect x 2070235 sectors
> sd1: sync (160.0ns offset 15), 8-bit (6.250MB/s) transfers, tagged queueing
>
> I then labeled (now-)sd0, made a filesystem on it, and copied stuff to
> it.  I started seeing tons of filesystem corruption.  So I got
> suspicious and sicced my disk-check program on it.  That is a program
> that simply writes data such that each sector's contents identifies
> which sector it was written to.
>
> This revealed that it's wrapping at 4G.  Reading sector 0 gets the data
> written to sector 8388608 (1<<23), for example.
>
> My first thought was 6-byte CDBs.  But this is not the 6-byte CDB
> limit; that's at 1G (21 bits of sector address).  I thought maybe it
> had wrapped eight times, so I tried the disk-check program again,
> restricted to precisely the first 8388608 sectors; that was fine.
>
> This is under 1.6.2, which is old enough a 4G limit would not be all
> that implausible - but its off_t is 64-bit, and 1.4T (even earlier) on
> sparc has no such issues, making me think that any 4G limit is either
> hardware or MD code.  Before going looking at MD software, I figured
> I'd ask: does anyone know whether the hardware has any such limitation?
>
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>   X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol