2 Mikl777 (Компьютеры)

написал Д_К @, 2024-02-02, 21:31 (232 дней назад)

Напомни, пожалуйста, сколько места (в процентах) нужно оставлять неразмеченного на SSD для увеличения его срока жизни. Взял SSD на 256 под систему и программы, его весть использовать, или какой то процент "про запас" оставить? Спасибо

Re: 2 Mikl777

написал VadimmF @, Королёв, 2024-02-02, 22:47 (232 дней назад) @ Д_К

Несколько процентов, а чего такой маленький взял?

Под систему и 5 нужных программ хватит

написал Д_К @, 2024-02-04, 17:01 (230 дней назад) @ VadimmF

Это чисто на управлялку безшумную

240 тебе, остальное OP

написал Mikl777 @, 2024-02-03, 01:44 (231 дней назад) @ Д_К

это минимум )

220 себе взял. Остальное оставил неразмеченным. Спасибо!

написал Д_К @, 2024-02-04, 17:02 (230 дней назад) @ Mikl777

не обязательно оставлять неразмеченное, если контролируешь использование

написал F1, 2024-02-03, 01:46 (231 дней назад) @ Д_К

объема. Если взять за правило не забивать диск более, чем на 70%, то можно и вообще не оставлять. 50% - вообще отлично. Для хранения данных всё равно используется вся ёмкость накопителя, просто используется она, очень грубо говоря, "по кругу". Соответственно, чем меньше одномоментно используемый объем накопителя, тем меньше его износ (меньше записей на единицу полного объема).

ваще никак не связано

написал Mikl777 @, 2024-02-03, 02:19 (231 дней назад) @ F1

если это пользовательские данные, даже если они пустые - они не могут использоваться для выравнивания износа ячеек.
и поэтому размер окна для выравнивания становится очень мелким, и выравнивание происходит сильно фрагментированно, что приводит к усилению записи до 15 к 1

какие "пользовательские данные" во free space?

написал F1, 2024-02-03, 02:22 (231 дней назад) @ Mikl777

вот ТАКИЕ, они нули но ТВОИ

написал Mikl777 @, 2024-02-03, 02:24 (231 дней назад) @ F1

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

каким образом контроллер внутри ссд знает, что там за данные

написал Зелимхан Ахматович, Ачхой-Мартан, 2024-02-03, 05:34 (231 дней назад) @ Mikl777

в ячейках, GPT/mbr и все остальное, единственно что умеет контроллер, это хранить таблицу top writer pages, и соответственно брать любой малоиспользованный блок и обменивать данные между ним и часто используемым, сохраняя его логический номер "сектора", чтобы файловая система не заметила подмену. и так постоянно идет обмен, т.к. в топ попадают все новые блоки.

правильно ли я понял, выходит, что если ссд под хранилище используется

написал Выпить @, 2024-02-03, 09:43 (231 дней назад) @ Зелимхан Ахматович

где пользователь данные почти не обновляет, то и держать почти полным можно ?

если под хранение - то OP вообще не нужна

написал Mikl777 @, 2024-02-03, 12:49 (231 дней назад) @ Выпить

OP нужна если на ссд часть данных динамически меняется, чтобы выравнивать износ крупноблочно, и благодаря этому минимально усиление записи создавать , от 1.1 до 2.0

вот знает , гад

написал Mikl777 @, 2024-02-03, 12:48 (231 дней назад) @ Зелимхан Ахматович

не просто так создаются области OP за зоной пользовательских данных исключительно, а не внутри.

и даже если внутри всё нулями занято, это пользовательские нули, и эти зоны для подмены ячеек крупноблочно использовать контроллеру НЕЛЬЗЯ.
как SOURCE

Это весьма условное разбиение, для удобства представления юзером. В реальности

написал F1, 2024-02-03, 17:17 (231 дней назад) @ Mikl777

в OP действительно важна именно крупноблочность. Но речь-то о другом. Если объем свободного места на "размеченной" части диска всегда достаточен, контроллер точно так же может использовать это место под GC и WL. И менять эти зоны с OP для обеспечения равномерности WL.

никакой разницы в разметке нет

написал Зелимхан Ахматович, Ачхой-Мартан, 2024-02-03, 19:39 (231 дней назад) @ Mikl777

это все форумная магия. есть два алогоритма, и все их реализуют в FTL, в основном сейчас dynamic, static используют в пром ссд для станков или специальных регистраторов, на некоторых ссд хитачи можно переключать алгоритм специальным софтом

