netwind

не имеет смысла увеличивать max_post_size из скрипта, потому что к моменту запуска скрипта переменные уже обработаны

может быть "очень большие строки" (вы не сказали насколько именно) передаются методом GET ? тогда браузер или сервер могут не передавать слишком длинный url

вы так и не сказали есть ли у вас suhosin ? нужно вывести phpinfo и поискать слово "suhosin".

вероятность довольно большая, ведь он есть в freebsd ports и в debian и в производных от него.

есть неприятные, на первый взгляд необъяснимые варианты с suhosin, когда переменные очищаются при недостаточных размерах max_post_size. надо все увеличить и проверить.

ну а сколько там штук переменных ? если там php с suhosin, то запросто.

Ваш сервер попал в топ10, но вы просмотрели в отчете как ОСТАЛЬНЫЕ хосты сделали весь трафик 2097.59 ГБ.

Сколько можно мучать бабушку ?

Заголовка Expires как не было так и нет - значит не работает кеширование на клиенте.

Блокировки по referer тоже - значит можно перевставлять картинки в блоги и форумы.

Вы либо за трафик платите, либо человека наймите.

---request begin---
GET /img0/7f770e41.jpg HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: wowlol.ru
Connection: Keep-Alive
Referer: kremlin.ru

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 04 Mar 2010 23:52:59 GMT
Content-Type: image/jpeg
Content-Length: 109976
Last-Modified: Thu, 04 Mar 2010 17:41:37 GMT
Connection: keep-alive
Accept-Ranges: bytes

---response end---
200 OK
Registered socket 1824 for persistent reuse.
Length: 109а976 (107K) [image/jpeg]

Himiko, так и что? размер конторы не обязательно означает, что персонал сплошь квалифицированный. На чьи же еще деньги существует весь узкопрофильный на IT-консалтинг и интеграторы ? :)

По факту мы имеем, что основные дистрибутивы линукса озаботились проблемой и сделали специальные проверяющие массивы скрипты, а значит проблема НЕ высосана из пальца и завтра может коснуться лично вас.

Himiko, они просто не знают. Тут ведь как повезет. После внезапного пропадания питания я наблюдал не чинящуюся файловую систему на рассинхронизировавшихся дисках.

myhand, да, действительно. я имею ввиду что скрипт checkarray появился в mdadm 3, но centos его конечно же не включает в новые версии. С собственным скриптом тоже неплохой вариант.

Тогда неужели никто эти логи не читает и не замечает рассинхронизации ?

Pilat, Средства контроля данных в самом диске тоже есть и достаточно надежны.

Пожалуй, это может происходить только при частых внезапных перезагрузках в ужасном ДЦ, когда не на все диски успевает записаться информация. В этом случае есть контроллеры с батарейкой и с некоторых пор в mdadm появился скрипт сверяющий массив раз в месяц.

В centos, как обычно, не появился :)

И еще там в комментах вспомнили, что на практике raid5 не делает сверку при чтении. То есть, при определении самого факта ошибки в данных ДАЖЕ в случае с raid5 на практике полагаются на внутренние механизмы диска.

vadson, но работает же. и в ослике и везде. В линуксе только не работает до сих пор.

Так еще в лицензии может быть запрещен reverse engineering протокола. То есть, создание любой совместимой клиентской или серверной программы возможно нарушает лицензию и, соответственно, незаконно.

ну вообще-то проблема чтения там была :

конечно нужно посмотреть smart и, если сервер арендованый, копировать данные и требовать замены hdd.