См. эффект «усиление записи», связанный с очисткой при TRIM.

никак не могу логически понять каким образом trim увеличивает wa, наоборот trim снижает wa т.к. говорит какие блоки ненужны и ssd не будет пытаться их использовать при сборке мусора

кого ты слушаешь!?
это же представитель «Некрофилы и Ко» - он об ssd только мечтает.
точнее поставить может, но только с целью угробить, т.к. его недоось ни на что кроме роутера не годится

При удалении данных с SSD средствами файловой системы команда TRIM помечает группу блоков SSD (1 блок SSD = 4k), принадлежащих блоку ФС (1 блок ФС = 4...128k = 1...34 блоков SSD) как «готовые к очистке». Сборщик мусора в фоне очищает их, делая возможным дальнейшие операции записи в блоки SSD без предварительной очистки со стороны драйвера ФС. Из-за отсутствия предварительной очистки на этапе записи данных запись на SSD происходит гораздо быстрее, чем если бы TRIM не было.

С другой стороны, операция предварительной очистки - это та же запись информации, когда вместо данных в ячейки записываются нули. Разница лишь в том, какая программа это делает: фирмварь SSD или операционная система через операции с драйвером ФС.

Я чувствую, ты не один SSD уработал. :))

как работает trim понятно, но где рост wa изза неё ?
ведь если trim не выдавать, то очистка нулями всё равно будет, но уже при записи новой порции данных

и какой же дебилобабской логикой ты отсюда вывел, что trim сильнее изнашивает ssd? trim износ выравнивает, что в конечном счёте продлевает срок жизни ssd

т.к. его недоось ни на что кроме роутера не годится

freebsd не умеет в trim, лол? вроде даже ZFS под линуксом умеет

Даже википедия знает больше, чем bsd-клоун

В своих SSD-контроллерах производители используют различные техники для оптимального распределения операций записи по всему флеш-накопителю.[5][11] Это делается не только для того, чтобы оптимизировать скорость путем минимизации усиления записи, но также для увеличения продолжительности жизни флеш-ячеек (выравнивание износа (англ.)), так как обычные MLC-флеш-ячейки выдерживают 3000-5000 циклов записи.[11] Другой подход заключается в том, чтобы использовать лишнюю память, не задекларированную операционной системе, для предоставления чистых страниц для операций записи как можно дольше перед тем, как начать перезаписывать другие страницы.[3]

Эффективность этих методов по большей части зависит от обмена информацией между ОС и контроллером SSD о том, какие страницы могут считаться занятыми, а какие — свободными. Традиционно большинство ОС не информируют накопители об удаленных секторах/страницах, что не позволяет контроллерам SSD оптимально распределять свободное пространство. Команда TRIM была введена чтобы исправить это, очищая неиспользуемые ячейки до того, как в них будет произведена запись, таким образом уменьшая время доступа.[3]

этот бсд-клоун годами копошится в своей бсде и остаётся ламер-ламером, он тут недавно гонял glxgears с включенным vsync и вопил «пачиму у миня всиво 60 фпс??!!!!1111», лол

При использовании TRIM файловая система (классическая, которая создавалась для HDD и, соответственно, которая борется с фрагментацией, оптимизируя запись новых данных) переиспользует очищенные блоки с большей вероятностью, чем без использования TRIM. Новые данные будут записываться вместо ранее удалённых, а не в следующие свободные области диска.

На SSD с TRIM есть большая вероятность того, что классическая файловая система «протрёт дыру» в какой-то области SSD только лишь из-за интенсивной перезаписи одних и тех же блоков, любезно очищенных сборщиком мусора с помощью «подсказки» TRIM.

zfs уже предлагали?

У линуксоидов нет денег на «лишние» 4-8 ГБ ОЗУ для этой ФС.

чувствую, ты ни одни ssd в глаза не видел

хм, не знал что там нужно много ОЗУ. Что-то я провтыкал инфу относительно zfs, пойду маны читать.

зачем тебе ssd со скоростью винта?

Так ли заметно увеличение скорости для большинства ФС с включенной поддержкой TRIM, если операции записи и так происходят асинхронно?

зачем тебе ssd со скоростью винта?

Чтобы узнать время жизни SSD в типичных условиях использования. А ZFS, по крайней мере, не даст использовать битые данные.

типичные это с trim.
а ты же просто убиваешь весь профит носителя.
да, норм фс не протрёт дырку, ибо copy-on-write

