Wrong sector size(s) set when unsupported block size passed to `openSeaChest_Format --formatUnit`

The Process

I tried to reformat a couple of Toshiba MG07SCA14TE SAS drives with the --formatUnit command:

root@truenas:~# openSeaChest_Format -d /dev/sg1 --formatUnit=4096 --fastFormat=1 --confirm this-will-erase-data

The Issue

Unfortunately I assumed 4Kn was supported and didn't check first.

The issue is that openSeaChest_Format didn't complain about the unsupported size and ran a format anyways. It looks like instead of selecting 4Kn or staying at 512e the tool chose the largest supported size, which ended up being 528.

root@truenas:~# openSeaChest_Format -d /dev/sg1 --showSupportedFormats
--------------------------------------------------------------------------------
 Logical Block Size  PI-0  PI-1  PI-2  PI-3  Relative Performance  Metadata Size
--------------------------------------------------------------------------------
                512     Y     ?     ?     N                   N/A            N/A
                520     Y     ?     ?     N                   N/A            N/A
*               528     Y     ?     ?     N                   N/A            N/A
--------------------------------------------------------------------------------

The physical sector size is also reported as changed, which seems strange to me(?).

Before the format:

Drive Capacity (TB/TiB): 14.00/12.73
Logical Sector Size (B): 512
Physical Sector Size (B): 4096

After the format:

Drive Capacity (TB/TiB): 13.93/12.67
Logical Sector Size (B): 528
Physical Sector Size (B): 4224

Now I have to reformat the drives (quick format not supported) to go back to full capacity and performance.

Suggested Change

I think the best way of handling this would be for openSeaChest_Format to refuse to attempt a format with a size not reported as being supported; and a flag to override if desired.

More Info

I update the drive firmware from 0102 to 0105 before running the format. I didn't powercycle the system between the firmware update and the format; which was dumb, but probably not the cause of the issue.

openSeaChest_Format Version: 3.0.4-6_2_0 X86_64

Full SATInfo:

/dev/sg1 - MG07SCA14TE - [SN] - 0105 - SCSI
        Vendor ID: TOSHIBA
        Model Number: MG07SCA14TE
        Serial Number:
        Firmware Revision: 0105
        World Wide Name: 5000039978119CC1
        Date Of Manufacture: Week 23, 2019
        Drive Capacity (TB/TiB): 13.93/12.67
        Temperature Data:
                Current Temperature (C): 34
                Highest Temperature (C): Not Reported
                Lowest Temperature (C): Not Reported
        Power On Time:  4 years 25 days 7 hours 34 minutes
        Power On Hours: 35647.57
        MaxLBA: 26382172159
        Native MaxLBA: Not Reported
        Logical Sector Size (B): 528
        Physical Sector Size (B): 4224
        Sector Alignment: 0
        Rotation Rate (RPM): 7200
        Form Factor: 3.5"
        Last DST information:
                DST has never been run
        Long Drive Self Test Time:  1 day 9 minutes
        Interface speed:
                Port 0
                        Max Speed (GB/s): 12.0
                        Negotiated Speed (Gb/s): 12.0
                Port 1
                        Max Speed (GB/s): 12.0
                        Negotiated Speed (Gb/s): Not Reported
        Annualized Workload Rate (TB/yr): Not Reported
        Total Bytes Read (B): Not Reported
        Total Bytes Written (B): Not Reported
        Encryption Support: Not Supported
        Cache Size (MiB): Not Reported
        Read Look-Ahead: Enabled
        Write Cache: Enabled
        SMART Status: Good
        ATA Security Information: Not Supported
        Firmware Download Support: Full, Segmented, Deferred
        Number of Logical Units: 1
        Specifications Supported:
                SPC-4
        Features Supported:
                Protection Type 1
                Protection Type 2
                Persistent Reservations
                Application Client Logging
                Self Test
                Automatic Write Reassignment [Enabled]
                Automatic Read Reassignment [Enabled]
                EPC [Enabled]
                Informational Exceptions [Mode 0]
                Translate Address
                Format Unit
                Sanitize
        Adapter Information:
                Adapter Type: PCI
                Vendor ID: 1000h
                Product ID: 00ACh
                Revision: 0001h

Hi @bandogora,

Sorry you ran into this weird behavior. I suspect the drive dropped to 528B automatically due to how the sector size change works on SAS and this behavior is not what Seagate drives do. This may be a Toshiba unique behavior to change to the largest sector size it supports instead of reporting an error for an invalid sector size.

On SAS drives you change the sector size by sending a mode select command with the block size set to your desired value as a number of bytes before starting the format unit command. If the drive does not support it, it is supposed to send back a check condition (error) indicating this is not allowed and openSeaChest_Format would have stopped there and reported the error rather than proceed onwards to a long format.

