Question 39 long-life Intel S3510 SSDs, no data persistence

Toggle sidebar Toggle sidebar
HaziFlorinMarian

HaziFlorinMarian

Jun 27, 2023
5
0
10
Hello!
I am facing an at least bizarre problem with a massive number of Intel S3510 SSDs (39 units).
All SSDs are purchased at an auction from a major seller with an invoice and a guarantee that all SSDs still have 80-89% life according to S.M.A.R.T data, and that's it.
The problem I discovered, however, refers to the fact that all 39 SSDs work perfectly as long as their power supply is not interrupted (shutdown/reboot). After the reboot, the SSDs no longer have any partitions on them and, by default, no data.
I tested the SSDs with Ubuntu, Debian and Windows and all 3 OS have this problem.
Any suggestions?
I find it hard to believe that the seller was able to collect 39 ssds with the same problem in the first place.
I think I'm missing something, but I don't know what.
Thank you!

Some data:
Code: 
root@node03:~# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       INTEL SSDSC2BB012T6
        Serial Number:      PHWA602400GZ1P2JGN
        Firmware Revision:  G2010150
        Media Serial Num:
        Media Manufacturer:
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
        Used: unknown (minor revision code 0x0110)
        Supported: 9 8 7 6 5
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  2344225968
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:     1144641 MBytes
        device size with M = 1000*1000:     1200243 MBytes (1200 GB)
        cache/buffer size  = unknown
        Form Factor: 2.5 inch
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 1   Current = 1
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    unknown 119[6]
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
           *    SANITIZE feature set
           *    CRYPTO_SCRAMBLE_EXT command
           *    BLOCK_ERASE_EXT command
           *    Device encrypts all user data
           *    Data Set Management TRIM supported (limit 4 blocks)
           *    Deterministic read ZEROs after TRIM
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 55cd2e404c6d60c7
        NAA             : 5
        IEEE OUI        : 5cd2e4
        Unique ID       : 04c6d60c7
Checksum: correct
 
This:

"All SSDs are purchased at an auction from a major seller with an invoice and a guarantee that all SSDs still have 80-89% life according to S.M.A.R.T data, and that's it."

I think if "no data" then "no life".

Seller?

Have you contacted the seller re: the guarantee?

My thought is that a bad batch of SSD's were dumped.....
 
Ralston18 said:
This:

"All SSDs are purchased at an auction from a major seller with an invoice and a guarantee that all SSDs still have 80-89% life according to S.M.A.R.T data, and that's it."

I think if "no data" then "no life".

Seller?

Have you contacted the seller re: the guarantee?

My thought is that a bad batch of SSD's were dumped.....
Click to expand...
Hello!
First of all, thanks for the answer.
Then, I wrote to the seller this morning but I still have no answer.
Somehow I want to do more than wait for him because I would not like to return the batch of SSDs because they were bought at a good price.
The seller deals with the sale of used equipment at auctions, so I don't think there is a problem with selecting the components other than by their age (the SSDs have about 56,000 operating hours).
Somehow I find it hard to believe that there are 39 SSDs in one person who have exactly the same problem.
 
56,000 hours - over six years of operating use....

39 SSD's - same batch perhaps. The manufacturer's test samples failed (if there was any testing) and the whole batch of "X" number SSD's was dumped. In whole or in piecemeal. Maybe different places and sellers.

You received 39 of them.

Or all SSD's could be from the same counterfeit source.

Does each SSD have a unique serial number?
 
rgd1101 said:
how did you test them?
what os? test with another working pc?
Click to expand...
I installed Proxmox on 4 different nodes, each with 6 SSDs and all of them failed to boot.

Ralston18 said:
56,000 hours - over six years of operating use....

39 SSD's - same batch perhaps. The manufacturer's test samples failed (if there was any testing) and the whole batch of "X" number SSD's was dumped. In whole or in piecemeal. Maybe different places and sellers.

You received 39 of them.

Or all SSD's could be from the same counterfeit source.

Does each SSD have a unique serial number?
Click to expand...
Yes, SSDs are uniquely ID's. There is no problem of clones because the seller has very positive feedbacks and thousands of products sold at auction.
Even I bought from the same seller 10x 6TB 12Gbps HDDs (also with over 50K operating hours) and they work flawlessly (0 SMART errors and performance like new)
 
HaziFlorinMarian said:
All SSDs are purchased at an auction from a major seller with an invoice and a guarantee that all SSDs still have 80-89% life according to S.M.A.R.T data, and that's it.
The problem I discovered, however, refers to the fact that all 39 SSDs work perfectly as long as their power supply is not interrupted (shutdown/reboot). After the reboot, the SSDs no longer have any partitions on them and, by default, no data.
Any suggestions?
Click to expand...
Well .. since data retention problem doesn't show up in SMART,
they technically have sold you, what was promised.

They will probably fight you on your return attempt.
 
I discovered the problem!
Comparing the 9 functional SSDs with the other 30 non-functional ones, I found out with the `hdparm -I /dev/sdX' command that all the functional disks have the "not frozen" flag, while the other 30 have the "frozen" flag set.
Now the problem is...can it be that frozen removed if I don't have any password?
 
HaziFlorinMarian said:
I discovered the problem!
Comparing the 9 functional SSDs with the other 30 non-functional ones, I found out with the `hdparm -I /dev/sdX' command that all the functional disks have the "not frozen" flag, while the other 30 have the "frozen" flag set.
Now the problem is...can it be that frozen removed if I don't have any password?
Click to expand...
That's a red herring. All it means is that the BIOS, or Windows, has executed a SECURITY FREEZE LOCK command to prevent malware from setting a password on your drive. Your drive should still be readable and writable. That said, I don't understand why 9 SSDs are not frozen and 30 are frozen, unless you have them on different ports. I have two SATA SSDs in a Win 10 box. Both are frozen and fully functional.

I suspect that something is trashing sector 0. I have seen this problem on numerous occasions, but I have not been able to pinpoint a root cause. The common factor appears to be an AMD Ryzen Windows 10 platform.
 
Last edited:
HaziFlorinMarian said:
The issue has been fixed on all SSDs.
For some reason, the drives were sent in frozen state but I succeed to remove that flag using this tutorial https://grok.lsu.edu/article.aspx?articleid=16716 , excepting that I used caddy pull/push instead of sleep to make it work.
Click to expand...
I don't know what you think you did, but there is no "frozen" flag. The OS or BIOS issues a SECURITY FREEZE LOCK command, and the SSD or HDD then remains frozen until the next power cycle. In other words, the "flag" is reset when the drive is powered off. A secure erase achieves nothing except wasting one P/E cycle.

If you stick the drive in a USB enclosure, then neither the OS nor the BIOS can send this command to the drive, as it is now behind a USB-SATA bridge. Therefore it will remain unfrozen whenever it is inside the enclosure. Also, the bug (?) that is trashing LBA 0 may not manifest itself in USB-connected storage devices.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom