SandForce-based SSDs

  • Thread starter Thread starter Man-wai Chang
  • Start date Start date
A trimmed block is a /write/ sector - not an erase block.  Each erase
block contains many write sectors, and the SSD can do nothing with
unused write sectors until the entire erase block is unused.
Click to expand...

Ah, okay, so an erase block isn't the same as a single sector, it's
multiple sectors?
No, you cannot.

If the SSD uses internal encryption (some do, as do some hard disks,
without it being visible from the outside), then secure erase is just a
matter of changing the internal password and marking everything as
unused and recyclable.  This will be done very quickly.  But the actual
block erases will be done later.
Click to expand...

Well, isn't that just a matter of marking all sectors dirty and
unused, therefore just sending an erase command to all erase blocks?

Yousuf Khan
 
In the last episode of <[email protected]>,
David Brown said:
The SSD knows that a write sector is no longer needed in three ways.
One is by TRIM commands (this is the least useful way). Another is by
the logical sector being overwritten. And the third is when it has
copied the data to a new physical write sector as part of garbage
collection. Simply deleting the file does nothing to the sector on the
disk.
Click to expand...

Writing nulls to the drive may also trigger a "no longer needed" signal
to the drive's firmware. At least one of the hacks around drives that
don't support TRIM simply writes nulls to all otherwise unallocated
space.
 
The model I bought was introduced in early 2011, so it's been around 1
year already. The price cuts did make it attractive though. When doing
research, you're mainly looking at reviews, benchmarks, and optimization
advice. You rarely see problems crop up in reviews (perhaps they get the
cherry-picked units). You only notice the problems after you actually
get them yourself, and then do a search on the forums for this same
problem. The unit I have had already been flashed to the latest
firmware, and so it didn't seem like there should be any problems still,
but there was. Fortunately, I was able to discover the
solution/workaround myself.

Yousuf Khan
Click to expand...

Hold the presses! The actual reason for the problem has been pinpointed
inside the AHCI drivers now. The problem lay in an obscure power
management feature in the AHCI drivers that don't exist in the IDE
drivers, called the HIPM/DIPM attributes. HIPM means Host-Initiated
Power Management, while DIPM is Device-Initiated ... etc. Since the IDE
driver doesn't touch these features, it doesn't have any problem with
them. To avoid the problem you need to disable these completely on the
AHCI drivers.

You need to set a key in the Registry to allow this feature to be
accessed by the Power Management advanced options. You need to go to the
following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\0012ee47-9041-4b5d-9b77-535fba8b1442\0b2d69d7-a2a1-449c-9680-f91c70521c60

And set the "Attributes" field to a DWORD of 0x2.

You can then follow this article on what to do to disable it:

http://www.sevenforums.com/tutorials/177819-ahci-link-power-management-enable-hipm-dipm.html

I followed the article, and switched back to the AHCI drivers, and no
longer had any freeze-up problems.

Yousuf Khan
 
Back
Top