[Аппаратный RAID]Выключение кэширования в VM

Отсутствует в man 8 mount. Система: СЛЕС11СП1

Ты хочешь странного, vm — это не просто файловый кэш, это еще mmap файлы и прочее. Если ты хочешь свести к нулю оптимизацию ввода-вывода, тебе планировщик IO надо поменять, например на noop

А зачем это нужно? Кеш рейд контроллера обычно в разы меньше оперативной памяти.

Чтобы все операции записи на ЖД были синхронизированы как минимум с контроллером. На нем батарейка есть, и продержит она достаточно долго для того, чтобы восстановить работу сервера и дозаписать засевшие в его памяти данные на массив. Оперативка таким свойством не обладает, более того, обнуляется при рестарте сервера после краха/восстановления питания/етц.

На сетевые файловые системы мне в данном случае плевать - на этом сервере их нет и не будет.

более того, обнуляется при рестарте сервера после краха/восстановления питания/етц

На аппаратный RAID денег хватило, а на ЮПСку, чтобы сервер успел скинуть все данные на диск и нормально завершить работу - нет?

Да, как-то не очень понятно. Хороший упс с мониторингом - и сервер выключается сам красиво и корректно. И не очень понятно причем здесь кеш чтения, при такой параное как раз -o sync очень помогает, но тормозит в итоге аццки.

Бесперебойник есть, но мы же говорим о совсем нештатной ситуации. Сейчас серверная перестраивается в «горячем» режиме (без пыли). Строители могут просто задеть оба два кабеля на блоках питания. Ядро может просто упасть. Мало ли что еще. А сервер планируем сделать весьма критичным стораджем.

Ок. Как сделать write-through? Чтение сколько угодно пусть кеширует.

sync чем плох я так и не понял?

Я же спросил в первом посте, mount -o sync спасает? Или ты о

while true; do sync; sleep 1; done

man mount:

The following options apply to any filesystem that is being mounted (but not every filesystem actually honors them - e.g., the sync option today has effect only for ext2, ext3, fat, vfat and ufs):

ext4 и xfs пролетают ?

Есть еще несколько глобальных параметров write cache

$ ls /proc/sys/vm/*dirty*
/proc/sys/vm/dirty_background_bytes 
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio 
/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_bytes
/proc/sys/vm/dirty_expire_centisecs

Нет, я именно о параметре монтирования sync, но читай выше про ограничения - нужно проверять с конкретной файловой системой, работает оно или нет. Но в любом случае, ты страдаешь фигнёй. Приклей провода к серверу и упсу, цепями обмотай :) Синхронная запись еще со времён ДОСа и smartdrive не катит :)

Ну по сути это всё равно не будет синхронной записью, даже если затюнить VM до минимума.

Я ж еще раз повторяю: за асинхронность у меня контроллер должен отвечать, но никак не операционка, которая может и упасть вместе со всем кешем записи или, что страшнее, с его частью. На выходе fs может превратиться в тыкву, массив-то выживет. Тем более нет правды в мире: xfs по одним слухам «УМВР», по другим «УМНР» (а там более 20ТБ на выходе; ext4 не катит даже с патчем, не говоря о том, что слесовцы прямо сказали: есть ext3 для всяких root и есть xfs, а потом и уазикФС, для storage).

Весть о том, что xfs игнорирует sync еще больше удручает.

Да мы поняли, что контроллер должен отвечать, но это, поверь мне, тупиковый путь, т.к. производительность падает ОЧЕНЬ сильно.

А XFS то sync поддерживает вполне себе:

# dd if=/dev/zero of=/mnt/raid1_360Gb/test bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.887437 s, 1.2 GB/s
# mount -o remount,sync /mnt/raid1_360Gb
# dd if=/dev/zero of=/mnt/raid1_360Gb/test2 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 102.184 s, 10.5 MB/s

Ну, сильно-не сильно, но должна быть в пределах: DAT + RCCCO - RCAPL, где

DAT - Drive average throughput (порядка тех же самых 50-60МБ/с) RCCCO - RAID Controller Command Cache Optimization (в зависимости от конфигурации массива оцениваю до 30% от DAT в усредненном показателе) RCAPL - RAID Controller Array PayLoad (ну, всякие там контрольные суммы посчитать и прочея, как раз те же 30%, но в максимальном показателе и сильно зависит от мощей контроллера)

Разве нэ? Впрочем, как приедут уже нормальные винты, а не Caviar Green, на которых рейд разваливается так и не собравшись, буду тестировать с sync и без него. Посмотрю, что да как.

По описанию подходит: http://xgu.ru/wiki/Raw-устройства

Теория она такая теория. В режиме sync файловая система сбрасывает синхронно на винт и данные и метаданные, которые хранятся в совершенно разных местах, поэтому большую роль играет время поиска. Головка винта постоянно дёргается. При async эти данные кешируются и записываются пачками тут и там. Отсюда и такое падение. С большим массивом с кучей винтов, возможно, будет иначе, выше я проверял на RAID1 из двух обычных десктопный винтов. У меня есть XFS на 21Тб RAID6, но пока его в sync перемаунтить и проверить не могу, но при случае проверю.

Я же написал про RCCCO, контроллер должен совместно с NCQ заниматься сортировкой. При таком раскладе даже одиночный винт должен (мало, но) чуть лучше себя чувствовать. А в R5/R6 конфигурациях - и того лучше.

Да, и будет возможность заранее протестировать, буду премного благодарен.

Боюсь, что обычные файловые системы на character-девайсе работать не будут.

mount -o sync спасет, включит write through.