SSD shown as 1073MB (instead of 256GB)

I've an issue with an SSD of mine. It's been a while since I haven't used it. I don't really remember what was on it (probably a linux distrib), I mostly used it to try stuff and boot random computers.

But now, I can't make it work properly. I plugged it with an USB 3.0 adapter, and, I can't get more than 1073MB of it (initially 240GO, sandisk SDSSDA-240G, SN: 153215405538).

So I only managed to create a partition of 1073MB using parted.

 Parted:

sudo parted /dev/sdb
(parted) print
Model: ATA SM2246AA-8 (scsi)
Disk /dev/sdb: 1073MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags 1 0,00B 1073MB 1073MB ext4

fdisk

sudo fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x500780cc.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Expert command (m for help): m
Command action b move beginning of data in a partition c change number of cylinders d print the raw data in the partition table e list extended partitions f fix partition order g create an IRIX (SGI) partition table h change number of heads i change the disk identifier m print this menu p print the partition table q quit without saving changes r return to main menu s change number of sectors/track v verify the partition table w write table to disk and exit
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdb: 34 heads, 61 sectors, 1010 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 00 0 0 0 0 0 0 0 0 00 2 00 0 0 0 0 0 0 0 0 00 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00
Expert command (m for help): v
Remaining 2096639 unallocated 512-byte sectors

Is it possible that the disk is physically damaged?

thx

3 Answers

Use the cfdisk utility. Enter cfdisk /dev/sdb from a root shell.

From there you can view, delete and edit partitions and see what Linux believes is the true capacity of the whole drive very easily.

If cfdisk tells you it's a 1073MByte SSD, try the following:

• It may not like your USB 3.0 adapter or your USB 3.0 adapter is defective. Was this working when connected to a SATA port? Try reconnecting it to a SATA port and see what cfdisk says then.

• Try applying a firmware update to your USB 3.0 adapter if possible (unlikely but possible). It would be strange for anything in the USB 3.0 generation to have issues with drive capacities (some older ones won't support >2TB disks, for example)

• If you plug this into a SATA port and cfdisk still tells you it's 1073MB in capacity, try updating the SSD firmware if Sandisk has one on their site. Then I would completely TRIM the drive with blkdiscard /dev/sdb Disclaimer: At this point any data on that disk is gone anyway and these steps will probably make anything on their completely unrecoverable.

• If no firmware update, do a security erase with hdparm and see if that helps. There's various other low-level reset options hdparm offers.

Disclaimer: Be 100% sure that you know your SSD's device before doing the above, especially if you do the blkdiscard or hdparm commands. Best to burn a live CD and work with only that drive connected via SATA if you get that far.

My best guess is, there's a short circuit on rom pins, and your ssd has booted into rom mode (or it can be named as engineering mode depending on the vendor). The 1024 mb you see is not the actual hdd but the flash/firmware area of your ssd.

Model: ATA SM2246AA-8 (scsi)

this means that your ssd is using an SMI2246AA nand controller with 8 chips installed, which only appears when it's in a state (recovery, engineering, safe mode??) other than standart

To fix it, you need to update the firmware of your ssd or upload a bootloader to it.

Based on the information you have supplied, you can here are some free tools on usbdev.ru or upantool.com to fix your hardware's flash/firmware. If these aren't good for you, you can try using PC-3000 hardware.

Why did this happen?

Unless you shorted some jumper pins, or soldered a pin, or erased the firmware on purpose, the above happens generally through voltage spikes (there's also a known bug in older versions of the firmware for sm2246aa controller, if you haven't updated the firmware, which was fixed later on newer versions).

I've heard of three causes of this type of problem:

• A dead disk -- I both heard of and seen USB flash drives that exhibit this problem and that become effectively dead as a result; I know of no way to fix them. An SSD might suffer from the same type of problem. If this is what's happened, your SSD is now effectively useless (or nearly so).
• A counterfeit disk -- Some unscrupulous parties sell disks (mainly USB flash drives) that claim to be size X, but are really size Y, where Y < X (by a wide margin). Sooner or later the buyer tries to store more than Y amount of data, at which point craziness ensues. It sounds like you've had the disk for a while and used it successfully, so this is probably not the case for you, but I thought I'd mention it in the interests of completeness.
• Use of HPA -- The Host Protected Area (HPA) is a section of a disk that you can set aside for special uses. When HPA is enabled, the disk appears to be smaller than it actually is. Sometimes it gets activated accidentally, which can produce problems like you're seeing. In Linux, you can type hdparm -N /dev/sdb as root (or using sudo) to see your disk's HPA status. You should see a sector count and a report that HPA is either enabled or disabled. If it's enabled, you can pass a new value with the -Np option, as in hdparm -Np 500000000 /dev/sdb, which sets the number of available sectors to 500,000,000 (precisely 256 GB). You'd probably want to take the total number of sectors from your original hdparm command, to match the exact size of your disk.

My suspicion is that you're dealing with a dead disk; I have seen reports of HPA problems appearing without the users knowing why, but in theory they should occur only if you'd been monkeying around with Linux's hdparm (or some equivalent low-level disk utility in another OS), and you haven't mentioned doing this.