Should RC6 provide me feedback if I'm scanning an SMR drive?

[himemsys]

Hi all,

I just purchased a Seagate BarraCuda 8TB (ST8000DM004) that uses SMR technology. From what I've read here, SpinRite RC6 should be SMR-aware, but I did not see any indication in the UI that it saw this drive as SMR. No warning if I selected level 3, nothing in the drive stats.

I've read here that SMR drives should only be run at level 2. Is this still the case? Is it safe to run at level 3 or higher? Not that I want to at this point, as it looks like it would take ~40 hours on level 3. Right now I'm running a level 2 scan (just to get a basic confirmation of drive health) and it's estimating ~11 hours.

Interestingly, when I benchmarked this drive, the front got ~200MB/s, middle got ~150MB/s, and end got ~80MB/s. What surprised me was the middle result. I expected it to be closer to the midpoint of 200 and 80.

Thank you for a great product! I've been a registered owner for about 14 years now!

 

[PHolder]

SMR has fairly fast reads but writes will cause it to slow down because of how the layering of the shingles works. If you run SpinRite at level 3 or higher, you will be causing writes, and it will very definitely cause the drive to work its hardest to do the rewriting of the shingles. Much like SSDs, the drive has data management that is more complex than simply calculating the correct track and rotation to find a LBA. It probably also has more RAM, so it can, if allowed, store in that RAM data on its way to the disk in hopes of saving work during sequential accesses. While this would work better for writing a single file to sequential LBAs, the way SpinRite is going to be accessing the drive, it's going be less helpful, and the drive is going to have to work even harder. Long story short, SMR is optimized for archival... for writing once and reading many and a utility like SpinRite is going to "stress" it ways more like random reads/writes would, which is going to make it run slow and work hard.

 

[Tazz]

IIRC, if you select Level 3 then select the SMR drive then hit 'Enter" to get to the next screen you'll get the warning, I think.
Somewhere along the line before the scan actually starts you should get a warning.

 

[ColbyBouma]

Correct. Here's a screenshot from an early Alpha:

 

[himemsys]

IIRC, if you select Level 3 then select the SMR drive then hit 'Enter" to get to the next screen you'll get the warning, I think.
Somewhere along the line before the scan actually starts you should get a warning.

That's what I expected, but I did not get a warning screen. I went ahead and let it start the level 3 scan just long enough to see the estimated scan time (~40 hours).

 

[ColbyBouma]

Some drives hide the fact that they're SMR. Do you still have your log files (SRLOGS folder on your flash drive)?

 

[himemsys]

Correct. Here's a screenshot from an early Alpha:View attachment 1040

Yeah, that's what I expected to see. I will try again this evening, but I'm thinking maybe SpinRite is not detecting that this particular drive model uses SMR.

For reference: https://www.tomshardware.com/reviews/seagate-barracuda-8tb-hdd-review

 

[Steve]

Yeah, that's what I expected to see. I will try again this evening, but I'm thinking maybe SpinRite is not detecting that this particular drive model uses SMR.

As the guy who implemented those screens I can assert with authority that what Colby said is correct: There are drives that (apparently) deliberately hide the fact that they are SMR drives.

SpinRite 6.1 does everything it can to find any clue that a drive may be SMR (or SSD) and will display that caution if it can find any trace of that. One thing that SMR drives would be expected to do, but apparently that Seagate does not, is to support and manage the “TRIM” state of their media just as SSDs do. If such a drive "knows" which regions of the media are storing data and which are not, a great deal of needless rewriting can be avoided. So SpinRite checks for support for TRIM, too.

In any event, there's nothing "wrong" with running SpinRite over an SMR drive at Level 3 or higher, it will likely just be much slower than CMR (conventional) drives since, in general, SMR drives will write more slowly. Note, also, that for a while SMR drives were "hybrid" with non-volatile CMR or SSD buffers on their front ends to "decouple" their slower writing speeds from the outside.

 

[himemsys]

As the guy who implemented those screens I can assert with authority that what Colby said is correct: There are drives that (apparently) deliberately hide the fact that they are SMR drives.

SpinRite 6.1 does everything it can to find any clue that a drive may be SMR (or SSD) and will display that caution if it can find any trace of that. One thing that SMR drives would be expected to do, but apparently that Seagate does not, is to support and manage the “TRIM” state of their media just as SSDs do. If such a drive "knows" which regions of the media are storing data and which are not, a great deal of needless rewriting can be avoided. So SpinRite checks for support for TRIM, too.

In any event, there's nothing "wrong" with running SpinRite over an SMR drive at Level 3 or higher, it will likely just be much slower than CMR (conventional) drives since, in general, SMR drives will write more slowly. Note, also, that for a while SMR drives were "hybrid" with non-volatile CMR or SSD buffers on their front ends to "decouple" their slower writing speeds from the outside.

Thanks, Steve. I thought I had read someone imply that running at level 3 or higher was not good to do, the implication being possible data loss or corruption due to the way the data is stored using SMR. Glad to hear that is not the case. And I'm not worried about this drive not being flagged as SMR. I know it is, and I know now that it wouldn't hurt the drive to do a level 3+ scan if I needed to. Nuff said.

Colby earlier asked for the SRLOGS. I snipped out the aborted runs. Here they are, if you're curious:

############################################################################
# SpinRite Detailed Technical Log generated at 11:29 am on Feb 6th, 2024. #
############################################################################
Release Candidate 6

Type|Port|BIOS|Runtime|Size| Model | Serial
----+----+----+-------+----+------------------------------+-------------------
ATA | TM | 80 | 321|120G|KINGSTON SA400S37120G |50026B778581F7E2
ATA | TS | 81 | 62|8.0T|ST8000DM004-2U9188 |ZR15J5HW

+==========================================================================+
| SpinRite 6.1, beginning level 2 operation at 12:00 pm on Feb 6th, 2024. |
|--------------------------------------------------------------------------|
| From 0.0000% sect: 0 To 100.0000% sect: 15,628,053,167 |
|==========================================================================|
| ST8000DM004-2U9188 |
|--------------------------------------------------------------------------|
| access mode: direct bus master serial number: ZR15J5HW |
| pci bus addr: 0:17:0 firmware rev: 0001 |
| adapter vendor: Advanced Micro rotation rate: 5400 |
| vendor-device: 1002-4390 ata/atapi spec: ATA-8 |
| bios drive: 81h drv technology: generic |
| controller reg: C000-C007h, B002h lba in use: yes, 48-bit LBA |
| bus master reg: 8000h |
| max transfer: serial 6.0 Gb/sec multi-word dma: -/2 (unknown md) |
| ultradma modes: 6/6 (133.3 MB/s) |
| sector count: 15,628,053,168 available pio: 4/4 (16.67 MB/s) |
| byte count: 8,001,563,222,016 |
| 4Ksec features: SMART SECURE POWR |
| transfers: 32,768 sector long ops: no : WCACH LOOKAHD HPA |
| ATA speed: 179,667,320 byte/s feature detail: 346B7D61 3469BC41 |
|==========================================================================|
| Level: 2 Graphic Status Display |
|==========================================================================|
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
|--- work ---- remaining --- completed +------- sector status key ---------|
| megabytes: 0.000 8,001,563 | .oO analyzing | R recovered |
| %: 0.000% 100.000%| . unprocessed | B defective |
| time: 0:00:00 14:30:36 | : processed | U unrecovered |
|==========================================================================|
| Final Sector Event Counts |
|--------------------------------------------------------------------------|
| command timeout: 0 command aborted: 0 |
| comm/cable errs: 0 not recoverable: 0 |
| minor troubles: 0 sect neverfound: 0 |
| dynastat recovr: 0 defective sectr: 0 |
|==========================================================================|
| End-of-Run SMART System Status |
|--------------------------------------------------------------------------|
| monitored param margin current/max raw data |
| ECC corrected 0 ::::::::::::::::::::::::...... 77/94 0000000C0A7400 |
| rd chan margin - |
| relocated sect 0 :::::::::::::::::::::::::::::: 90/90 00000000000000 |
| realloc events - |
| seek errors 0 :::::::::::::::::::::::::::::: 25/25 00000000A0274C |
| recal retries - |
| cabling errors 0 :::::::::::::::::::::::::::::: 200/200 00000000000000 |
| uncorrectable 0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
| write errors - |
| command timeout 0 :::::::::::::::::::::::::::::: 100/100 00000200020002 |
| pending sectors 0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
| read retries - |
| total writes 0 :::::::::::::::::::::::::::::: 100/100 000000CB06FD97 |
| write failures - |
| wear leveling - |
| remaining life - |
| realloc space - |
|--------------------------------------------------------------------------|
| drive temperature: 34'C/ 93'F |
|==========================================================================|
| SpinRite 6.1, level 2 operation completed at 2:31 am on Feb 7th, 2024. |
+==========================================================================+