да, норм фс не протрёт дырку, ибо copy-on-write

Какая из линуксовых ФС делает с данными copy-on-write?

f2fs

btrfs

закрыта, не звезди. ext4

4.2

сам ты 4.2. Выбрать есть из чего. Рабочие есть. А то, что ТС тупая барышня, не смогшая определиться сам, то ССЗБ. А в макос и виндовс вообще по определению сейчас нельзя ССД использовать.

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

При использовании TRIM файловая система (классическая, которая создавалась для HDD и, соответственно, которая борется с фрагментацией, оптимизируя запись новых данных) переиспользует очищенные блоки с большей вероятностью, чем без использования TRIM. Новые данные будут записываться вместо ранее удалённых, а не в следующие свободные области диска.

Это всё хоть сколько-то справедливо только для HDD. На SSD вопрос куда будут записаны новые данные решает микроконтролёр диска, и при этом он следит, чтобы все ячейки памяти изнашивались примерно одинаково. Поэтому вывод

На SSD с TRIM есть большая вероятность того, что классическая файловая система «протрёт дыру» в какой-то области SSD

это полная чушь.

У меня стоит ext4 с discard. Полёт нормальный.

А в макос и виндовс вообще по определению сейчас нельзя ССД использовать.

ты как был дебилом, так и остался

какая хорошая аргументация для умного человека. Зад жжёт?

с чего ты решил, что кто-то будет приводить аргументы в ответ на твоё бездоказательное кукарекание?

Ты сильно слажал. TRIM нужен для того, чтобы пометить блоки как пригодные к дальнейшему используованию и поместить их в аналог LRU list. Грубо говоря, повторная запись в эти блоки произойдет когда все остальные блоки с меньшим количеством перезаписей будут изношены до примерно того же или худшего состояния.

Без trim после удаления файла SSD будет считать блоки удаленного файла «использованными» и будет с целью «оптимизировать износ» постоянно «тасовать» данные.

То есть ты записал 100500 данных на SSD до состояния «забил до предела» киношками и образами, потом большие файлы удалил, но SSD об этом без trim не узнал. И когда ты записываешь новые данные, SSD, считая что блок занят но давно не использовался, вместо записи туда будет сначала читать данные, потом записывать их в другое место (наиболее изношенный блок), и только потом вписывать реальные данные. То есть без trim скорость записи упадёт в два с лишним раза, чем если бы ты использовал trim, как только суммарный объем записи превысит объем SSD.

/превед_бздунам

Ответ на: комментарий

что-же в итоге ? ext4 подойдет ?

С опциией discard - да, пойдет. Но не под все задачи

То есть без trim скорость записи упадёт

А я что написал? Перечитай ещё раз, если такой невнимательный.

На SSD вопрос куда будут записаны новые данные решает микроконтролёр диска, и при этом он следит, чтобы все ячейки памяти изнашивались примерно одинаково.

Что, есть счётчик числа перезаписей у каждого 4k-блока SSD? (просто для битовой карты памяти состояний страниц потребуется огромный объём дополнительной памяти, отдельно от основного объёма - легче реализовать ECC, чем делать подсчёт числа перезаписи каждого блока). Я думаю, контроллер SSD не столь интеллектуален, чтобы учитывать каждый 4k-блок и вести его индивидуальную статистику использования для равномерного износа. Просто для такого потребуется очень много служебной памяти и вычислительных тактов микроконтроллера.

Так ли заметно увеличение скорости для большинства ФС с включенной поддержкой TRIM, если операции записи и так происходят асинхронно?

трим может чуть замедлить запись если включена, и ОЧЕНЬ сильно затормозить ВСЁ, если её выключить(причём этот эффект происходит не сразу, но ВНЕЗАПНО)

Чтобы узнать время жизни SSD в типичных условиях использования. А ZFS, по крайней мере, не даст использовать битые данные.

контроль данных имеется внутри любого SSD. Также как и восстановление ошибок. Нет смысла наворачивать поверх этого ещё один слой проверок.

Это всё хоть сколько-то справедливо только для HDD. На SSD вопрос куда будут записаны новые данные решает микроконтролёр диска, и при этом он следит, чтобы все ячейки памяти изнашивались примерно одинаково. Поэтому вывод

ни хрена он не следит. Самый обычный безумный рандом. Бессмысленный и беспощадный.

На SSD с TRIM есть большая вероятность того, что классическая файловая система «протрёт дыру» в какой-то области SSD

это полная чушь.

