https://kcall.co.uk/ssd/index.html

               Everything I know about SSDs

Solid State Devices using NAND Flash, how they differ from
    Hard Drives, and how they affect file deletion and
                         recovery

March 2019:

 

Introduction:

I started writing this rather long page for my own
benefit, when I acquired a upgrade from my old 2006 Win 8
250 gb HDD PC to a Dell Optiflex 3010 with a 128 gb SSD. I
never used more than 30 or 40 gb of the system drive, and
I'm not a gamer or an avid film or music collector either.
Not on a PC anyway. As I played with my new kit the
further I went I realised that I knew very little about
NAND flash in SSDs, just how SSDs work, how do they read
and write and store data, and what sort of trickery do
they employ? I can visualise an HDD, writing tiny magnetic
patterns on a rotating surface, but SSDs are different,
vastly different.

There's also quite a few misconceptions about SSDs which
seem persistent, and it would be nice to examine them if
not perhaps quash a few of them. Perhaps I was guilty of
harbouring quite a few misconceptions myself. However it
started, this article grew into, shall we say, a mid-level
technical discussion. If all you need to know is that SSDs
are quiet, reliable, fast, and will work for years, then
there's no need to read any further. If however, you think
that knowing how to read a 3D TLC NAND flash cell is
interesting, then you have little option but to plough on.

As much of the detailed information as possible has been
sourced from corporate and private technical articles,
with quite a lot from Seagate and WD, and the wonderfully
named Flash Memory Summit. Some of the conclusions I've
made are from just trying to apply what logic I can along
with common sense. Such is the complexity of NAND flash
controllers, the variance in their methods of operation,
and the speed of their development, that trying to
comprehend let alone keep up with them is difficult to say
the least. I can't say whether what I've written isn't
confusing or is even true, but it's more of a guide than a
bible. There'll be some repetition too. And it will soon
be out of date.

I am obliged to those I have borrowed from, and will also
be obliged to those who point out any errors without any
reward apart from that of contribution. I've tried to
explain what is different with SSDs, and why it is so hard
to grasp with our ingrained HDD minds.

The first misconception might be the plural of SSD:
gramatically it should be, so I'm told, SSDs, but SSD's is
almost as commonplace. Here I will stick to one SSD, many
SSDs.

 

Software and hardware:

This article was written in 2019 onwards and deals almost
exclusively with NAND flash in the form of pc or laptop
storage devices we know as SSDs. I shan't complicate
things even more by referring to the ubiquitous flash
drive or other NAND flash devices. If significant
differences exist I shall try to note them as and when
that occurs, but the default is the internal drive.
Nowhere here is there anything about flash storage in
phones, etc.

Most of the detail was produced whilst my PC was running
Windows 10 Home, with a fairly modest internal 2.5" WD
Green 120 gb SSD. This uses a Silicon Motion SM2258XT
controller and four 32 GiB SanDisk 05497 032G 15nm 3D TLC
memory chips with an inbuilt SLC cache of unknown
capacity. As this article tries to discuss the behaviour
of SSDs as a whole it shouldn't matter what host operating
or file system is used, but in my case it's Windows and
NTFS. Nothing here is specific to a particular brand or
type of SSD, it should all be generic. We're really
dealing with the principles of SSD operation.

The only additional software applications I have used are
Piriform's excellent Recuva, which can list both live and
deleted files and their cluster allocations, and HexDen
(HxD), a very usable and capable hex editor. Recuva is
free from www.piriform.com, and HexDen is also free from
www.mh-nexus.de. I use the portable versions of both
pieces of software.

All the conclusions and opinions here are entirely my own
work, and any data taken from my own pc. It would be wise
to verify, or at least agree with my reasoning, before
accepting these words as the truth. Much of this is a
simplified explanation of a very complex subject.

 

SSD Physical Internals:

Poking inside an SSD is something of a disappointment, a
small pc board with a few NAND flash chips and a
controller chip, lightweight and a little flimsy. As for
the software inside the controller, I can only summarise
the basic tasks. It seems commonplace that controllers are
bought in from external manufacturers, as indeed are the
memory chips. SSD controller software is proprietary, very
complex and highly guarded, but all controllers have to do
basic tasks, even if we don't quite know how. Only those
tasks can be discussed here, the very clever tweaks and
tricks will have to remain known only to the manufacturer.
I'll start with a little groundwork.

 

NAND Flash:

I wasn't going to delve into the internals of NAND flash,
there are enough frankly bemusing articles on Wikipedia
for all that. All you really need to know is that NAND
(NOT-AND) flash memory stores information in arrays of
cells made from floating-gate transistors. The floating
gate can either have no charge of electrons, and be in an
'empty' logical state, or be charged with electrons at
various voltage thresholds and be in a logical state which
represents a value. NAND flash is non-volatile and retains
its state even when the SSD is not powered up. Oh yes,
it's called flash because a large chunk of cells can be
erased (flashed) at a time.

