Да, знаю, я специально указал Announcement date. Просто сёдня в очередной раз нашёл её на нескольких сайтах, решил написать на хабре, может админы заметят.
=)) Ну во-первых, не в кусты, а на обед.
Во-вторых я не писал, что это уязвимость nginx. Читайте внимательно.
Ну и в третьих проблема мне кажеться в том, что оказывается в переменной $fastcgi_script_name. У лайти такого например нету.
Кворум — это система защиты от split-brain в распределенных системах.
Кворумом обычно называют N/2+1 машин, где N — количество машин распределенной системы
По-русски, это означает, что если одна из частей кластера видит «падение» половины и более кворумных нод она(меньшая часть кластера) завершает работу. Сделано это для того, чтобы сохранить целостность данных на ФС, ведь в теории возможна ситуация когда часть машин оказалось изолированными от сети и им нельзя ни при каких условиях писать на диск, а также читать с него, ибо данные могут быть не актуальны.
Практически аналогичная ситуация с GlusterFS (есть у нас на одном из проектов ) — настроить так, чтоб не падало так и не получилось. На недельке обновим — посмотрим как новая версия будет себя вести.
А что ещё? Lustre — это не только ФС, но ещё и огроменный патч на ядро, который не так то просто прикрутить рядом с нашим Xen. Gluster имеет некоторые проблемы со скоростью Lock'ов.
GFS2, OCFS и тп, прибиты сбоку к SAN / NAS.
Поправил.
По поводу сборки я нечего не сказал, ибо сборкой занимался другой человек. У нас в компании для централизованой сборки пакетов используется OBS (может быть в скором времени и о нём напишем), благодоря чему на одного сотрудника ставится задание собрать пакет, а другой по завершении просто добавляет необходимый репозиторий и делает zypper in gpfs
Да, я давно хотел попроавить опечатки в recEive и segMentation но у меня теперь этот текст больше не редактируется.
Хабр пишет «Some error… We know...» может сильно client_max_body_size уменьшили
Отличный комментарий.
Да, действительно, если углубляться, то появляется множество нюансов, таких как, например, SMID и ему подобные.
Так же, как вы правильно заметили, оптимальные по времени алгоритмы обычно отличаются прожорливостью по памяти, из-за чего их применение может стать нецелесообразным.
ПС. Небольшое замечание: Требуемая память для работы алгоритма обычно заранее известна и выделяется единоразово, одном куском, тем самым потребляя совсем мало процессорного времени
Если хотите задавать вопросы — задавайте, пускай они даже будут глупыми/тривиальными, за это вас никто минусовать не будет. Но не стоит абсолютно не аргументировано наезжать на автора, он вполне логичен, во отличие от вас =)
Судя по php.net/manual/en/ini.core.php:
Available since PHP 4.3.0. PHP_INI_ALL prior to PHP 5.2.1.
/scripts/1px.gif/test.php
lighttpd:
/scripts/1px.gif
Во-вторых я не писал, что это уязвимость nginx. Читайте внимательно.
Ну и в третьих проблема мне кажеться в том, что оказывается в переменной $fastcgi_script_name. У лайти такого например нету.
По поводу кворумных нод — да это только защита от split-brain
Также у нод есть свой Designation — manager | client который определяет будет ли нода учавствовать в выборах file system и token менеджера
Кворумом обычно называют N/2+1 машин, где N — количество машин распределенной системы
По-русски, это означает, что если одна из частей кластера видит «падение» половины и более кворумных нод она(меньшая часть кластера) завершает работу. Сделано это для того, чтобы сохранить целостность данных на ФС, ведь в теории возможна ситуация когда часть машин оказалось изолированными от сети и им нельзя ни при каких условиях писать на диск, а также читать с него, ибо данные могут быть не актуальны.
Читайте, подмечайте интересные моменты =)
GFS2, OCFS и тп, прибиты сбоку к SAN / NAS.
По поводу сборки я нечего не сказал, ибо сборкой занимался другой человек. У нас в компании для централизованой сборки пакетов используется OBS (может быть в скором времени и о нём напишем), благодоря чему на одного сотрудника ставится задание собрать пакет, а другой по завершении просто добавляет необходимый репозиторий и делает
zypper in gpfsХабр пишет «Some error… We know...» может сильно client_max_body_size уменьшили
Будет ли когда-нибудь реализовано изменение innodb_buffer_pool_size «на лету»?
Да, действительно, если углубляться, то появляется множество нюансов, таких как, например, SMID и ему подобные.
Так же, как вы правильно заметили, оптимальные по времени алгоритмы обычно отличаются прожорливостью по памяти, из-за чего их применение может стать нецелесообразным.
ПС. Небольшое замечание: Требуемая память для работы алгоритма обычно заранее известна и выделяется единоразово, одном куском, тем самым потребляя совсем мало процессорного времени
Если хотите задавать вопросы — задавайте, пускай они даже будут глупыми/тривиальными, за это вас никто минусовать не будет. Но не стоит абсолютно не аргументировано наезжать на автора, он вполне логичен, во отличие от вас =)