+==========================================================================+
| Drive's Current Measured Performance |
|--------------------------------------------------------------------------|
| ST8000DM004-2U9188 |
| ZR15J5HW |
|--------------------------------------------------------------------------|
| smart polling delay: 121.833 msec |
| random sectors time: 17.380 msec |
| front of drive rate: 208.030 MB/s |
| midpoint drive rate: 179.394 MB/s |
| end of drive rate: 88.593 MB/s |
+==========================================================================+

 

[himemsys]

Exactly, people seem to think that SMR drives are identical to SSD in the sense that amount of writes is limited due to physical properties of the drive. At least that's what I sense some times.

For me, I thought that perhaps the overlapping tracks somehow introduced a variable that made reading and rewriting data a little more sketchy than with CMR technology. I didn't even make the connection that writes might be more limited than with CMR.

 

[jlee]

Interestingly, when I benchmarked this drive, the front got ~200MB/s, middle got ~150MB/s, and end got ~80MB/s. What surprised me was the middle result. I expected it to be closer to the midpoint of 200 and 80.

That's because halfway through the LBA range is not physically halfway from the spindle of the drive to the outer edge. The outer tracks hold more sectors per track than the inner tracks. That means that the halfway point in the LBA range is actually closer to the outer edge of the drive than it is to the spindle. And since it's closer to the outer edge than the spindle, the transfer speed at the LBA midpoint is closer to what you see at the outer edge than near the spindle.

Of course with SMR drives this is only true when the drive is new and the LBAs are mapped like they are on a CMR drive. With SMR drives after use LBAs can be anywhere on the drive which means that the transfer speed at the LBA midpoint can be anything between the transfer rates of the inner and outer tracks.

 

[himemsys]

That's because halfway through the LBA range is not physically halfway from the spindle of the drive to the outer edge. The outer tracks hold more sectors per track than the inner tracks. That means that the halfway point in the LBA range is actually closer to the outer edge of the drive than it is to the spindle. And since it's closer to the outer edge than the spindle, the transfer speed at the LBA midpoint is closer to what you see at the outer edge than near the spindle.

Of course with SMR drives this is only true when the drive is new and the LBAs are mapped like they are on a CMR drive. With SMR drives after use LBAs can be anywhere on the drive which means that the transfer speed at the LBA midpoint can be anything between the transfer rates of the inner and outer tracks.

The midpoint rate was actually even closer to the front of drive rate than I remembered:

| smart polling delay: 121.833 msec |
| random sectors time: 17.380 msec |
| front of drive rate: 208.030 MB/s |
| midpoint drive rate: 179.394 MB/s |
| end of drive rate: 88.593 MB/s |

I was aware of that, but it's good to get a reminder. What I meant was, typically on spinning drives, the midpoint transfer rate is roughly 60-70% of the front transfer rate. With *this* drive, the midpoint transfer rate is 86% of the front transfer rate. In other words, the transfer rate curve is shaped a bit differently than a typical spinning drive, with more of the first half of the drive shifted towards it's maximum transfer rate, and a bigger drop off from the midpoint to the end.

 

[Steve]

That's because halfway through the LBA range is not physically halfway from the spindle of the drive to the outer edge. The outer tracks hold more sectors per track than the inner tracks. That means that the halfway point in the LBA range is actually closer to the outer edge of the drive than it is to the spindle. And since it's closer to the outer edge than the spindle, the transfer speed at the LBA midpoint is closer to what you see at the outer edge than near the spindle.

Beautifully stated. VERY Nice and exactly correct!