День добрый. Возникли проблемы с файловой системой, конкретно необходимо максимально отрубить кэширование всех ее структур, чтобы максимально сохранять целостность ФС при резком отключении питания (Debian 2.6 kernel). Читал в нете, нашел указания на параметр /proc/sys/vm/vfs_cache_pressure - но это несколько не то конечно. Разумеется если после каждого write делать sync() проблема частично решается, но это в принципе очень избыточно и неудобно по времени исполнения (фактически sync дважды подряд сбрасывает все кеши на диск). Сейчас смотрю в сторону правки исходного кода ядра, например после каждой модификации каких-либо структур или данных сразу сбрасывать изменения на диск. В связи с этим хотел бы узнать ваше мнение, стои ли этим заниматься или например запустить демона, который бы вызывал sync с некоторой периодичностью (что-то типа pdflush). А еще интересует есть ли какие готовые решения или патчи на ядро.
сначала посмотри linux/Documentation/filesystems/proc.txt (раздел 2.4) если ничего из перечисленного там не поможет, будем думать дальше
Поглядел, попробовал подтюнить следующие параметры: Код (Text): echo "1" > /proc/sys/vm/dirty_writeback_centisecs echo "0" > /proc/sys/vm/dirty_expire_centisecs echo "0" > /proc/sys/vm/dirty_background_ratio echo "100000" > /proc/sys/vm/vfs_cache_pressure результат надо сказать так себе, контролируя визуально доступ к диску и поэкспериментировав могу сказать что кэши сбрасываются никак не раньше 1 с (в лучшем случае). потом прочитал в одной статье следующее: "if a writeback event takes longer than a dirty_writeback_centisecs interval, then leave a one-second gap". Нашел в ядре это место: Код (Text): static void wb_timer_fn(unsigned long unused) { if (pdflush_operation(wb_kupdate, 0) < 0) mod_timer(&wb_timer, jiffies + HZ); /* delay 1 second */ } сразу заменил HZ на dirty_writeback_interval и пересобрал ядро. Резульат неоднозначный - опять таки поэкспериментировав получил следующее: то кэши сбрасываются почти одновременно с записью, то опять блин до 2-3 секунд промежутки. Это конечно не дело, надо как-то осуществлять сразу сквозную запись через кэш на диски. Да, забыл сказать, еще на всякий пожарный сделал "renice 18 pdflush".
to r90: да, это помогло в принципе, но интересует вопрос а все ли всетаки скидывается на диск? например метаданные или еще что. А то откопал у mount еще и параметр dirsync - вроде для синхронизации директорий и фиг знает что так еще может быть. to all а еще напрягает неравномерность времени записи на диск (после монтажа с sync), колебания по времени до 90 миллисекунд на один write! Ну время записи большое это уже ничего не поделаешь, интересно из-за чего, пробовал ставить разные дисциплины диспетчеризации процессов - результат тот же. Может это pdflush периодически просыпается и надолго лочит кэши? Можно ли его какнибудь отлучить от сброса кэшей файловой системы или это важная часть этого механизма? ЗЫ не подумайте что я тут ерундой страдаю, просто на работе требуют
sync -- это полноценный sync, то есть если пишется что-то на дискету и write отработал, то дискету можно вытаскивать. Любопытно чего же такого требуют... Если: То чем не устраивает журналируемая фс? ext3 у меня ни разу не падал из-за неожиданных выключений. Потери данных, которые за последнюю секунду были write в кеш, но не успели sync на диск? Ну если этот временной промежуток хочется уменьшить, я бы сделал так: Код (Text): #include <unistd.h> int main () { if (fork ()) { return 0; } if (fork ()) { return 0; } chdir ("/"); close (STDIN_FILENO); close (STDOUT_FILENO); close (STDERR_FILENO); while (1) { usleep (100000); sync (); } }
спасибо за совет, sync в принципе нормаьно подходит, просто хотелось, что бы время записи на диск было более-менее одинаковым, а то замеряю сколько делается write, оказывается разброс в разы! И дисковой активности то вроде нет, своп отключен, pdflush вообще почти не просыпается и приоритеты повышал (nice=-19), пробовал разные ioscheduler-ы для диска. Вот щас собрал ядро с опциями CONFIG_PREEMPT и CONFIG_PREEMPT_BKL - таже петрушка, что такое не пойму.
Я подозреваю всё просто упирается в количество чтений/записей которые надо сделать в ответ на write. Там же не просто сектор переписать, быть может к файлу ещё один inode прицепить, быть может не один, может быть найти свободный блок. Поэтому, думаю и возникает разброс.
Нет, файл создается один раз creat-ом и блоки пишутся одинакового размера в него с начала файла (файловая система смонтирована c опцией sync), одновременно выводится статистика времени выполнения write, после нескольких записей файл закрывается. Если процессу понизить nice, то временные отклонения становятся реже, но все равно есть, думаю что это закидоны шедулера процессов или в/в шедулера. Ну да ладно, в принципе я с этим смирился, спасибо и на этих советах, но конечно если будут идеи - буду благодарен.
coder_x Это ты пишешь блоки одинакового размера. А драйвер фс на каждый твой блок производит одну или более записей. Если при записи твой блок перевалил через границу в 4096 байт (или какой у тебя там размер блока фс?), то драйвер должен из свободных блоков на диске выбрать ещё один, удалить его из списка свободных, добавить в список блоков файла и вписать туда данные. Если речь идёт о журналируемой фс, то всё становиться ещё чуть сложнее. Я не настолько знаток формата ext2/3, чтобы сказать точно сколько секторов жёсткого диска будет переписано, но явно не один.
r90, ты не понял, после каждой записи блока я делаю seek опять на начало файла, т.о. пишется на одно и тоже место все время.