полностью согласен — никаких дыр не получится. Ну точнее — маловероятно. Как монетка, которая выпала 1024 раза подряд орлом.

А в макос и виндовс вообще по определению сейчас нельзя ССД использовать.

ты как был дебилом, так и остался

это ты дебил. А darkenshvein истину глаголит. Хоть и SSD тут не при чём.

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

да хрен там. Нету там никакой поблочной статистики. Тупо пул свободных ячеек, и всё.

И когда ты записываешь новые данные, SSD, считая что блок занят но давно не использовался, вместо записи туда будет сначала читать данные, потом записывать их в другое место (наиболее изношенный блок), и только потом вписывать реальные данные.

да нифига. Просто SSD не умеет стирать страницы, а умеет только острова(в которых много страниц). Потому, если SSD ничего не стирает, то получается так, что на островах есть и нужные и не нужные страницы, потому остров и писать нельзя, и стирать нельзя. Надо нужные страницы сначала эвакуировать, потом стереть, а потом уже и писать. Ну а с TRIM оно это в фоне может сделать, пока ты спишь/дрочишь (:

ZFS может хранить данные в нескольких копиях (можно установить число в соответсвующем свойстве ФС). - этим обеспечивается защита от частичной потери/разрушения данных на одном носителе. В аналогичном случае классические ФС в случае сбоя какого-либо блока SSD обнаружат либо невозможность чтения (с последующими попытками перечитать сбойный кластер-блок ФС), либо при чтении сбойного блока отдадут приложению мусор при несовершенной аппаратной коррекции ошибок (битый файл).

ext4 подойдет ?

УМВР, уже год. Как сказал мегабакс — для SSD лучше подходит f2fs, я согласен, хотя она пока сыровата. Но пойдёт, если ты бекапы делаешь, и у тебя больше 1 компа.

Что, есть счётчик числа перезаписей

нет конечно.

легче реализовать ECC

там круче: коды Рида-Соломона.

не столь интеллектуален, чтобы учитывать каждый 4k-бло

рандом достаточно «интеллектуален» (:

Для рандомной перезаписи нужна карта отображения lba-адресов на свободные/занятые ячейки (4k-блоки) во внутренней адресации. У микроконтроллера SSD есть такая карта? Сомневаюсь. Я думаю, в SSD всё линейно + резервный объём памяти, недоступный для прямой адресации, но необходимый для подмены отживших 4k-блоков SSD.

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

да, я слышал. В прошлом веке так делали.

Сейчас применяются коды Рида-Соломона, которые замешивают скажем 1000 бит в скажем 1500. Что-бы прочитать 1000 бит нужно прочитать 1000 бит. Но _любых_ из 1500. Т.е. 500 бит(из 1500) могут быть уничтожены, и данные всё равно прочитаются. Так делается в любых HDD, в CDROM, во флешках, и конечно в SSD. Надо сказать, что эти коды не только исправляют ошибки, но и проверяют целостность данных. Т.ч. какие-то дополнительные средства не требуются. Единственная причина — защита от подделки(ЭЦП), но это уже другое.

Для рандомной перезаписи нужна карта отображения lba-адресов на свободные/занятые ячейки (4k-блоки) во внутренней адресации. У микроконтроллера SSD есть такая карта?

есть начиная с флешек. Не сомневайся, я это экспериментально доказал. Вангую, что она лежит в разнице между честными и нечестными гигабайтами. Вот к примеру у меня флешка в 7`816`085`504 байт (по данным fdisk), хотя на ценнике обещали 8`589`934`592 байт (8 честных гигабайт). «Лишняя» память видимо используется для карты LBA адресов а также для резерва(даже на полностью забитую флешку можно быстро записать маленький файл. Что доказывает, что грязные блоки флешка немного чистит, когда они выходят из пула).

На флешках оно не подменяет ничего, а просто так и оставляет битые(исправляя RS-кодом). А на SSD — не знаю. Скорее всего там коды длиннее, и резерв больше...

речь emulek

звучит убедительно

нефтему:

1. как на f2fs UUID глянуть? И можно-ли монтировать по нему? А то у мну что-то не получилось(хотя в суперблоке такое поле есть)

2. а что с xattr? Пытался смонтировать с user_xattr, не хочет. Но вроде как поддержка должны быть. Ядро надо патчить?

uuid-ов вроде нет
xattr есть

/dev/sda2 on / type f2fs (rw,relatime,background_gc=on,discard,user_xattr,acl,active_logs=6)