inotify умеет следить только за одной папкой. В частности, это значит, что придётся в ядре хранить по несколько десятков байт для каждой папки и при запуске - сканировать всю ФС.
Raistlin: 400 Гб файлов клиентов в RAID1... Что-то незаметно, бекаплю раз в сутки. _не инкрементально_, просто бекап непрерывный и не торопливый... т.е. сутки и бекапится =).
И все сутки у Вас получается снижена производительность :(
Raistlin:
Ни одно имя мне ни о чем не говорит.
:(
Raistlin:
Позволю себе высказать только мысль, что в кернелспейсе не должны работать подобные процессы - это глупо. Но вот вешать в ядро то, что в общем-то там быть не должно - как-то не айс. Правильнее - перехватывать чтение в юзерспейсе и именно в нем же составоять лог. Ядро - значит ядро, а не прикладной софт и оно не должно заниматься ерундой.
Способы перехватить сисколлы в Linux:
1) Линковка со своим open(), close() и так далее. Обходится. Сложна в компиляции - абсолютно всё нужно слинковать с другими библиотеками. Процесс, выполняющийся от пользователя, должен уметь писать в общий лог, либо нужно уметь собирать кучу логов.
2) ptrace на все процессы. Съест, наверно, 30-40% Вашего cpu на анализ и на лишние шесть переключений контекста на каждый сисколл.
3) Модуль ядра. Получается то же самое, только длиннее и неудобнее - нужно подставляться в таблицу сисколлов и получать то же самое в итоге.
Raistlin:
Для этого есть журналируемые ФС...
Вы уверены, что понимаете, зачем есть журналируемые ФС?
bugsmoran: Ну так клиент же не знает об этом. 4 сборки = 4 тестирования, но не 4 выката на продакшен. На продакшен дай Бог каждое 20-е или 30-е ядро попадает. Сейчас уже конечно не 4 за ночь. Почти всего, что нужно добились. Вот только баг неприятный всплыл, но уже он закрыт.
Ну всё равно получается минимум - ребут в месяц. Это заведомые 5 минут дауна в месяц, что достаточно плохо.
Плюс, скорее всего, при тестировании на продакшене вылезет что-то достаточно нехорошее, что потребует ещё 5 минут перезагрузки.
Осознание этого в основном и останавливает от использования подобных фич на более-менее серьезном проекте. Хотя, может быть, начальство когда-нибудь созреет до необходимости инноваций.
bugsmoran: Первый адекватный человек на форуме ))) Только им не понять. У них беготня между хостингами (или между серверами хостера) - нормальное явление. Для них спокойствие не есть ценность. А может просто потроллить хотят, скучно наверно без дела сидеть.
Спокойствие - это "пересобирание ядер по 4 раза за ночь потому что эффект всегда получается немного не тот"? :) Баланс всё-таки нужно соблюдать, хотя мне действительно намного ближе инновационная система ведения техники, чем legacy.
WhiteSuite: Ок, тогда вопрос. Почему во всех картинках filemgr? Это не вопрос доказывающий, мою правоту. Тем более я не могу понять, на какую тему вы со мной спорите. Это просто вопрос, на который никто из вас отетить не может. А факт на лице: filemgr во всех 100% случаев паники ядра.
Это уже другой вопрос - что там накосячили, из-за чего у Вас функция падает :) Думаю, посмотрев стрейсом бинарник менеджера файлов, ответ станет очевиден. И если Вы вызовете эту функцию из другой программы, то ядро так же упадёт.
Спорю я, собственно говоря, о том, что проблема - в патче от BlueHost или еще кого-то, а не в ядре с kernel.org или ispmgr, потому что любой вызов любого сисколла из юзерспейса никогда не должен приводить к панике в ядре, и в kernel.org это достаточно неплохо соблюдается.
Увы, прочитав патч от фаствпс на 2.6.32 не могу придумать случая, когда это должно падать :(
WhiteSuite:
Ядро с патчем от мейнтейнеров конкретного дистрибутива не называется ванильным. А ядро, скачанное с kernel.org ванильное.
Тут я полностью согласен.
WhiteSuite:
Впрочем я не настаиваю на терминологии. Главное, что ядро с kernel.org, а патч с BlueHost, только переделанный нашим инженером.
Но ядро с kernel.org с патчем с BlueHost это не ядро с kernel.org :)
WhiteSuite: Если Вы помните, что на картинке, то там именно это приложение сбивалось. Никакое другое. Просто так этот баг не вылезет. Видимо переменная all_path тоже была "не такая".
Но если это делало одно приложение, то, теоретически, это могло делать и другое и, на самом деле, Вы должны быть безумно рады, что ispmanager это воспроизвел. Так как в противном случае об этом мог бы случайно узнать недоброжелатель и каким-нибудь chmod(0, 0) долго класть все Ваши серверы.
inotify умеет следить только за одной папкой. В частности, это значит, что придётся в ядре хранить по несколько десятков байт для каждой папки и при запуске - сканировать всю ФС.
400 Гб файлов клиентов в RAID1... Что-то незаметно, бекаплю раз в сутки. _не инкрементально_, просто бекап непрерывный и не торопливый... т.е. сутки и бекапится =).
И все сутки у Вас получается снижена производительность :(
Ни одно имя мне ни о чем не говорит.
:(
Позволю себе высказать только мысль, что в кернелспейсе не должны работать подобные процессы - это глупо. Но вот вешать в ядро то, что в общем-то там быть не должно - как-то не айс. Правильнее - перехватывать чтение в юзерспейсе и именно в нем же составоять лог. Ядро - значит ядро, а не прикладной софт и оно не должно заниматься ерундой.
Способы перехватить сисколлы в Linux:
1) Линковка со своим open(), close() и так далее. Обходится. Сложна в компиляции - абсолютно всё нужно слинковать с другими библиотеками. Процесс, выполняющийся от пользователя, должен уметь писать в общий лог, либо нужно уметь собирать кучу логов.
2) ptrace на все процессы. Съест, наверно, 30-40% Вашего cpu на анализ и на лишние шесть переключений контекста на каждый сисколл.
3) Модуль ядра. Получается то же самое, только длиннее и неудобнее - нужно подставляться в таблицу сисколлов и получать то же самое в итоге.
Для этого есть журналируемые ФС...
Вы уверены, что понимаете, зачем есть журналируемые ФС?
Ну так клиент же не знает об этом. 4 сборки = 4 тестирования, но не 4 выката на продакшен. На продакшен дай Бог каждое 20-е или 30-е ядро попадает. Сейчас уже конечно не 4 за ночь. Почти всего, что нужно добились. Вот только баг неприятный всплыл, но уже он закрыт.
Ну всё равно получается минимум - ребут в месяц. Это заведомые 5 минут дауна в месяц, что достаточно плохо.
Плюс, скорее всего, при тестировании на продакшене вылезет что-то достаточно нехорошее, что потребует ещё 5 минут перезагрузки.
Осознание этого в основном и останавливает от использования подобных фич на более-менее серьезном проекте. Хотя, может быть, начальство когда-нибудь созреет до необходимости инноваций.
Кроссплатформенно - это когда волшебные числа берутся из заголовков :)
gfs (не от гугля, а от редхета)
Первый адекватный человек на форуме ))) Только им не понять. У них беготня между хостингами (или между серверами хостера) - нормальное явление. Для них спокойствие не есть ценность. А может просто потроллить хотят, скучно наверно без дела сидеть.
Спокойствие - это "пересобирание ядер по 4 раза за ночь потому что эффект всегда получается немного не тот"? :) Баланс всё-таки нужно соблюдать, хотя мне действительно намного ближе инновационная система ведения техники, чем legacy.
а гиде патч то? я так понимаю это чуть ли не варез. легальное не скачаешь.
Я тут читал - http://fastvps.googlecode.com/svn/trunk/patches/bluehost-backup-fastvps-edited-patch-2.6.32.diff
Все придумывают способ любимому форуму заработать ещё денег :) Вот бы они пошли на то, что бы он перестал падать!
Ок, тогда вопрос. Почему во всех картинках filemgr?
Это не вопрос доказывающий, мою правоту. Тем более я не могу понять, на какую тему вы со мной спорите. Это просто вопрос, на который никто из вас отетить не может. А факт на лице: filemgr во всех 100% случаев паники ядра.
Это уже другой вопрос - что там накосячили, из-за чего у Вас функция падает :) Думаю, посмотрев стрейсом бинарник менеджера файлов, ответ станет очевиден. И если Вы вызовете эту функцию из другой программы, то ядро так же упадёт.
Спорю я, собственно говоря, о том, что проблема - в патче от BlueHost или еще кого-то, а не в ядре с kernel.org или ispmgr, потому что любой вызов любого сисколла из юзерспейса никогда не должен приводить к панике в ядре, и в kernel.org это достаточно неплохо соблюдается.
Увы, прочитав патч от фаствпс на 2.6.32 не могу придумать случая, когда это должно падать :(
Ядро с патчем от мейнтейнеров конкретного дистрибутива не называется ванильным. А ядро, скачанное с kernel.org ванильное.
Тут я полностью согласен.
Впрочем я не настаиваю на терминологии. Главное, что ядро с kernel.org, а патч с BlueHost, только переделанный нашим инженером.
Но ядро с kernel.org с патчем с BlueHost это не ядро с kernel.org :)
Если Вы помните, что на картинке, то там именно это приложение сбивалось. Никакое другое. Просто так этот баг не вылезет. Видимо переменная all_path тоже была "не такая".
Но если это делало одно приложение, то, теоретически, это могло делать и другое и, на самом деле, Вы должны быть безумно рады, что ispmanager это воспроизвел. Так как в противном случае об этом мог бы случайно узнать недоброжелатель и каким-нибудь chmod(0, 0) долго класть все Ваши серверы.
Ну так а патч на ядро.
Ядро с патчем не называется ванильным ;)