Skip to content

Add support for drives larger than 2 TB (Closes: #1551)#1552

Merged
rdmark merged 1 commit intoPiSCSI:developfrom
cdhooper:huge_drive_support
Nov 18, 2025
Merged

Add support for drives larger than 2 TB (Closes: #1551)#1552
rdmark merged 1 commit intoPiSCSI:developfrom
cdhooper:huge_drive_support

Conversation

@cdhooper
Copy link
Copy Markdown

No description provided.

@cdhooper
Copy link
Copy Markdown
Author

Although some Amiga code correctly supports such large drives, it's pretty clear that not all code (HDToolBox) does:
amiga_piscsi_17tb_drive_devtest
amiga_piscsi_17tb_drive_hdtoolbox

Copy link
Copy Markdown
Member

@rdmark rdmark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution! This looks good at a code review level.

Have you tested building on a 32 bit system? We still want to support f.e. RPi 2 or Zero, and had some challenges with large ints in the past.

Comment on lines +294 to +297
uint64_t disk_blocks = GetBlockCount();
if (disk_blocks > 0xFFFFFFFF)
disk_blocks = 0xFFFFFFFF;
SetInt32(buf, 4, static_cast<uint32_t>(disk_blocks));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you see any side effects from "faking" the block size in the 6 byte ModeSense?

@cdhooper
Copy link
Copy Markdown
Author

I have not tested building on a 32-bit system, but will work to set one up to do so. I'll report back where when that has been tested.

As you likely know, Mode Sense (6) supports a 32-bit number for the maximum block count, where Mode Sense (10) supports a 64-bit number for the count. The Seagate SCSI Commands Reference Manual from 2016, has this to say about a "Short LBA mode parameter block descriptor" as returned by Mode Sense (6):

On a MODE SENSE command, if the number of logical blocks on the medium exceeds the maximum value that is able to be specified in the NUMBER OF LOGICAL BLOCKS field, the device server shall return a value of FFFFFFFh.

Similarly, the Read Capacity (10) command should return FFFFFFFFh if the capacity of the drive exceeds 2^32 sectors, and that a driver should then know to use Read Capacity (16) if it supports that command.

Regarding side effects, yes, I did see a funny one. The Read Capacity commands specify the value returned as the last addressable sector on the device. This means that typically, an application which uses the value returned by that command is going to add 1 to it to get the actual number of blocks on a given device. If the program is not aware of Read Capacity (16), and is not using greater than 32-bit math, then it might report to the user that the total number of sectors on the drive as 0. I don't view this as a huge problem, however. In that case, the legacy driver wouldn't correctly support the capacity of the drive anyway, so providing that driver with a device that is 2 ^ 32 sectors or larger wouldn't make sense from the user perspective.

@cdhooper
Copy link
Copy Markdown
Author

I put together a 32-bit Pi and have confirmed that PiSCSI with these changes do compile clean under 32-bit. If you would like me to test the 32-bit system, it will take about 30 hours, as the system I use for that work is currently testing another piece of hardware.

@rdmark
Copy link
Copy Markdown
Member

rdmark commented Nov 17, 2025

This is great, exactly what I wanted to know! Can you please add the Seagate reference manual quote (and related discussion) in the commit message? It really helps to have this in the commit log for future reference.

I kicked off a compilation of your PR code on my RPi Zero w. Let's see if it finishes over night.

Mode Sense (6) supports a 32-bit number for the maximum block count, where Mode Sense (10) supports a 64-bit number for the count. The Seagate SCSI Commands Reference Manual from 2016, has this to say about a "Short LBA mode parameter block descriptor" as returned by Mode Sense (6):

>  On a MODE SENSE command, if the number of logical blocks on the
>  medium exceeds the maximum value that is able to be specified in
>  the NUMBER OF LOGICAL BLOCKS field, the device server shall return
>  a value of FFFFFFFh.

Similarly, the Read Capacity (10) command should return FFFFFFFFh if the capacity of the drive exceeds 2^32 sectors, and that a driver should then know to use Read Capacity (16) if it supports that command.

There may be an unexpected side-effect if presenting a drive of more than 2^32 sectors to a legacy host that does not support devices that large. The Read Capacity commands specify the value returned as the last addressable sector on the device. This means that typically, an application which uses the value returned by that command is going to add 1 to it to get the actual number of blocks on a given device. If the program is not aware of Read Capacity (16), and is not using greater than 32-bit math, then it might report to the user that the total number of sectors on the drive as 0. I don't view this as a huge problem, however. In that case, the legacy driver wouldn't correctly support the capacity of the drive anyway, so providing that driver with a device that is 2 ^ 32 sectors or larger wouldn't make sense from the user perspective.
Copy link
Copy Markdown
Member

@rdmark rdmark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sanity test on an RPi Zero w was successful. LGTM!

@rdmark rdmark merged commit 25718e0 into PiSCSI:develop Nov 18, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants