Казалось бы: всё уже придумано и отработано: очистить таблицу от удалённых имён файлов (пока только в NTFS) и затереть свободное место на диске (много разных программ и способов). Но это - палевно: хоть нулями зачищай (слишком алгоритмично), хоть идеальным мусором (слишком хаотично). Само наличие мусора говорит о том, что тут ранее были данные, - но удалённых файлов программы восстановления не находят - вот и палево. Нулями затрёшь - полное палево. Другой постоянной цифрой затрёшь - полное палево.

Во время изучения фрагментации, у SSD было обнаружено название древней технологии равномерного износа ячеек чипов данных: Wear Leveling. Сначала целью было доказательство её работоспособности - как доказательство, что дефрагментаторы врут о реальном расположении данных на носителе. Однако это трансформировалось в алгоритм такого затирания свободного места на SSD, что комар носа не подточит.

Пусть есть раздел NTFS на SSD, WinPE. Целенаправленно затирается с помощью Fast ZeroFilling: заполнение раздела файлами Delete_Me_Tenderly.TMP*, заполненных нулями, - а потом их стирание. Очистка MFT не делается - программы восстановления увидят эти файлы. Далее берётся файл Тест CD (702MB).txt из архива для проверки оптических приводов. В нём записаны единицы через Enter. Делается простой расчёт, сколько раз надо этим файлом перезаписать свободное место, чтобы охватить весь его объём. И тупо копируется в корень необходимое количество раз (система сама при замене затирает файл и пишет его заново). В итоге, свободное место заполняется единственным файлом; и такое можно объяснить самым въедливым проверяльщикам как "баг контроллера".

Далее используется программа восстановления данных и показывает ошибки:

- не всё содержимое файла Delete_Me_Tenderly.TMP0 заменилось с нулей на единицы с Enter. Потому что нужно было скопировать файл 11 раз - скопировал 10;

- посмотрел начало файла с помощью AkelPad, а надо было 702МБ вниз промотать. AkelPad хорошо себя показала при огромных объёмах данных, но при огромном количестве Enter - просто перестала скроллить. Нашёл альтернативу: Lister по F3 в составе Total Commander. И на 50% файла 2ГБ, что превышает объём 702МБ файла, - были сплошные единицы.

Достаточно ли доказательств, что и способ рабочий, и Wear Leveling работает корректно? На скринах же очевидно всё. А вот 8=====>.

Строчечка с нулями в AkelPad - это не просто строчечка, а 33% от размера файла 2ГБ. Небрежно проанализировав, где единицы начинаются и кончаются: получалось, что файл записался не с начала раздела, а после первого гигабайта, - и без конца записывался именно в это место. То есть, в WinPE Windows 11 произошло то же самое, что в стационарной Windows 10 во время экспериментов с фрагментацией: контроллер записывал файл в одно и то же место (или записал его всего 1 раз) - при этом, нихрена не в логичное место.

Ладно, сделаем всё сначала. Создание раздела (чуть меньшего размера), зануление, копирование файла - но не просто копирование, а слежение за красным светодиодом, который моргает раз в секунду при копировании файла (с USB 2.0 HDD копируется на SATA SSD). После неморгания светодиода - ещё и файл удалить вручную перед копированием. Сразу было обращено внимание: после каждого копирования файла - моргание светодиода наступало; то есть, данные на SSD пишутся - ячейки изнашиваются.

Далее заскринил программу восстановления данных, которая показывала дичь: расположение текстового файла - в проценте >50 от начала раздела, все остальные ячейки - показывала как пустые (как будто на них запись никогда не велась).

Опять восстановив Delete_Me_Tenderly.TMP0 - дичь продолжилась: единицы шли с самого начала файла (начала самого первого файла, создававшегося в разделе) - и заканчивались на 34% файла 2ГБ (а если размер текстового файла 735.770.754Б разделить на размер зануляемого файла 2.143.289.344Б - и получается 34.3% - а Lister как раз с 0% и начинает показывать информацию).

Одновременно с этим, отличился Defraggler: он показывал наличие текстового файла в таком же процентном месте раздела и длину, как в R-Studio.

Получается: вероятность, что Wear Leveling у SSD не работает (при этом, в 2 разных ОС уже), - повышается и становится чуть ли не правдой, смотря на нули в восстановленных файлах Delete_Me_Tenderly.TMP*. Лезу в S.M.A.R.T. SSD: параметр 173 "Wear leveling erase count worst" имеет значения 22/176/105 - технология работает. В интернете тоже заявлено: у Patriot аж с двумя алгоритмами она присутствует.

Оказывается, в разном ПО S.M.A.R.T. показывается по-разному. В Victoria это 173 "Wear leveling erase count worst" 22/176/105. В CrystalDiskInfo этот параметр представлен в HEX как AD просто "Erase Count". Вообще, оказалось удобно смотреть RAW-значения параметров: например, ниже видимости скрина указан износ SSD: 7% за почти 4 года - и видно это именно в RAW).

И даже Minimum, Maximum и Average Erase Count не говорят, включена Wear Leveling или нет: значения очень остро зависят от хранимых данных пользователем и количества свободного места.

Значит, что-то отрыл - чрезвычайно странное. И единственное, что приходит на ум:

- виртуальная картина раздела вообще не соответствует реальной информации в ячейках чипов данных SSD (что уже под сомнением);

- запись единиц оборвалась в тестовом разделе и продолжилась в других разделах: на них полно свободного места - и оно могло начать изнашиваться последовательно (старее свободного места нового созданного раздела). Однако интернет пишет, что Wear Leveling применима именно к разделу (и лучше оставлять 10% свободного места для её успешной работы);

- скимпфляция SSD по всему миру: заявляют, что Wear Leveling есть, - а её, по факту, нет.