samsung magician makes wonders

It has increased from 80 GB to 146 GB? I think that's nothing to do with over provisioning (OP)...66+ of 256 GiB would be far too much.

Reasons:

Magican uses zero extra OP with default settings. You should have been aware when setting it manually....
Generally when you set extra OP it either decreases directly the total capacity, or you take some away as unassigned space. (Visible at partition scheme).

AFAIK unassigned space cannot be TRIM'ed, though. (TRIM works within a file system only)
The advice therefore has to be to assign all the available user space, but to leave back some rest capacity. (No full disk usage). It's like OP but within a FS.


Most SSDs come with own factory OP.
That means the total user capacity of physical SSD memory has been decreased already for OP.

OP is defined by:

(physical capacity - user capacity) / user capacity.

OP is an certain amount specified by the manufacturer.

Some OP is reasoned by the (faulty) conversion of IEC-prefix (binary) to SI-prefix (decimal).

For instance:
1 GiB NAND consists of 2^30 physical bytes (1,073,741,824 Byte).

The manufacturer specifies the size as 1 GB 10^9 (1,000,000,000 Byte), though
This means there is OP of 7.37% reasoned by (actually faulty GiB=GB) conversion alone.

(2^30-10^9)/10^9*100%

That means from GiB to GB you always have an OP of 7.37%. Most articles are talking about those 7 percent OP.
And people complain about that 'decrease' but do not consider their use for OP.

Another common relation which is frequently found at specifications of 256 G(i)B SSDs:

They either come with 250 GB (9.95% OP, yours for instance) or with 240 GB (14.53% OP).

That's the reason why common OP values are 7.37%, 9.95% or 14.53%.

To TRIM space it has to be assigned to a partition with a usable file system. OP space cannot be addressed by TRIM, but also contains no active user data.

TRIM is a command sent to the controller by the OS whereas all the cells (OP plus usable) are managed by the controller firmware itself. (wear leveling, garbage control, bad block management)..
The OS communicates to the controller by TRIM command which pages are ready to become erased. Without TRIM the controller does not know about and it would waste a lot of time erasing pages as blocks directly on re-write-demand....

For a common client use you do not need additional OP.
Factory OP cells are used for garbage control, wear leveling and bad block management....

Increase of factory OP makes sense there where garbage control, wear leveling and bad block management take a noticeable time. Those processes (TRIM also) take more time because the erase process of NAND happens in erasable blocks and is significantly slower than the r/w operations which are done in pages.

For instance everywhere where one rewrites / alters a lot of data all the time (e.g. server use).....

But finally..OP is a sort of psychological value only.

When you relate the amount of total TB written to a lower usable capacity then those cells seemingly have a better wear. But that's actually an illusion.

The wear related to total amount of cells is constant and depends on their quality alone.
The job of a controller is to make use of each block (cell) equally so that they all last a similar time.

 

When I bought my new EVO 860 1TB I also wanted to use Magican to clone two data partitions. For some reasons it only let me choose the system partition to clone.

I decided to copy and paste all the files by explorer. That can be done because it's data only. By doing that I copied file by file and no raw data or sectors. Each of those files is copied and pasted so I know that all them are still intact.

I wonder how Magican handles dynamic system files such as pagefile.sys and hiberfil.sys. To clone those would be actually useless....
I myself make a clean installation when I change the system drive. I usually tie this event with an OS upgrade.

BTW: The factory reserved cells (OP) are reserved by the controller firmware and do not appear anywhere as unallocated space.

In fact those blocks (cells) are reallocated on demand by the controller. It's a dynamic process. Means the identity of the OP cells is changing during operation. Their quantity is constant and 'unusable', though.
To get them TRIM'ed by the OS they have to be a part of a file system which they should become, sooner or later.

 

I am strictly against using defrag for SSD.

- M$ defrag reorganizes occupied space different to the controller's proprietary algo!
- defrag creates useless wear
- the controller continues doing its work either way and the work of defrag gets obsolete. By that there is even more wear created.

The pro is the SSDs firmware/controller not M$'s generic defrag tool.

What I notice after I have made a clean installation is that the SSD is slower first.....
After a few reboots and idle time frames the controller did its job and the boot time decreases.

After cloning a system just give it some time....

 

It does not hurt at first sight, but it's contra-productive since the measure like wear leveling and garbage collect are opposed to defrag.

- To compensate wear and to fragment data is actually the same. To de-fragment is opposed to proper wear leveling. To make the same use of each cell you have to take care that data will be fragmented on those cells which have least of all wear yet. They are never in a row...organizing clusters in a row makes absolutely no sense on SSDs = non (moving) physical disks.

- Defrag cannot determine which are the erasable blocks of the particular SSD. Garbage collect tries to sum up many blocks which are partly occupied to fewer of fully occupied blocks.
Only full blocks can be erased (at once)...

TRIM reports ready to be erased, but garbage collect then has to reorganize cells to fully erasable blocks...congruent to the EBS grid.
If defrag has put them in a row first and there comes the request to become deleted, garbage control has to reorganize them to erasable blocks.
That's useless extra work...

Well, SSD manufacturers do not talk about their own algos for wear leveling and garbage control.
Therefore the probability that a generic tool such as M$ defrag should be supportive to any SSD is near zero...

People should know that a SSD has an own firmware that is best for own maintenance.
HDDs don't have that....and there are real physical distances for the r/w heads which are optimized when one puts clusters in a row when using defrag...