Тогда "просто забить", увы.
Плохая, негодная телепатия. Я вовсе никак не связывал качество кода с арестом кого-либо.
Файловая система в ядре - значит кто-то ее сопровождает. Я даже знаю как узнать кто ;)
Все это, однако, не гарантирует безошибочность ее работы и отсутствие багов в самой FS или утилитах.
Ага. А не потеряли-ли вы в процессе этого счастья какие-то данные?
А данные и не должны так меняться, если FS их правильно записала. Операция либо доведена до конца - либо все связанные с ней "данные" просто невалидны. В этом смысл журналирования.
Повторяю, не факт что проблема не связана конкретно с reiserfs.
В смысле, reiserfschk работает? Я бы не сказал что это "нормально".
Может имеет смысл заменить эту файловую систему?
[102486.375622] REISERFS error (device md1): vs-2100 add_save_link: search_by_key ([-1 1802542 0x1001 DIRECT]) returned 1 [102486.381161] REISERFS (device md1): Remounting filesystem read-only [104091.351195] REISERFS warning (device md1): clm-6006 reiserfs_dirty_inode: writing inode 1676038 on readonly FS
Выглядит не как проблема с журналом. Что, по-идее - весьма странно.
У вас raid1?
Все чуть сложнее, вам объясняли как-то.
В общем, наверное этот сценарий имеет смысл в принципе. С другой стороны, соглассованность данных гарантируется ведением журнала.
Пока все-же больше похоже на проблемы конкретно reiserfs.
Какого рода проблемам, можно подробнее?
Ну, в этом случае - вы как раз и "ручками запишете что-то разное на блины".
Вот только вряд-ли это приведет к реальным проблемам (потерю части "кривозаписанных" данных за таковую не считаем). Таки журналируемые файловые системы используют обычно. Странно, что reiserfs у вас портился.
Теоретически, нормально исправить проблему можно, но разработчик очень подробно объяснил (см. баг в дебиане) почему это приведет к существенному снижению производительности (или переусложнению). Короче, более разумного решения чем "забить на это для raid1/raid10" - нету и не предвидится.
Боюсь, что никак. Речь лишь о том, что для некоторых типов рейда - эти показатели фактически бесполезны.
С другой стороны, сценарии "реальных проблем" с mismatch_cnt != 0 на raid1 придумать сложно. Ну, разве вы ручками запишете что-то разное на блины.
Тем не менее, вы предложили конкретное объяснение. Неверное в принципе.
Разбивка по-умолчанию.
Болезный, ты читать умеешь?
Наверно, подразумевали таки весь конфиг nginx. Вместе с содержимым include.
Там nginx перед апачем - эта настройка бессмысленна.
Разжуйте на кой хрен столько апачей. Только ради того, чтобы залезть в своп лишний раз - или вам просто цифири круглые нравятся?
ТС - ограничьте поиск, начните с этого.
Какой тип RAID? Если raid1/raid10 - это нормально. В ином случае - повод для беспокойства.
Дело там не во включенном swap во время проверки. Дело во включенном swap вообще. Хотя, к подобной "рассинхронизации" приводят еще несколько сценариев.
http://bugs.debian.org/518834
С подачи дебиана все давно поправили в документации (man 4 md, раздел SCRUBBING AND MISMATCHES).
Смарт должен запускаться регулярно. Для этого есть smartd.
Не удивительно, учитывая подобные смешные суммы (на полчаса работы максимум). И то, что Вы явно мешаете задачи администратора и саппортов в одну большую кучу.
Это сколько, например?
1) Откуда вы знаете, что проблема в днс? 2) Что мешало уточнить у "админа" последовательность действий, которые он делает за 10$?
Из этого списка более-менее осмысленно звучит последний пункт. Вы способны детализировать остальные "ТЗ"? Во сколько их оцениваете?
apt-get install php5-imagick
Если это не работает - ваш сервер испорчен :)
Рад за вас. Но щенячий восторг от супермикры в этом случае, имхо, был неуместен.
Вообще, начинать стартап со своего оборудования - лучше тогда, когда требования к нему предельно ясные (и нет приемлемых вариантов аренды). Иначе - стоит посмотреть в сторону аренды оборудования.
