>> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой
>> CoW ФС.
> Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь
> там контроллера. Но проблема не в том. Проблема в том что
> контроллер - есть. И он не знает какие блоки используются. Поэтому
> вынужден очищать блоки только когда туда пытаются писать по факту. А
> не заранее. И вот это является очень неоптимальным режимом работы.Откуда ты знаешь? Без TRIM контроллер не запускает механизм очистки, а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди обнуления/записи контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру блока SSD).
> И
> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать
> операции записи, и запись медленнее происходит.
Вывод из посылки, которая не верна.
>> Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков
>> совпадают) страниц блока SSD,
> И вот это - плохо. Потому что операция стирания - медленная и
> деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и
> деструктивнее чем конкуренты из-за неподдержки TRIM.
Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, но из-за малого размера блока ФС, содержимое блока SSD каждый раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, но так же И делается "усиление записи" для всех остальных страниц блока SSD, не участвующие в хранении данных записываемого блока ФС.
Контроллер SSD записывает данные на флэш только поблочно, при этом используется оперативный кэш для заполнения вновь затребованных страниц и освежения немодифицируемых страниц. Это способствует большему износу ячеек памяти, чем если бы блок ФС совпадал с размером блока SSD.
Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Ресурс флэш тратиться на освежение, которого можно избежать в принципе — сделать размер блока ФС равным размеру блока SSD.
>> новые данные будут записываться после обнуления предыдущего содержимого.
>> А в традиционных ФС вместо предварительного стирания страниц (они уже
>> ранее обнулены GC после команды TRIM) будет происходить "усиление записи"
> Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с
> поддержкой trim запись будет просто записью страниц без нужды что-то там
> стирать и перетрясать.
Контроллер SSD по команде ФС записывает данные на флэш только поблочно, при этом имеются в виду не блоки ФС (хотя и они тоже в этом процессе участвуют), а более объёмная по отношению к ФС величина — блок SSD, имеющий размер 512 килобайт.
Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть очищенные страницы в блоке, то их не нужно предварительно обнулять (это сделал GC после команды TRIM), скорость записи на них высока. Однако в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает данные на флэш только целым блоком из оперативного кэша. Это называется "усилением записи".
> "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав
> контроллер SSD в наихучший режим работы из всех возможных.
Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как не тайна за семью печатями.
> По поводу
> чего оно будет тормознее работать и сильнее протирать флеш. Erase как
> раз весьма деструктивная операция. А т.к. пространства для маневра у GC
> контроллера будет минимум, erase будет делаться постоянно, по поводу и без.
GC работает с отдельными страницами. И тут никак не влияет на скорость поблочной (пере)записи данных, так как за один раз стирается и модифицируется весь блок SSD — мы говорим для условия, когда размеры блоков ФС и SSD совпадают. Когда же размеры блоков ФС и SSD не совпадают, то тут начинается интересная штука: при интенсивных операциях записи-стирания данных GC может и не успеть обнулить помеченные TRIM страницы, поэтому новая запись в них будет происходить с ПРЕДВАРИТЕЛЬНЫМ обнулением содержимого непосредственно перед модификацией. И мы тут сильно потеряем в скорости записи на мелких блоках ФС, так как будет постоянная перезагрузка оперативного кэша SSD для модификации его блоков. В случае с совпадением размеров блоков операция очистки производится для всего блока SSD сразу, данные записываются большими порциями — нет оверхеда на подчистку отдельных страниц.
>> Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных
>> (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт
>> дополнительной операции по обнулению блока SSD.
> Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки.
> А у btrfs вполне себе реализован trim. Вот в таком виде
> подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера
> SSD не мешает.
Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. ;) Выяснится, что GC может и не успевает за подчистками. Заодно и проверить ресурс флэшатины под обеими ФС. ;)
>> За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц
>> под блок ФС было выполнено на аппаратном уровне после команды TRIM,
> На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы
> блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок.
Ты действительно веришь, что GC после своей работы с блоком разделяет блок на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки SSD и складирует их куда-то? Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)
