Количество винтов не играет никакой роли, т.к. массив восстанавливается параллельно на всех, а не по-очереди на каждом.
Дайте-ка угадаю. У Вас FreeBSD c UFS? :) А если бы использовали журналируемую ФС - минута на восстановление журнала и дальше работать.
fsck несколько дней? Такой disaster recovery plan - это epiс fail
Что-то дорого, есть вариант дешевле ;)
Вам завтра, может быть, сменят права на файлы, которые уже есть в системе. Но все новые файлы все равно будут иметь такую же проблему. Для ее устранения нужна перенастройка сервера и переработка управляющей логики. Как мне кажется, учитывая праздники, на решение вопроса в первые 2 недели января рассчитывать не стоит.---------- Добавлено 31.12.2012 в 04:23 ----------
Дешево что ли? У них цены не сильно благосклонные вроде.
Нет, не сильно. Латентность suPHP клиенты на глаз вряд ли увидят, а если и увидят, то она будет скорее всего не значительной. Разница хорошо будет видна только на графике загрузки CPU и, возможно, DISK IO.
Какие Вам нужны пруфы? Вы на архитектуру посмотрите. suPHP - это модуль апача, который занимается только тем, что в момент запроса он дергает РНР интерпретатор, ставит ему setUID и подсовывает интерпретатору скрипт для выполнения. "Дергание" интерпретатора на каждый запрос - операция накладная (в терминологии ресурсов). Поскольку каждый раз нужно "подымать" с диска в память сам интерпретатор, ворох модулей к нему, приклеивать модули к нему, лепить это все в одно целое и только после этого РНР сможет начать заниматься обработкой скрипта. Т.е. перед тем как запрос начнет обрабатываться должно пройти какое-то время, которое будет потрачено на накладные расходы - "компилирование" интерпретатора.
Совсем другая ситуация в случае ITK, который по своей сутки является префорком, который позволяет использовать mod_php. Тут алгоритм обработки несколько иной. Во-первых интерпретатор компилируется один раз - в момент запуска апача. Дальше экземпляры интерпретатора размножаются путем дешевого (в терминологии затрат ресурсов) fork'а. Во-вторых, в памяти постоянно префоркнуто несколько экземпляров. При поступлении запроса картина его обработки выглядит следующим образом: пришел запрос на выполнение скрипта, готовому интерпретатору делается setUID и передается скрипт для выполнения. Как видите накладная операция компилирования интерпретатора отсутствует.
Если провести аналогии с арендой серверов, то это примерно выглядит так:
suPHP: пришел клиент, попросил сервер в аренду. Едем к поставщику шасси, берем шасси, по пути заезжаем к другому поставщику за процессором, потом на другой конец города за винтами, звоним четвертому, просим подвезти память, приезжаем, собираем, выдаем. Клиент доволен.
prefork: Пока у нас было свободное время - мы заранее подготовили 10 серверов типичных конфигураций. Пришел клиент, попросил сервер в аренду. Оплатил и моментально получил сервер, который был установлен нами заблаговременно. Клиент счастлив.
Есть еще peruser, который префоркает уже setUID'нутые процессы, что еще более ускоряет обработку запроса. Но проблема в том, что ему нужно держать в памяти минимум один процесс на каждый виртуалхост. Что при нескольких сотнях виртуалхостов будет иметь примерно такие же последствия как если взять и просто отстрелить себе ногу. Не настолько накладен setUID, чтобы сотни апачей в памяти висели.
Тут вот еще почитать можно:
http://blog.stuartherbert.com/php/2008/01/18/using-suphp-to-secure-a-shared-server/
http://blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/
http://blog.stuartherbert.com/php/2008/03/20/using-mpm-peruser-to-secure-a-shared-server/
Об этом только хостеру известно.
Тут дело не в сапе. Ваша сапа - это частный случай одной большой, давно известной проблемы, которой уже есть много решений. Тут дело в непонимании техническим персоналом базовых, фундаментальных вещей.
suphp - это был удачный костыль для apache 1.3, который являлся вполне сносным решением 3 года назад. На сегодня он уже устарел. Как и сам apache 1.3. Все плюшки suphp сегодня можно получить за счет других средств, которые обеспечивают более высокую производительность и являются более универсальными.
Само собой не обязаны. Я об этом как раз и говорю. Просто не все хостеры/админы понимают как правильно предоставлять сервис.
Его - это кого?