Since no error was given the drive accepted the command requesting 4K sector size and continued onwards to the format unit command...but never informed that it would actually format to a smaller sector size than you requested.

I think the best way of handling this would be for openSeaChest_Format to refuse to attempt a format with a size not reported as being supported; and a flag to override if desired.

This is not possible in most cases on SAS drives due to the way format unit historically works back to older SCSI days and even today. Not all vendors or firmwares even report the supported sizes back to the host. There was a log page added in the standards to report supported sector sizes and if that page is supported that could be used for validation before running the format, but I will need some more output from you to see if your drive supports this capability or not (and if you are willing to test this change that would be helpful because Seagate SAS drives do not currently support this page). I'm happy to add this additional lookup, it is not present only due to lack of support on drives I've been able to test so far.

Can you share the output of openSeaChest_Format --showSupportedFormats -v4 | tee verboseSupportedFormats.txt This command looks for this other page to see what sizes are supported, but if it is not found then the supported sizes output is generated based on what is historically supported on SAS devices.

The physical sector size is also reported as changed, which seems strange to me(?).

This is actually expected behavior. Running format unit commands to change sector sizes does change the physical sector size within the drive.

The way the sector size is reported is the logical block size is reported as a number of bytes. The physical sector size is reported as a power of 2 value for how many logical sectors are within the physical sector on the drive so it is always some multiple of the logical size presented to the host.

I update the drive firmware from 0102 to 0105 before running the format. I didn't powercycle the system between the firmware update and the format; which was dumb, but probably not the cause of the issue.

This would not cause your issue. If the firmware activated (segmented download mode or the deferred activation command was issued) then that firmware was already online and running.

Thank you for your response, it was very informative! This is my first time working with SAS and SCSI. I didn't relize reporting the supported sizes back to the host was so vendor dependant.

Here's the verbose log: verboseSupportedFormats.txt

@bandogora,

Thanks for the log!

It does not appear this drive supports that page of supported block lengths either (VPD page 84h) to add that additional lookup.

This is my first time working with SAS and SCSI. I didn't relize reporting the supported sizes back to the host was so vendor dependant.

I don't think this is necessarily a Vendor A vs Vendor B, but what the vendor chooses to support in firmware. The page in the standards called " Supported Block Lengths and Protection Types VPD page" (B4h) was added in SBC4 as an optional page. Whenever something in a standard is marked "optional" a vendor can choose to support it or not which leads to cases like this one you reported.

It could be that the vendor that sponsored this addition to the standard supports it in their firmware and others can choose to do it as well or not. I don't know which vendor made this addition though. A lot of times a vendor can come up with an idea and their customers want it but require it to be in a standard. Then that vendor proposes it, it gets reviewed and voted on and sometimes modified, then it's standardized. At that point any other vendor can also implement it to that definition, but it's not guaranteed to be picked up by others.

There is also another new command and VPD page called "Format with Preset" which is more like how NVMe formatting works. The drive reports descriptors of the formatting it supports (It also allows switching recording types if the firmware supports it: Ex CMR vs SMR) and then in that command software specifies which descriptor to use when formatting. openSeaChest does not currently support this mode of formatting but it is another thing we can look into in the future. If you do openSeaChest_Format -d <handle> -i there is some support to check if that command is supported or not as it will output "Format with Preset" in the supported features section. I don't see this reporting on this drive either though.

I wish I had a better answer for you to this issue! I know it is a pain to go through a long format only to have to start all over again. I'll see if I can come up with some other ideas to help validate this ahead of formatting.

If you have any other ideas, you think would be helpful from your standpoint, please let me know so I can look into those as well.

@vonericsen I can only think of one potential improvement if we can't validate supported formats.

We could have --formatUnit first send the command associated with --showSupportedFormats, then validate the requested sector size against that return.

This command looks for this other page to see what sizes are supported, but if it is not found then the supported sizes output is generated based on what is historically supported on SAS devices.

I'm not sure exactly how openSeaChest internals work, but if we can distinguish that the returned supported formats are actually just the historically supported formats we can give a warning to the user.

Something along the lines of:

This drive does not report it's supported formats. It might not return an error indicating the requested sector size is not allowed and proceed with the format anyways. If this is the case it may FORMAT TO A SIZE THAT WAS NOT REQUESTED.

Maybe also give these Toshiba drives as an example.

I would have still attempted the format with that warning, but I would have tried it with one drive first and saved some time.

I am a novice with SAS and these tools though, so I don't know if this is practical or even particularly useful.

Seagate / openSeaChest