But if you want to know more, go ahead. Here the term cell
and transistor refer to the same physical entity and are
used interchangeably, and I won't keep saying NAND all the
time.

Flash memory comprises multiple two-dimensional arrays of
transistors, and supports three basic operations, read,
program (write) and erase. Apart from the flash arrays,
the flash chip includes command and status registers, a
control unit, decoders, analogue circuits, buffers, and
address and data buses. A separate chip holding the SSD
controller sends read, program, or erase commands to the
flash chip. In a read operation the controller passes the
physical address to the flash chip which locates the data
and sends it back to the controller. in a program
operation the data and physical address are passed to the
chip. In an erase operation, only the physical address is
passed to the chip.

The flash chip's latches store data transferred to and from
the flash arrays, and the sense amplifiers detect bit line
voltages during read operations. The controller monitors
the command sent to the chip using the status register.
The controller also includes Error Checking and Correction
(EEC) algorithms to manage error and reliability issues in
the chip and to ensure that correct data is read or
written.

Each row of an array is connected by a Word line, and each
column by a Bit line. At the intersection of a row and
column is a Floating Gate Transistor, or cell, where the
logical data is stored. Word lines are connected to the
transistors in parallel, and bit lines in series. The ends
of the bit lines are connected to sense amplifiers.

Flash arrays are partitioned into blocks, and blocks are
divided into pages. Within a block the cells connected to
each word line constitute a page. The cells connected to
the bit lines give the number of pages in a block. Common
page sizes are 4k, 8k or 16k, with 128 to 256 pages making
a block size between 512k and 4mb. A page is the smallest
granularity of data that can be addressed by the chip
control unit.

Read or program operations involve the chip controller
selecting the relevant block using the block decoder, then
selecting a page in the block using the page decoder. The
chip controller is also responsible for activating the
correct analogue circuitry to generate the voltages needed
for program and erase operations.

Although the number of cells in each row is nominally
equivalent to the page size, the actual number of cells in
each row is higher than the stated capacity of each page.
This is because each page contains a set of spare cells as
well as data cells. The spare cells store the ECC bits for
that page as well as the physical to logical address
mapping for the page. The controller may also save
additional metadata information about the page in the
spare area. During a read operation, the entire page
(including the bits in the spare area) is transmitted to
the controller. The ECC logic in the controller checks and
correct the read data. During a program operation the
controller transmits both the user data and the ECC bits
to the flash memory.

Upon system boot the controller scans the spare area of
each page in the entire flash array to load the logical to
physical address mapping into its own memory (there may be
other techiques for holding mapping data in the
controller). The controller holds the logical to physical
address mapping in the Flash Translation Layer (FTL). The
FTL also performs garbage collection to clear invalid
pages following writes, and performs wear-leveling to
ensure that all the flash blocks are used, evenly.

Since flash does not support in-place updates, a page
needs to be erased before its contents can be programmed;
but unlike a program or a read operation which work at a
page granularity, the erase operation is performed at a
block granularity.

 

2D and 3D, and Layers:

In flash architecture a block of planar flash, a
two-dimensional array of cells, is rather unsurprisingly
called 2D flash. If one (or more) array is stacked on top
of each other then it's 3D flash. 3D NAND flash is built
on one chip, up to 32 layers, and was devised to drive
costs down when planar flash reached its scaling limit: 3D
flash costs little more than 2D to produce, but multiplies
the storage capacity immensely. In both 2D and 3D the
cells in each page (the rows) are connected by Word Lines,
and the cells at each offset within a page (the columns)
are connected with a Bit Line (to put it very simply).