TN-29-61 Wear Leveling in NAND Flash Memory Wear Leveling Algorithms
Wear leveling is associated with a block aging table (BAT) to store information about which blocks have been erased in a selected period of time.
There are two kinds of wear leveling that can be implemented in the FTL:
• Dynamic wear leveling
• Static wear leveling
Dynamic Wear Leveling
When applying the dynamic wear leveling, new data is programmed to the free blocks (among blocks used to store user data) that have had the fewest WRITE/ERASE cycles.
Static Wear Leveling
With static wear leveling, the content of blocks storing static data (such as code) is copied to another block so that the original block can be used for data that is changed more frequently.
Static wear leveling is triggered when the difference between the maximum and the minimum number of WRITE/ERASE cycles per block reaches a specific threshold. With this particular technique, the mean age of physical NAND blocks is maintained constant.

только вот усиление записи разное

написал Mikl777 @, 2024-02-04, 13:54 (230 дней назад) @ Зелимхан Ахматович

если у самсунга не выделить область OP через магициан, то усиление записи около 10
т.е. в нанд пишется х10 больше, чем в хост

а если у самунга выделить область ОР через магициан, то усиление записи около 2
т.е. в нанд пишется х2 раза больше, чем в хост

Читал старые статьи, очень любопытно было

написал dennis, 2024-02-04, 14:58 (230 дней назад) @ Mikl777

Когда Sandforce хвалился своим контроллером со сжатием, что благодаря ему усиление не более 1-1.5
Не взлетело что ли?

никому не нужно стало

написал Mikl777 @, 2024-02-04, 15:44 (230 дней назад) @ dennis

т.к. это сжатие было выгодным когда нанд был очень дорогим и его было мало
когда диск на 128 ГБ стоил как ща стоит на 4 ТБ

простой вопрос: расположение области OP после начальной "разметки" всегда одно

написал F1, 2024-02-04, 15:58 (230 дней назад) @ Mikl777

и тоже (физически, в адресном пр-ве NAND), или меняется?

просто пустая область без файловой системы в конце диска

написал Mikl777 @, 2024-02-04, 16:05 (230 дней назад) @ F1

которую контроллер диска может использовать для крупноблочной игры в пятнашки - выравнивания крупными блоками.

суть в том что у бытовых дисков эта область очень маленькая, и поэтому выравнивание делается очень неэффективно

Я ведь другой вопрос задал)) Я знаю, что такое OP и как работают механизмы

написал F1, 2024-02-04, 17:34 (230 дней назад) @ Mikl777

поддержания диска в оптимальном состоянии.

нули не нули , удаление условного файла не означает удаление данных

написал Выпить @, 2024-02-04, 16:05 (230 дней назад) @ Mikl777

те по факту на диске всегда что-то записано

после команды TRIM ссд шьёт именно НУЛИ

написал Mikl777 @, 2024-02-04, 16:10 (230 дней назад) @ Выпить

в отличие от HDD, т.е. у SSD ничего не записано

говорят наоборот шьёт единицы (снимает заряд)

написал telson, 2024-02-04, 16:21 (230 дней назад) @ Mikl777

Это миф, аналогичный тому, что от складкого жопа слипнеца !

написал Ю & Ю @, Москва, 2024-02-03, 22:42 (231 дней назад) @ Д_К

У меня все SSD работают уже несколько лет, без всяких там заморочек...
А если и сломаются я просто тупо новый куплю. Хотя таких случаев не было ни разу более 5 лет.
А ценные данные в любом случае, как и яйца не хранятся в одной корзине :-)

А производители дурачьё да? кто создаёт аппаратный OP ??

написал Mikl777 @, 2024-02-04, 13:50 (230 дней назад) @ Ю & Ю

где 3200 ГБ диск вместо 4000, и 800ГБ выделено под OP область

гммм.. это где-то в спецификациях производителя надо смотреть?

написал VL, 2024-02-04, 14:47 (230 дней назад) @ Mikl777

ну все серверные ссд, 800 гб, 1600 гб, 3200 гб

написал Mikl777 @, 2024-02-04, 15:47 (230 дней назад) @ VL

у 800 гб диска - реальный обьём 1024

у 960 гб реальный обьём те жже 1024

но у первого 224 гб OP
у второго 64гб ОР

так и у несерверных бывают странные объемы

написал dennis, 2024-02-04, 17:14 (230 дней назад) @ Mikl777

НЕ 512 Гб, а 500 Гб, 480 Гб
То есть кусок-то прячут под своим OP?

в условно дорогих - да, выделяется ощутимо места. Под OP и резерв

написал F1, 2024-02-04, 17:35 (230 дней назад) @ dennis