А я могу "угадать" :) Раз кеши у вас сбрасываются при отмонтировании - то меняется информация в sys/vm. Следовательно, да - временные метки на файле меняются (как и на всех остальных в каталоге).
Больше нет. Цена - основной критерий, определяющий риски и бюджет защиты.
Заявляется, что подобная ситуация возникает только в двух случаях:
1) кто-то трогает явно один из дисков, минуя рейд
2) приложение работает с сильно временными данными, в ситуации когда оно *в принципе* не собирается их позднее читать (mmap, swap и т.п.)
Обе в принципе, не позволяют утверждать наглость "это не рейд".
А вот это мне тоже не нравится. Не знаю, однако, может последние ядра дают администратору больше информации (например, в /sys/). Надо бы почитать...
Вроде только в тодо:
http://neil.brown.name/blog/20110216044002#12
Нет, конечно. Просто "большие" по абсолютной величине mismatch_cnt (~1k) - ровно ничего не говорят порой об интенсивности использования swap.
Это нормально в конкретной ситуации (использование swap и т.п.).
Начните с того, что отключите swap.
Это простой тест, забыли? kill -9 как раз приблизительно эквивалентен внезапному отключению питания. С физической железкой, конечно, лучше - но не думаю что есть принципиальная разница в данном случае.
Неуд.
На низком уровне _не может_ быть ахинеи, когда этот самый уровень (или уровни, к примеру если у вас между ФС и диском еще и LVM есть) барьеры поддерживает. Вы бы познакомились немного с предметом.
Поподробнее. Опишите свои действия.
Объяснение покуда штатное из man md "SCRUBBING AND MISMATCHES", в частности учтите то что пишет рейд в ответ на check/repair. Например, после repair c исправленными mismatch_cnt!=0 - показатель md/mismatch_cnt будет ненулевым! Судя по приведенному выводу команд - для вас это неожиданность.
Ну и плевать. ФС с барьерами просто не посчитает такую транзакцию.
да хоть savedefault?
Трогать определенно нужно, вопрос лишь в том - только ли на чтение.
nonamexx, попробуйте
quotaoff -v -a
quotacheck -v -a
quotaon -v -a
И у какого, интересно? - вы читать умеете, или просто не понимаете что вам показали.
repquota -a
покажите
Попросить кого-то это сделать.
Или покажите как минимум:
uname -adfmountquotacheck -a
Тогда это тоже баг - либо в md, либо где-то уже ниже (вплоть до прошивки контроллера). По идее, write cache не должен мешать md, "if the programmers make the right call(s)" (тм).
barrier=1 (правда, md тоже должен их поддерживать, как и ФС, и LVM - если есть) должны исключить ситуацию с порчей данных ФС при резете из-за подобных вещей - но на это вроде не похоже.
Да, если бы вы исключили "манипуляции" с reiserfs непосредственно на дисках (загрузчик).
Многие = еще адын.
Возможно, вам повезло?
Поймите, мне интересна проблема и я не исключаю что дело в md. Просто не считаю, что вами исключены все иные варианты.
Если вам так все очевидно - где баг?
Разные файловые системы.
Ну а как иначе, если ее адепты багрепорт написать не осилят ;)
Потому что к чему вы это привели? Груб 2 нормально поддерживает по крайней мере raid1 (вроде все уровни уже умеет, хотя не факт что нормально ;)). Но у вас на проблемном сервере старый груб.
Скажем так, они могут вести себя "непривычно" в этом отношении. Как минимум, с определенных точек зрения.
Если воспринимать это как интерфейс к данным другой программы (ядра) - становится более понятным.
Да, но не все обязаны обрабатывать сисколлы одинаково. Можно запросто что-то типа EPERM возвращать в ответ на попытку unlink. Ну, или нечто более подходящее по статусу.
PS: Я нехорошо обозвал их "виртуальными". Вики говорит о procfs: a *special* filesystem.
Еще один открыватель банальности "procfs работает отлично от того, к чему я привык в /home/" ? ;) Как бы никто вам и не обещал.
Добро пожаловать, это виртуальная система. Правда, последняя ошибка (EACCES, если я корректно ее перевел) - по-моему не к месту.
дело хозяйское - обещаю вас игнорировать.
