не имеет смысла увеличивать max_post_size из скрипта, потому что к моменту запуска скрипта переменные уже обработаны
может быть "очень большие строки" (вы не сказали насколько именно) передаются методом GET ? тогда браузер или сервер могут не передавать слишком длинный url
вы так и не сказали есть ли у вас suhosin ? нужно вывести phpinfo и поискать слово "suhosin".
вероятность довольно большая, ведь он есть в freebsd ports и в debian и в производных от него.
есть неприятные, на первый взгляд необъяснимые варианты с suhosin, когда переменные очищаются при недостаточных размерах max_post_size. надо все увеличить и проверить.
Himiko, так и что? размер конторы не обязательно означает, что персонал сплошь квалифицированный. На чьи же еще деньги существует весь узкопрофильный на IT-консалтинг и интеграторы ? :)
По факту мы имеем, что основные дистрибутивы линукса озаботились проблемой и сделали специальные проверяющие массивы скрипты, а значит проблема НЕ высосана из пальца и завтра может коснуться лично вас.
Himiko, они просто не знают. Тут ведь как повезет. После внезапного пропадания питания я наблюдал не чинящуюся файловую систему на рассинхронизировавшихся дисках.
myhand, да, действительно. я имею ввиду что скрипт checkarray появился в mdadm 3, но centos его конечно же не включает в новые версии. С собственным скриптом тоже неплохой вариант.
Тогда неужели никто эти логи не читает и не замечает рассинхронизации ?
Pilat, Средства контроля данных в самом диске тоже есть и достаточно надежны.
Пожалуй, это может происходить только при частых внезапных перезагрузках в ужасном ДЦ, когда не на все диски успевает записаться информация. В этом случае есть контроллеры с батарейкой и с некоторых пор в mdadm появился скрипт сверяющий массив раз в месяц.
В centos, как обычно, не появился :)
И еще там в комментах вспомнили, что на практике raid5 не делает сверку при чтении. То есть, при определении самого факта ошибки в данных ДАЖЕ в случае с raid5 на практике полагаются на внутренние механизмы диска.
bimcom: -эмулятор, то это колеса вашей личной разработки, которые подходят к машине клиента, пусть они не такие современные как у производителя авто, но они крутятся (и тут не понятно за что конфисковали сервера)
Так еще в лицензии может быть запрещен reverse engineering протокола. То есть, создание любой совместимой клиентской или серверной программы возможно нарушает лицензию и, соответственно, незаконно.
не имеет смысла увеличивать max_post_size из скрипта, потому что к моменту запуска скрипта переменные уже обработаны
может быть "очень большие строки" (вы не сказали насколько именно) передаются методом GET ? тогда браузер или сервер могут не передавать слишком длинный url
вы так и не сказали есть ли у вас suhosin ? нужно вывести phpinfo и поискать слово "suhosin".
вероятность довольно большая, ведь он есть в freebsd ports и в debian и в производных от него.
есть неприятные, на первый взгляд необъяснимые варианты с suhosin, когда переменные очищаются при недостаточных размерах max_post_size. надо все увеличить и проверить.
ну а сколько там штук переменных ? если там php с suhosin, то запросто.
Ваш сервер попал в топ10, но вы просмотрели в отчете как ОСТАЛЬНЫЕ хосты сделали весь трафик 2097.59 ГБ.
Сколько можно мучать бабушку ?
Заголовка Expires как не было так и нет - значит не работает кеширование на клиенте.
Блокировки по referer тоже - значит можно перевставлять картинки в блоги и форумы.
Вы либо за трафик платите, либо человека наймите.
Himiko, так и что? размер конторы не обязательно означает, что персонал сплошь квалифицированный. На чьи же еще деньги существует весь узкопрофильный на IT-консалтинг и интеграторы ? :)
По факту мы имеем, что основные дистрибутивы линукса озаботились проблемой и сделали специальные проверяющие массивы скрипты, а значит проблема НЕ высосана из пальца и завтра может коснуться лично вас.
Himiko, они просто не знают. Тут ведь как повезет. После внезапного пропадания питания я наблюдал не чинящуюся файловую систему на рассинхронизировавшихся дисках.
myhand, да, действительно. я имею ввиду что скрипт checkarray появился в mdadm 3, но centos его конечно же не включает в новые версии. С собственным скриптом тоже неплохой вариант.
Тогда неужели никто эти логи не читает и не замечает рассинхронизации ?
Pilat, Средства контроля данных в самом диске тоже есть и достаточно надежны.
Пожалуй, это может происходить только при частых внезапных перезагрузках в ужасном ДЦ, когда не на все диски успевает записаться информация. В этом случае есть контроллеры с батарейкой и с некоторых пор в mdadm появился скрипт сверяющий массив раз в месяц.
В centos, как обычно, не появился :)
И еще там в комментах вспомнили, что на практике raid5 не делает сверку при чтении. То есть, при определении самого факта ошибки в данных ДАЖЕ в случае с raid5 на практике полагаются на внутренние механизмы диска.
vadson, но работает же. и в ослике и везде. В линуксе только не работает до сих пор.
-эмулятор, то это колеса вашей личной разработки, которые подходят к машине клиента, пусть они не такие современные как у производителя авто, но они крутятся (и тут не понятно за что конфисковали сервера)
Так еще в лицензии может быть запрещен reverse engineering протокола. То есть, создание любой совместимой клиентской или серверной программы возможно нарушает лицензию и, соответственно, незаконно.
ну вообще-то проблема чтения там была :
Mar 2 07:52:14 ksrv kernel: [305416.912738] sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
конечно нужно посмотреть smart и, если сервер арендованый, копировать данные и требовать замены hdd.