Я думал о способах ускорения дискового ввода-вывода, и одним из узких мест, к которому я постоянно возвращаюсь, является журнал. Есть очевидное преимущество использования SSD для журнала - сверх того просто напишите кеширование если, конечно, я просто не отключу журнал с кешем записи (в конце концов, devicemapper, похоже, не поддерживает барьеры). Чтобы получить преимущества от использования кеша записи BB на контроллере, мне нужно отключить ведение журнала, но тогда ОС должна попытаться выполнить проверку системы после сбоя. Конечно, если ОС знает, что находится в памяти с резервным питанием, она может это использовать. так как журнал, но это означает, что он должен быть представлен как блочное устройство и находиться под контролем только операционной системы.
Однако мне не удалось найти подходящего недорогого устройства (нет, выравнивание записи для Flash не подходит для журнала, по крайней мере, того, который использует Smartmedia).
Хотя нет конца флеш-устройствам, контроллерам дисков / массивов с кешами записи BB, до сих пор я не нашел ничего, что просто дает мне энергонезависимую память, адресуемую как блочное устройство хранения.
Не могли бы вы объяснить, почему использование SSD для журналов является очевидным преимуществом? Все FS реализуют журналы как своего рода кольцевой буфер, к которому в любом случае доступ является последовательным. Просто отключите барьеры на BBWC, и это будет хорошо.
Файловые системы EXT3 и EXT4, используемые для монтирования журнала в «упорядоченном» режиме. В более новых ядрах по умолчанию используется режим обратной записи. В «упорядоченном» режиме обновления журнала фиксировались на диск до записи каких-либо данных. В режиме «обратной записи» обновления журнала записываются на диск в соответствии с обычными политиками планировщика ввода-вывода, а запись данных на диск осуществляется. не заблокирован при обновлении журнала. Вы в основном не видите, что там вообще есть дневник из POV выступления.
Вы хотите отключить барьеры (и, вероятно, замаскировать FUA и SCSI_CACHE_SYNCHRONIZE SCSI CDB) на всем, что может защитить ваши записи от батареи, в противном случае ваша производительность пострадает. Вы получаете семантику барьеров (или всего, что записывается на диски и ожидает подтверждения) в вашем журнале и данных с помощью BBWC.
NVRAM без надлежащей поддержки со стороны ОС (VFS) не поможет вам ни с чем, что BBWC (который в любом случае является своего рода NVRAM) не может решить. В Linux 2.4 была поддержка некоторых устройств NVRAM для ускорения NFSv2 / 3, которые работают синхронно, но BBWC сделали их устаревшими.
Правильно относиться к флеш-устройствам не думать о них как о блочных устройствах, а использовать их как то, чем они являются - флеш-память NAND. Но это потребует изменения того, как, по нашему мнению, файловая система должна взаимодействовать с базовым хранилищем более общим образом. В ядре также нет подходящего API для использования флеш-памяти NAND.
Единственный ответ на данный момент - это от Нильса, но, согласно моим комментариям, есть устройства iRAM и Hyperdrive. Так что я закрою это
SSD-диски не следует использовать для частых операций записи. Почему бы вам просто не поместить журнал на отдельную отказоустойчивую RAID-систему (5 или 10), состоящую из обычных дисков (как минимум 4 «маленьких»)?