3D flash is not the same as layered flash, where separate
very thin chips are arranged in a stack. This is
prohibitively expensive. Most modern consumer SSDs (in the
2010's) use 3D TLC flash.

 

Can I see one?

The cell size on end-user flash is minute, with 15nm being
common, and ranges from 43nm down to 12nm. Actually cell
size, or cell diameter, is misleading, as the stated size
is not a measurement of any dimension of a cell but a
measure of the distance between discrete components on the
chip. The silicon layers on the chip are approximately 0.5
to 3nm thick: by comparison a hydrogen atom is 0.1nm in
diameter, and the silicon atoms used in chip manufacture
0.2nm. A nanometre (nm) is indeed exceedingly small, a
billionth of a metre, and as an analogy if one mn were the
size of a standard marble (about 13mm) then one metre
would be the size of the earth. The power of a billion is
impressive.

 

SLC, MLC, TLC, QLC and Beyond:

A Single-Level Cell (SLC) has one threshold of electron
charge to indicate the state of one bit, one or zero. A
Multi-Level Cell (MLC) holds a voltage denoting the state
of two bits, with three different thresholds representing
11, 10, 00 and 01. A Triple-Level Cell (TLC) holds the
state of three bits, 111, 110, 100, 101, 001, 000, 010,
and 011. The 15 thresholds used in Quad-level cells (QLC)
can be deduced if anyone is at all interested. (I have
seen other variations of what these threshold values
represent in bit terms.)

Unfortunately when the double level cell was developed it
was called a multi-level cell and given the acronym MLC,
thus forcing everyone to type out multi-level cell
laboriously when they want to refer to multiple level
cells. If only it had been called a double-level cell we
could use DLC, TLC, and QLC freely and use MLC to describe
the lot, but it's too late for that now. If only flash had
stopped at SLC, with its yes/no one/zero state, these
explanations would be far easier to write, and hopefully
far easier to grasp.

With multi-level cells physical NAND pages represent two
or more logical pages. The two bits belonging to a MLC are
separately mapped to two logical pages. Odd numbered pages
(including zero) are mapped to the least significant (RH)
bit, and even numbered pages are mapped to the most
significant (LH) bit. Similarly, the three bits belonging
to a TLC are separately mapped to three logical pages, and
a QLC is mapped to four logical pages (The page numbering
for TLC and QLC is unknown).

The more bits a multi-level cell has to support affects
the cell's performance. With SLC the controller only has
to check if one threshold has been exceeded. With MLC the
cell can have four values, with TLC eight, and QLC 16.
Reading the correct value of the cell requires the SSD
controller to use precise voltages and multiple reads to
ascertain the charge in the cell. It's also apparent that
if a single physical page supports multiple logical pages
then that page will be read and written more frequently
than a SLC page, with consequent affect on its life
expectancy. Furthermore it would seem self-evident that a
TLC SSD would need only a third of the physical cells
required in an SLC device, so my 120 gb TLC SSD would
actually hold only 40 gb of NAND cells.

High-use enterprise SSDs used to be the province of the
SLC, with it's greater speed, endurance, reliability and
read/write capabilities, MLC and TLC are gaining
acceptance for enterprise use. The end-user consumer SSD
market gets the cheaper higher capacity but slower and
more fragile multiple level cells.

 

Why is Nothing One?

Anyone still following this may have noticed a common
factor in both single and multi-level cells, in that an
empty cell - where the floating gate has no charge -
represents one. Unlike HDDs, where any bit pattern can be
written anywhere, a default logical state of ones is
present on an empty SSD page. This is because there is
only one programming function on the cells, to move
electrons across the floating gate. NAND flash cells can
only be programmed to a state of zero, there is no ability
to program a one. With multi-level calls the default is
still one across all pages, but a logical one can be
represented even after the cell has been programmed and
there are electrons present across the gate.

Ever since Fibonacci introduced the Hindu-Arabic numeral
system with its concept of zero into European mathematics
in 1202, the human mind associates zero with empty and one
with full. To be empty and represent one is rather
perplexing, and appears to be mainly from convention (an
empty state could represent zero but would required
inverters on the data lines). Possibly the circuitry is
less complex, and possibly the ability of an empty cell to
conduct a charge implies that it is a one.

 

They're all SLC anyway:

After all this it's perhaps worth emphasising that NAND
flash, whatever its intended use, is all physically SLC.
If you could look into a TLC cell you wouldn't see 101, or
011, or whatever. There can only ever be one quantity of
electrons in a cell, no matter how that quantity is
interpreted. The SSD controller knows whether the cells
are to be treated as SLC, MLC etc and programs them
accordingly, measures the electron count, and determines
what logical value it represents. But even quad cells can
only contain one value, just as do SLC cells.

 

The Myths and Misconceptions:

And now we come to the myths, misconceptions and the real
reason for writing this article, what happens when an SSD
page is read, written and rewritten, and how does this
affect deleted file recovery? On one hand we have NTFS,
designed specifically for HDDs way before SSDs became
easily available, NAND flash with its own unique way of
operating, and several billion humans with years of
ingrained HDD use and expectations. And here, if I haven't
already, I shall use SSD interchangeably if incorrectly
for NAND flash.

 

Storage Device Controllers:

All HDDs, SSDs and flash drives have an internal
controller. It's the way that the storage device can be,
in the words of Microsoft, abstracted from the host. That
abstraction is done by logical block addressing, where
each cluster capable of being addressed on the storage
device is known to the host by an ascending number (the
LBA). The storage device controller maps that number to
the sectors or pages on the device. To the host this
mapping is constant - a cluster remains mapped to the same
LBA until the host changes it. On an HDD this relationship
is physical and fixed: in its simplist deconstruction an
HDD controller just reads and writes whatever sectors the
host asks it to. It doesn't have to think about what was
there before, it just does what it's told and writes new
data on top of the old. It does that because it can,
there's nothing preventing a new cluster being written
directly on top of the same sectors of an old one. On an
SSD it's different.

With an SSD the host still uses the LBA addressing system
with the constant reconciliation between LBA and cluster
number. It knows that the device is a SSD and has a few
tricks to accommodate this, but they will come later. The
SSD controller however has many tricks to reconcile the
host's file system, written for HDDs, with the demands of
NAND flash.

 

Flash Translation Layer:

The host still uses LBA addressing to address the SSD for
read and writes, as it knows no other. These commands are
intercepted by the Flash Translation Layer on the SSD
controller. The FTL maintains a map of LBAs to physical
block addresses, and and passes the translated PBA to the
controller. This map is required because unlike an HDD the
LBA to PBA relationship is volatile. It's volatile because
of the way data is written to NAND flash.

An empty page, with all cells uncharged, contains by
default all ones. If a hex editor is used to look at an
SSD's empty sectors however, it will be presented with
clusters of zeroes. This is because empty pages are not
allocated to the LBA/PBA mapping table. Instead, if a read
request is issued for an empty page a default page of
zeroes is returned. This applies to both unallocated
clusters and those which are part of a file: the SSD does
not allocate a page and change all its cells from ones to
zeroes.

 

Floating Gate Transistors:

This section might be helpful before plunging into reads
and writes, and here cell and (FG)transistor become
interchangable (a cell is a transistor). For more, much
more, about floating gate MOSFET
(Metal-Oxide-Semiconductor Field-Effect Transistors) there
is always Wikipedia.

A FGMOS transistor has three terminals, gate, drain, and
source. When a voltage is applied to the gate a current
can flow from the source to the drain. Low voltages
applied to the gate cause the voltage flowing from source
to drain to vary proportionally to the gate voltage. At a
higher voltage the proportional response stops and the
gate closes regardless.

The charge in the floating gate alters the voltage
threshold of the transistor, i.e. at what point the gate
will close. When the gate voltage is above a certain
value, around 0.5 V, the gate will always close. When the
voltage is below this value, the closing of the gate is
determined by the floating gate voltage.

If the floating gate has no charge then a low voltage
applied to the gate closes the gate and allows current to
flow from source to drain. If the floating gate has a
charge then a higher voltage needs to be applied to the
gate for it to close and current to flow. The charge in
the floating gate changes how much voltage must be applied
to the gate in order for it to close and conduct.

 

SSD Reads:

There's nothing inherent in the design of NAND flash that
prevents reading and writing to and from individual cells.
However in line with NAND flash's design goal to be simple
and small the standard commands that NAND chips accept are
structured such that a page is the smallest addressable
unit. This eliminates space that would be needed to hold
additional instructions and cell-to-page maps.

To read a single page, and the cells within it, the page
needs to be isolated from the other pages within the
block. To do this the pages not being read are temporarily
disabled.

All cells/transistors in the same block row (a page) are
connected in parallel with a Word Line to the transistors'
gates. All transistors in the same block column (cell
offset) are chained in series with a Bit Line connecting
the drain of one to the source of the next. At the end of
each bit line is a sense amplifier. When a read takes
place a pass-through voltage is applied to all word lines
except the page being read. The pass-through voltage is
close to or higher than the highest possible threshold
voltage and forces the transistors in all pages not being
read to close whether they have a stored charge or not.
All bit lines are energised with a low current.

The word line for the page being read is given a reference
voltage, and all the bit line sense amplifiers read.
Transistors holding a high enough electron count will not
be closed by the reference voltage, and the bit line
current will not pass through the source/drain chain to
the sense amplifier. Transistors with no charge, or a
charge below the threshold, will be closed by the
reference voltage and conduct the bit line current to the
sense amplifier. Several reads at varying threshold
voltages are required to determine the logical state of a
multi-level cell.

(To add, or avoid, more confusion a floating gate
transistor can be either open or closed. An open gate does
not conduct an electrical charge, and a closed gate does.
So if the gate is open nothing can get through, and if
it's closed it can. No wonder we're confused.)

It can be seen from this that to read one page in a block
requires that all transistors in every page in the block
receive either a pass-through or one or more reference
voltages. It also appears that this will still apply even
if some or all of the other pages in the block are empty.
This becomes significant in Read Disturbance below.

 

Interpreting the results:

It is quite easy to grasp the concept behind reading an
SLC. Only one threshold applies to SLC flash so only one
test voltage is required - the floating gate either will
or will not close. if the threshold voltage closes the
gate then the bit line current passes to the sense
amplifier and the stored value is one. If it doesn't then
it's zero.

Multi-level cells are different, and the reasoning behind
the stored value bit order becomes apparent. In a MLC the
possible user bit combinations are 11, 10, 00 and 01,
separated by three threshold values. To read the most
significant (l/h) bit only requires one read, of the
middle threshold voltage. If the gate closes then the MSB
is one, if it doesn't then the MSB is zero, no matter what
is in the least significant bit. To read the LSB (r/h) two
reads are required, one of threshold one, and one of
threshold three. If the read of threshold one closes the
gate then the LSB is set to one and read two is not
required. If the gate opens then a read of threshold three
is taken. If it closes the LSB is set to zero. If it
doesn't then the value is one.

The bit combinations in TLC cells are 111, 110, 100, 101,
001, 000, 010, and 011, separated by seven threshold
values, and are more tricky to grasp. The MSB bit again
only requires one read of the middle threshold, as in MLC.
The central bit requires two reads, at threshold two and
six, and the LSB requires four reads, at thresholds one,
three, five and seven.

All multi-cell pages based on the MSB (l/h) are treated as
SLC, with only one read required to determine the user bit
value.

 

SSD Writes:

The most significant aspect of NAND flash, the widest fork
in the HDD/SSD path, and the fundamental, pivotal factor
in what follows, is that data can only be written to an
empty SSD page. This is not new, nor is it in any way
unknown, but it has the greatest implications for data
security and recovery.

While SSDs can read and write to individual pages, they
cannot overwrite pages, as the voltages required to revert
a zero to a one would damage adjacent cells. All writes
and rewrites need an empty page. Unlike HDDs, where a
compete cluster is written to the disk whatever was there
previously, the act of writing an SSD page allocates an
empty page with its default of all ones, and an electrical
charge is applied to the cells that require changing to
zeroes. This is as true for multi-level cells as it is for
SLCs, as the no-charge all-ones pattern is either replaced
with a charge representing another pattern, or is left
alone. This is a once-only process.

When a write request is issued an empty page is allocated,
usually within the same block, and the data written. The
LBA/PBA map in the FTL is updated to allocate the new page
to the relevant LBA. The LBA will always remain the same
to the host: no matter which page is allocated the host
will never know. This is the same process if the user data
is being rewritten or if it is a new file allocation: the
only difference is that the rewrite will have slightly
more work to do. The old page will be flagged as invalid
and will be inacessible to the host, but will still take
up space within its block as it cannot be reused.

Whilst it's easy to grasp writing to SLC pages,
multi-level cell pages are more difficult to visualise.
The controller accumulates new writes in the SSD cache
until enough logical pages to fill a physical page are
gathered, and then writes the physical page. This entails
the fewest writes to the page. If a logical page in a
multi-level page is amended it would require a new page to
be allocated and all logical pages rewritten, as the
individual values in the physical page can't be altered.
If a logical page is deleted then I surmise that the
deleted logical page is flagged as invalid, and when the
block becomes a candidate for garbage collection any valid
logical pages are consolidated before writing. In other
words a multi-level page, or at least the majority of
them, will always contain a full compliment of logical
pages.

It's apparent that if NAND flash handles data writes in
this way - and it does - the SSD will eventually become
full of valid and invalid pages, and performance will
gradually slow to a crawl. Although an individual SSD page
can't be erased a block can, and this method is used to
return blocks to a writable state. To expedite this, and
to ensure that a pool of empty blocks is always available
for writes, the SSD controller uses Garbage Collection.

 

Garbage Collection:

Garbage Collection is enabled on the humblest up to the
highest capacity SSD: without it NAND flash would be
unusable. Garbage Collection is part of the SSD controller
and its work is unknown to the host. In its simplest form
GC takes a block holding valid and invalid pages, copies
the valid pages to a new empty block, updates the LBA
mapping tables, and consigns the old block to the invalid
block pool. There the block and its pages are reset to
empty state, and the block added to the available block
pool. Thus a pool of available blocks should always be
available for write activity. As long as there is power to
the SSD GC will do its work, it cannot be stopped. There
are various sophisticated techniques for GC routines, all
proprietary and mainly known only to the manufacturers.

When an SSD arrives new from the factory writes will
gradually fill the drive in a progressive, linear pattern
until the addressable storage space has been entirely
written. However once garbage collection begins, the
method by which the data is written - sequential vs random
- affects performance. Sequentially written data writes
whole blocks, and when the data is replaced the whole
block is marked as invalid. During garbage collection
nothing needs to be moved to another block. This is the
fastest possible garbage collection - i.e. no garbage to
collect. When data is written randomly invalid pages are
scattered throughout the SSD. When garbage collection acts
on a block containing randomly written data, more data
must be moved to a new block before the block can be
erased.

 

The Garbage Collection Conundrum:

Garbage Collection can either take place in the
background, when the host is idle, or the foreground, as
and when it is needed for a write. Whilst background GC
may seem to be preferrable, it has drawbacks. If the host
uses a power-saving mode when idle, GC will either wait
for the device to restart with a consequent user delay for
GC to complete, or wake the device up and reduce battery
life whilst the host is 'idle'. Furthermore GC has no
knowledge of the data it is collecting. Inevitably some
data will be subject to GC and then be deleted shortly
afterwards, incurring another bout of GC and consequent
additional and unnecessary writes (write amplification,
the ratio of actual writes to data writes). Foreground GC,
seemingly the antithesis of performance, avoids the
power-saving problems, only incurs writes when they are
actually required, and with fast cache and highly
developed GC algorithms presents no noticeable performance
penalty to the user. The trend in modern GC appears to be
foreground collection, or a combination of foreground and
background collection.

Based on foreground garbage collection, and that most user
activity is random, then the inevitable conclusion is that
the SSD will spend most of its life at full capacity, if
by that we mean available blocks, even though the
allocated space appears to the host to be low.

However there is another potential problem with SSDs, and
that is to do with a historical event: the way that file
systems were designed.

 

File Systems - What you see isn't what you get:

Host file systems were designed in the days when HDDs
reigned supreme, simply because SSDs had yet to arrive in
an available and affordable form. The file system does not
take into account the needs of NAND flash. Files are
constantly being updated: they get allocated, moved and
deleted, and grow and shrink in size. The way the file
system handles this is incompatible with the workings of
NAND flash.

It's worth emphasising that storage devices are abstracted
from the host operating system. Whilst an array of folders
and files are displayed by Explorer in a form wholly
comprehensible to a human, it's all an illusion. What
Explorer is showing is a logical construct created
entirely from metadata held within the file system's
tables. The storage device controller knows nothing about
files or folders, or tables or operating systems: all an
HDD or SDD sees are commands to read or write specific
sectors, which it does faithfully. An SSD has one
advantage over an HDD however, it knows that some pages
hold data, and are mapped to an LBA, and some pages are
empty, hold no valid data, and are not mapped to an LBA.
Conversely an HDD does not need to know this, to an HDD
all sectors are the same.

 

File Deletion:

In NTFS, when a file is deleted the entry in the Master
File Table is flagged as such, and the cluster bitmap is
amended to flag the file's clusters as available for
reuse. The delete process takes place entirely within the
MFT and the cluster bitmap. This is perfectly adequate for
an HDD, as NTFS can simply reuse the MFT entry and the
clusters whenever it wishes. On an SSD the process from
NTFS's point is exactly the same, as NTFS has no other way
of deleting files. However all the SSD sees is exactly
what an HDD would see, updates to a few pages. Neither an
HDD nor an SSD knows that it's the MFT and cluster bit map
being updated, as they have no knowledge of such things.
As there is no activity on the deleted file's clusters,
the SSD's pages holding the clusters remain mapped to
their LBAs in the FTL. The SSD's FTL has no way of knowing
that these pages are no longer allocated by NTFS: to the
SSD the pages are still valid and will not be cleaned up
by garbage collection.

As these 'dead' pages are allocated to an LBA they could
be released when files are allocated or extended and the
host uses that LBA. In this case the page will be flagged
as invalid and a new page used. However it is inevitable
that eventually a significant amount of unused and
unwanted baggage which is not flagged for garbage
collection will be pointlessly maintained by the SSD
controller and be unavailable for reuse. To overcome this,
and to correlate the hosts view of allocated and
unallocated pages with the SSD's, NTFS from Windows 7
onwards acquired the TRIM command.

 

SSD Detection:

Although the storage device is abstracted from the File
System, to enable some of the file system's SSD tweaks it
needs to know whether the device is an HDD or SSD. There
are various ways to do this, including querying the
rotational speed of the device, which on an SSD should be
zero (or perhaps one). This seems the most widely used and
most proficient method.

 

TRIM:

TRIM (it isn't an acronym) is a SATA command sent by the
file system to the SSD controller to indicate that
particular pages no longer contain live data, and are
therfore candidates for garbage collection. TRIM is only
supported in Windows on NTFS volumes. It is invoked on
file deletion, partition deletion, and disk formatting.
TRIM has to be supported by the SSD and enabled in NTFS to
take effect. The command 'fsutil behavior query
disabledeletenotify' returns 0 if TRIM is enabled in the
operating system. It does not mean that the SSD supports
it (or even if an SSD is actually installed) but all
modern SSDs support a version of it.

There are three different types of TRIM defined in the
SATA protocol and implemented in SSD drives.
Non-deterministic TRIM: where each read command after a
TRIM may return different data; Deterministic TRIM (DRAT):
where all read commands after a TRIM return the same data
(i.e. become determinate) and do not change until new data
is written; and Deterministic Read Zero after TRIM (DZAT):
where all read commands after a TRIM return zeroes until
the page is written with new data. By the way whilst DRAT
returns data on a read it is not the userdata that was
ptrviously there bafore the TRIM: it is random.

Fortunately Non-Deterministic TRIM is rarely used, and
Windows does not support DRAT, so a read of a trimmed page
- which is easily done with a hex aditor - invokes DZAT
and returns zeroes immediately after the TRIM command is
issued. The physical pages may not have been cleaned
immediately following the TRIM command, but the SSD
controller knows that there is no valid data held at the
trimmed page address.

TRIM tells the FTL that the pages allocated to specific
LBAs are to be classed as invalid. When a block no longer
has any free pages, or a specific threshold is reached,
the block is a candidate for garbage collection. Live data
is copied to a new empty block, and the original block is
erased and made available for reuse.

TRIM is an asynchronous command that is queued for
low-priority operation. It does not need or send a
response. The size of the TRIM queue is limited and in
times of high activity some TRIM commands may be dropped.
There is no indication that this takes place, so some
unwanted pages may escape garbage collection.

 

RETRIM:

Windows Defragger - now called Storage Optimiser - has an
option to Optimise SSDs. This does not defrag the SSD but
sends a series of TRIM commands to all unallocated pages
identified in NTFS's cluster bitmap. This global TRIM (or
RETRIM) command is run at a granularity that the TRIM
queue will never exceed its permitted size and no RETRIM
commands will be dropped. A RETRIM is run automatically
once a month by the storage optimiser.

 

Over-provisioning:

All NAND flash devices use over-provisioning, additional
capacity for extra write operations, controller firmware,
failed block replacements, and other features utilised by
the SSD controller. This capacity is not physically
separate from the user capacity but is simply an amount of
space in excess of that which can be allocated by the
host. The specific pages within this excess space will
vary dynamically as the SSD is used. According to Seagate,
the minimum reserve is the difference between binary and
decimal naming conventions. An SSD is marketed as a
storage device and its capacity is measured in gigabytes
(1,000,000,000 Bytes). NAND flash however is memory and is
measured in gibibytes (1,073,741,824 bytes), making the
minimum overprovisioning percentage just over 7.37%. Even
if an SSD appears to the host to be full, it will still
have 7.37% of available space with which to keep
functioning and performing writes (although write
performance will be diabolical). Manufacturers may further
reduce the amount of capacity available to the user and
set it aside as additional over-provisioning, in addition
to the built-in 7.37%. Additional over-provisioning can
also be created by the host by allocating a partition that
does not use the drive's full capacity. The unallocated
space will automatically be used by the controller as
dynamic over-provisioning.

My humble WD SSD has four 32 gb chips but a specified
capacity of 120 gb, meaning that it has 8 gb set aside as
additional over-provisioning. Add this to the 7.37%
minimum (9.4 gb) and the 17.4 gb equates to almost 15%
over-provisioning space.

 

Wear Levelling:

Some files are written once and remain untouched for the
rest of their life. Others have few updates, some very
many. As a consequence some blocks will hardly ever see
the invalid block pool and have a very low erase/write
count, and some will be in the pool every few minutes and
have a very heavy count. To spread the wear so that all
blocks are subject to erase/writes equally, and the
performance of the SSD is maintained over its life, wear
levelling is used. Wear levelling uses algorithms to
indentify blocks with the lowest erase count and move the
contents to high erase count blocks; and to select low
erase count blocks for new allocations. As with garbage
collection, wear levelling is far more complex than I
could possibly deduce, let alone explain.

 

Read Disturbance:

SSD reads are not quite free, there is a price to pay. As
described above, a read of one page generates a
pass-through voltage on all other cells in the block. This
voltage is likely to be below the highest threshold value
that could be held by the cell, but it still generates a
weak programming effect on the cells, which can
unintentionally shift their threshold voltages. The
pass-through voltage induces electric tunnelling that can
shift the voltages of the unread cells to a higher value,
disturbing the cell contents. As the size of flash cells
is reduced the transistor oxide becomes thinner and in
turn increases this tunnelling effect, with fewer read
operations required to neighbouring pages for the unread
flash cells to become disturbed, and move into a different
logical state. Cells holding lower threshold values are
more susceptible to read disturbance.

Thus each read can cause the threshold voltages of other
unread cells in the same block to shift to a higher value.
After a significant amount of reads this can cause read
errors for those cells. A read count is kept for each
block and if it is exceeded the block is rewritten. The
count is high for SLC cells, around 1m, lower for 25 nm
MLC at around 40,000, and much lower for 15 nm TLC cells.

 

File Recovery:

And now we come to deleted file recovery. NTFS goes
through exactly the same process to delete a file on an
SSD as it does on an HDD, with the exception of the
additional TRIM command. And the TRIM command (assuming
it's executed) and a few SSD quirks destroys any
practicable chance of deleted file recovery.

TRIM commands, as described above, have a complimentary
setting within the SSD controller in the form of DRAT and
DZAT. (I don't believe that non-deterministic TRIM is used
in any reputable SSD, and I don't think that Windows
supports DRAT, but I have no proof.) The implementation of
DZAT means that immediately on successful execution of the
TRIM command (which will in most cases be immediately on
file deletion) any attempt to read the TRIMed page will
return zeroes. The data on the page will still exist until
the block is processed by the garbage collector, but that
data is not accessible from the host by any practicable
means, or any general software.

Garbage collection is independent of the host device and
will be invoked at the will of the SSD's controller. Once
the process is started it cannot be stopped, apart from
powering off the SSD. Once powered up again the garbage
collector will resume its duties to completion.

Deleted file recovery on a modern SSD is next to
impossible for the end user, and under Windows as close to
impossible as you can get. A theoretical examination of
the chips would most likely show compressed and encrypted
data, striped over multiple blocks, and no possibility of
relating one page of data to another across the multiple
millions of pages. There is a very small possibility of
recovering recently deleted files by powering off the SSD
immediately and sending it to a professional data recovery
company. They may recover some data, given enough time and
money.

After a session of file deletion, such as running
Piriform's CCleaner, run Recuva on the SSD. The headers of
the deleted files found (and presumably the rest of the
file) will all be zeroes. This is TRIM and DZAT doing
their work in a few seconds, killing any chance of deleted
file recovery. Of course TRIM can be disabled, at the cost
of performance, but it's probably better to be a little
less cavalier when deleting files that might be wanted
later.

 

Deletd File Security:

The notion of secure file deletion - overwriting a file's
data before deletion - is irrelevant, and if any other
pattern except zeroes is chosen is just additional and
pointless wear on the SSD. Even overwriting with zeroes
will cause transaction log and other files to be written,
so secure file deletion on an SSD should never be used.
Wiping Free Space is far worse for pointless writes, and
is even more futile than secure file deletion. The deleted
files just aren't there any more.

 

The OCZ Myth:

Some years ago (as a little light relief to all these
acres of text) the OCZ forums were buzzing with the latest
method of regaining performance on their SSDs: run
Piriform's CCleaner Wipe Free Space, with one overwrite
pass of zeroes. Although performance may have been
regained, logic, and common sense, went out of the window.
The theory was that overwriting the pages with zeroes was
equivalent to erasing blocks (this was before the days of
TRIM). This was nonsense, and should have been apparent
from the start. The default state of an empty page is all
ones, not zeroes, and how could a piece of software
possibly erase NAND flash?. The real reason was that as
CCleaner was filling the pages with zeroes the SSD
controller simply unmapped the pages and showed default
pages of zeroes to the host. The invalid pages were then
candidates for garbage collection, which gave a much
greater pool of blocks to call upon on writes, and hence a
better performance. A sort of RETRIM before that was
invented.

 

SSD Defragmentation:

One of the SSD mantras is that an SSD should never be
defragged. Whilst there is little (there is a little) to
be gained from rearranging clusters into adjacent pages -
an SSD has no significant overhead in random reads - an
SSD defrag is not entirely verboten. In fact from Windows
8 onwards the Storage Optimiser will defrag an SSD if
certain conditions are met. If System Restore is enabled,
the fragmentation level is above 10%, and at least one
month has passed since the last defrag, Windows Storage
Optimiser Scheduled Maintenance will defrag the SSD. This
is what Microsoft calls a Traditional Defrag, it is not an
Optimise (RETRIM). The defrag is required to reduce the
extents on the volume snapshot files when system restore
is enabled.

There is nothing to be afraid of in a monthly defrag. Most
users won't hit the 10% fragmented criteria so a simple
RETRIM will be run, and Windows 10 users won't get
defragged anyway (System Restore is disabled in Widows 10
by default). The reduction in life of an SSD will not be
noticed. Furthermore, although SSDs are not fazed by
random reads, files do get fragmented and that means a
significant increase in I/Os. An occasional clearup is a
boon.

 

SSD Lifetime: There are many users worried about the life
expectancy of their SSDs. Yes, continuous write/erase
cycles, and the added and unseen write amplification, do
take a toll on the life of NAND flash. Using an SSD does
wear it out. My WD Green 120 gb SSD, a TLC SSD from a
reputable manufacturer but at the very lowest cost, has an
estimated life of 1 million+ hours and a write limit if 40
terabytes. One million hours is 114 years, so we can
forget that. As for writes, at 1 gb a day - far more than
my current rate of data use - it would take the same 114
years to reach 40 tb. Even with massive write overhead
this SSD is not going to wear out in the forseeable
future. If all 128 gib of available flash is used equally,
the 40 tb equates to 312 writes per cell, a very
conservative number.

 

The End:

The only thing to add is that NAND flash, SSDs, and
especially SSD controllers, are far more sophisticated,
complex and incomprehensible than what has been written
here, what I know, what I could possibly comprehend, and
what I could possibly explain. I should also add secret,
as their software is proprietary. Whilst an HDD is a
marvel of complex electro-mechanical engineering at a
ridiculously low cost, the SSD is an equally marvellous
and complex piece of electronics and software at a
minimally higher cost. We should be thankful for both.

 

 

You can return to my home page here

If you have any questions, comments or criticisms at all
then I'd be pleased to hear them: please email me at kes
at kcall dot co dot uk.

            (c) Webmaster. All rights reserved.