Я тут заметил различие между значениями в lzo1_overrun и теми которые находятся в ядре в lzo.h. В lzo1_overrun "хвост" вычисляется как: "in_len / 64 + 16 + 3". В ядре в lzo.h худший случай (при несжимаемом файле) определен как: "((x) + ((x) / 16) + 64 + 3)", т.е. если вычесть x хвост будет in_len / 16 + 64 + 3. Собственно в примерах minilzo (которую помнится R4 и использовал) используется тот-же вариант, что и в ядре.
Это так и должно быть?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Привет! Для компрессии в Reiser4 я использовал оригинальную библиотеку lzo Маркуса Оберхамера. Соответственно, указанное значение lzo1_overrun брал из неё. Это было 12 лет назад, когда в ядре ещё не было никакого lzo. Потом где-то в 2007 году в ядро добавили его поддержку сильно искромсав оригинальные исходники (несмотря на протесты автора). Ну, и нам пришлось перейти на ядерную версию. Откуда взялась такая разница я сейчас с ходу не скажу, надо основательно в это погружаться. А что, есть какие проблемы?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Да, я сейчас заглянул в оригинальный minilzo, и там OUT_LEN вычисляется как IN_LEN + IN_LEN / 16 + 64 + 3. То есть, ошибка, выходит, у меня. Исправлю. Спасибо!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Насчет проблем сложно сказать с чем они именно связаны, с ccreg40 или оборудованием, да и частота его появления, получается что, сильно зависит от условий. Будем пробовать, будем смотреть.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Недавно мы выявили связь спонтанных повреждений ФС с дефицитом памяти в системе (в частности, когда активизируется oom-киллер). Я пытаюсь найти участки кода критичные к ошибке ENOMEM. Пока что есть рекомендация не использовать reiser4 в системе без swap-раздела (стандартного рекомендованного размера).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добрый день.
С приложенным патчем (прилагать его надо из директории reiser4) система у меня корректно проработала 100 часов без swap-раздела под нагрузкой. На большее время пока не могу зарезервировать машину. Вобщем, пробуйте, чекайте раздел хотя бы раз в неделю, делитесь опытом...
Доброго времени суток!
Я тут заметил различие между значениями в lzo1_overrun и теми которые находятся в ядре в lzo.h. В lzo1_overrun "хвост" вычисляется как: "in_len / 64 + 16 + 3". В ядре в lzo.h худший случай (при несжимаемом файле) определен как: "((x) + ((x) / 16) + 64 + 3)", т.е. если вычесть x хвост будет in_len / 16 + 64 + 3. Собственно в примерах minilzo (которую помнится R4 и использовал) используется тот-же вариант, что и в ядре.
Это так и должно быть?
Привет! Для компрессии в Reiser4 я использовал оригинальную библиотеку lzo Маркуса Оберхамера. Соответственно, указанное значение lzo1_overrun брал из неё. Это было 12 лет назад, когда в ядре ещё не было никакого lzo. Потом где-то в 2007 году в ядро добавили его поддержку сильно искромсав оригинальные исходники (несмотря на протесты автора). Ну, и нам пришлось перейти на ядерную версию. Откуда взялась такая разница я сейчас с ходу не скажу, надо основательно в это погружаться. А что, есть какие проблемы?
Да, я сейчас заглянул в оригинальный minilzo, и там OUT_LEN вычисляется как IN_LEN + IN_LEN / 16 + 64 + 3. То есть, ошибка, выходит, у меня. Исправлю. Спасибо!!!
Насчет проблем сложно сказать с чем они именно связаны, с ccreg40 или оборудованием, да и частота его появления, получается что, сильно зависит от условий. Будем пробовать, будем смотреть.
Недавно мы выявили связь спонтанных повреждений ФС с дефицитом памяти в системе (в частности, когда активизируется oom-киллер). Я пытаюсь найти участки кода критичные к ошибке ENOMEM. Пока что есть рекомендация не использовать reiser4 в системе без swap-раздела (стандартного рекомендованного размера).
Добрый день.
С приложенным патчем (прилагать его надо из директории reiser4) система у меня корректно проработала 100 часов без swap-раздела под нагрузкой. На большее время пока не могу зарезервировать машину. Вобщем, пробуйте, чекайте раздел хотя бы раз в неделю, делитесь опытом...