SSD-диск

[drmz]

Кочевник, так NVME значно прискорить, головне, щоб в оперативку та багатопоточність cpu не уперлось.
Можна ж зекономити на розмірі, якщо системі залишити старий sata, а NMVE буде для робочих файлів.

Post automatically merged: Сьогодні в 10:41

Это п*здец, товарищи! Да ну его на*й хранить на них критичные данные, HDD на несколько порядков надежнее (в 20...100 раз). И поэтому данные операционной системы и программ на диске C который SSD, не стоит смешивать с ценными пользовательскими данными, которые должны лежать на диске D который есть HDD, ну или постоянный бекап в облако/внешний HDD (который перед порчей данных конечно забыл сделать). Что и стоило доказать.

Яшпєйсал раніше, і не з інтернет історій, а з власного досвіду.

 

[drmz]

Тут важный момент, что если ssd все время в работе, то его микропрограмма по идее должна проверять эти данные и исправлять ошибки незаметно для нас. И тогда все на практике годами будет хорошо. Сюрпрайз может быть при попытке вычитать данные с SSD который два-три года полежал где-то без питания.

проверяет в процессе перекладывания с места на место, с ячейки в ячейку, для распределения равномерности износа. Но в отключенном состоянии у нас записей нет, поэтому перекладывать некому и незачем. А утечки в "трехслойных\четырехслойных" ячейках случаются и у нас по перде идет, с большой вероятностью, несколько файлов одновременно. А если еще и MFT затронет - "чпок!" добрый вечер.

 

[Antares]

швидкість вдома і на роботі відрізняється в рази

ще може не в ssd різниця, а в залізі та драйверах. Якщо SSD SATA, то контроллер SATA на "домашніх" материнках може бути не дуже. Щоб перевірити це, треба тест швидкості дискової підсистеми на робті та дома, просто синтетичний тест, но уважно щоб не потерти данні).

Post automatically merged: Сьогодні в 11:40

проверяет в процессе перекладывания с места на место, с ячейки в ячейку, для распределения равномерности износа.

получается если файл статичный, то ничего не перекладывается ? Тогда теоретически, если на диск емкостью в 128гб записать статический файл 120гб, и далее пользоваться оставшимися, грубо говоря 8Гб пустого пространства, то контроллер на SSD даст эти 8Гб "износить", при этом объем 120ГБ занятый статическим файлом будет как новый?

 

[Kritik]

Тогда теоретически, если на диск емкостью в 128гб записать статический файл 120гб, и далее пользоваться оставшимися, грубо говоря 8Гб пустого пространства, то контроллер на SSD даст эти 8Гб "износить", при этом объем 120ГБ занятый статическим файлом будет как новый

Теоретически да.
Но тоже теоретически, есть вероятность, что операционка может по каким-то своим причинам фрагментировать этот файл, и тогда какой-то износ будет.

 

[Antares]

Тогда теоретически, если на диск емкостью в 128гб записать статический файл 120гб, и далее пользоваться оставшимися, грубо говоря 8Гб пустого пространства, то контроллер на SSD даст эти 8Гб "износить", при этом объем 120ГБ занятый статическим файлом будет как новый

Теоретически да.
Но тоже теоретически, есть вероятность, что операционка может по каким-то своим причинам фрагментировать этот файл, и тогда какой-то износ будет.

Если бы SSD работал по такому принципу, тогда он бы не отличался от обычной флеш памяти. Контроллер постоянно перемещает данные по ячейкам, и только он знает где они находятся (адреса в ячейках). Это делается для равномерного износа. Для ОС нет никакого способа видеть как именно распределены данные по физической памяти.

 

[drmz]

Тогда теоретически, если на диск емкостью в 128гб записать статический файл 120гб, и далее пользоваться оставшимися, грубо говоря 8Гб пустого пространства, то контроллер на SSD даст эти 8Гб "износить", при этом объем 120ГБ занятый статическим файлом будет как новый

Теоретически да.
Но тоже теоретически, есть вероятность, что операционка может по каким-то своим причинам фрагментировать этот файл, и тогда какой-то износ будет.

Да фрагментация все время. Если принудительно дефрагментировать и хранить большие файлы, то SSD начинает медленнее работать некоторое время.
Вероятно, в нашем умозрительном примере, одна запись в MFT и в зеркальный MFT провоцирует контроллер к идее "о, давно, я вон в той огромной поляне не гулял" и берет от туда данные из ячеек, переносит в буферную область, делая на поляне "перфорации" и далее продолжает перекладывать(в системе координат ячеек, не в файловой системе).
Но это всё было во времена MLC, а как сейчас cacheless чипы с TLC\QLC памятью работают, страшно представить.

 

[Antares]

одна запись в MFT

на уровне контроллера нет MFT, есть только адреса ячеек, счетчики таймеры и тд. Тем более контроллер пишет сразу в несколько микросхем физической памяти в несколько потоков для увеличения скорости.

 

[drmz]

Antares, я про ячейки, в которых MFT была прописана. Например в ячейке прописано три байта и она "потекла" , остался один байт живой, но не тот, что относился к MFT. И уже потенциально имеем проблему.
А учитывая, что безкешевые контроллеры как кеш используют часть поляны самого SSD, то скорее всего и реестр по износу ячеек где-то там же и прописывают(на поляне). Т.е. информация по изношенности ячеек тоже может "потечь" в какой-то момент.

 

[Antares]

я про ячейки, в которых MFT была прописана. Например в ячейке прописано три байта и она "потекла" , остался один байт живой, но не тот, что относился к MFT. И уже потенциально имеем проблему.

Так оно и есть. Он вместе с постоянными перезаписями еще контроль четности + отказоустойчивое кодирование. Вообще интересна бы статистика отказов SSD, что чаще, отказы контроллера (схемы питания, ошибки в прошивке) или именно износ ячеек. Мне износ ячеек не попадался, чтоб SSD "устал" именно так как в HDD, переназначенные сектора, сбои чтения, "медленные" сектора. А вот тупо отказ контроллера, что SDD переставал либо нормально работать либо не виделся в системе вообще, пару раз было.