ы. Опять таки по ощущениям с большим количеством файло он вроде быстрее всех.
newzenonПросто, намекаю на то, что experimental - полезный репозиторий.
А в подписи у меня вроде как Debian sid / experimental. 
newzenonНет? А я думал переформатировать свой home с Feiser3 на Feiser4
.
Дальше мыслей дело пошло?
]]>Ну и выход там вроде есть:
Ммм... А у меня важные данные в sqlite хранятся, чтобы её таким хаком заделывать oO
]]>Нет? А я думал переформатировать свой home с Reiser3 на Reiser4 .
Ну и выход там вроде есть:
1. Собрать библиотеку libnosync.so и поместить её в /lib (или /lib64).
2. Затем добавляем принудительную подгрузку этой библиотеки ко всем динамическим бинарникам:echo "export LD_PRELOAD='libnosync.so'" >> /etc/profile
Таким образом при следующем логине любого пользователя к любой запускаемой им программе будет применена попытка перезаписать внешние вызовы фунций синхронизации на пустышки. К статическим бинарникам (таким как sync и sudo) это не относится.
Это конечно не дело, интересно а разработчики reiser собираются с эти что-то делать?
Darth Revan, так не вопрос где взять 2.3.36, дело в том, что как-бэ обещание было что поддержка reiser4 появится в этом ядре, а ее нет, к тому же 2.6.36 на kernel.org уже объявлено как стабильное. А причем LibreOffice?
]]>Одним из ключевых понятий Reiser4 является транзакция: грубо говоря, одна атомарная транзакция - это пачка операций с ФС. Транзакционная запись повышает сохранность данных, однако всегда есть и обратная сторона медали: при частых, искуственно вызванных fsync(), мы получаем огромный оверхэд на дисковых транзакциях, и скорость записи многократно падает.
Принудительную синхронизацию ФС вызывает множество программ и утилит, начиная от банального статического sync и заканчивая sqlite, встроенного в amarok. Скорее всего под другими ФС этот факт не ощущался настолько сильно и ярко, как под Reiser4. Тем не менее, с этим приходится считаться.
Эт конец. Зачем нужна такая ФС? Особенно мне, ярому приверженцу sqlite?
]]>