nilfs2 на /home — как оно?

Использовал ~полгода, были неудаляемые файлы, неизвестно откуда взявшиеся + некоторая потеря данных (бэкапы помогли). Но всё это было довольно давно, о нынешнем состоянии не в курсе.

о, месье тонкий извращенец

Сфигали? Крайне удобная вещь. Аналоги через fuse в разы тормознее. На ssd есть прочие профиты, но мне они были пофиг. А бэкапы делать в любом случае.

Просто то же пробовал использовать, особого профита с ext3/ext4 не заметил для себя.

Возможность вернуться к произвольному состоянию ФС — вполне себе киллерфича.

>Просто то же пробовал использовать, особого профита с ext3/ext4 не заметил для себя.

Э-э-э... Ну как-бы x3al все высказал.

Пробовал использовать... Долго ли использовал? Под какие задачи использовал? Проблемы были?

А, да. Нужно понимать, что достаточный объём ФС должен оставаться свободным, иначе сборщик мусора достанет и основное преимущество сойдёт на нет. Я частично обходил это вынесением кэшей и прочих tmp за пределы ФС.

она жрет очень много места. лучше посмотри в сторону btrfs, она более-менее стабильна и не так прожорлива

Использую NILFS2 с августа месяца с момента выхода ядра 3.0 как корневую ФС. В случае внезапного вырубания питания ведёт себя просто замечательно. За это время такая ситуация случалась 4-5 раз - ничего потеряно не было, восстановление после сбоя мгновенное.
Фичя со снапшотами оказалась чрезвычайно удобна для бэкапов. Не хватает только работающих роллбэков (разрабы обещают сделать когда-нибудь).
В 3-ем ядре похоже что-то доработали, т.к последний раз пробовал NILFS2 во времена ядра 2.6.34 - остался недоволен низкой производительностью, и тем, что после того как поиграл немного с ручным созданием\удалением чекпоинтов\снапшотов - фс сдохла.
По тестам и личным ощущениям общая скорость держится на уровне между ext3(со включенными барьерами) и ext4. Производительность при работе с маленькими файлами и метаданными на уровне ext3. Работа со средними файлами в районе нескольких метров субъективно быстрее.
Замеченные проблемы:
1) rpm при установке пакетов не всегда может корректно определить наличие свободных инодов. В результате установка некоторых пакетов заканчивается неудачно. Помогает опция --ignoresize. Я себе просто пропатчил rpm, для установки нужных флагов автоматом. Судя по гуглю - этот глюк иногда возникает и на других экзотических ФС. С остальными программами проблем пока не заметил.
2) старые nilfs-utils до версии 2.1.0 - редкостное УГ. Особенно сборщик мусора. В версии 2.1.0-rc2 сборщик мусора работает намного адекватнее, быстрее, и куда менее заметнее. Судя по чейнджлогу в старых nilfs-utils были и другие серьезные проблемы.

За 3,5 месяца работы с NILFS2 на ядре 3.0 проблем с потерей или повреждением данных пока небыло. Но всё-таки важные данные я пока на ней не храню - только система, с регулярным бэкапом на случай выхода ФС из строя.

> у меня ноут иногда отрубается - наверное, из-за перегрева

Я вытащил ksensors в трей. http://img26.imageshack.us/img26/6104/snimok283.png Для KDE 4 должно быть что-нибудь такое, а для Gnome есть applet.

протестировал NILFS2 работает медленно, при отключении во время записи сохраняет недописанный файл при следующем монтировании.

Лучшего мнения оставляет XFS скорость записи раз 3-5 быстрее, чем NILFS2. При отключении во время записи, XFS восстанавливает последнее состояние файлов, как и положено для журналируемой ФС. Обнуления, в которым упрекают XFS не обнаружил ни разу как ни старался, наоборот, восстанавливались стертые файлы.

Там место свободное медленно освобождается, он может говорить что нет места на разделе, хотя по идее дофига

А я к сожалению сталкивался с обнулением файлов на XFS. При систематических сбоях с питанием как правило обнуляются файлы только что созданные и уже «сохраненные», но еще не успевшие сбросится на диск благодаря отложенному размещению (одно из свойств XFS). Чаще всего таким образом повреждаются разнообразные конфиги в домашнем каталоге.
Хуже всего было, когда я потерял 3 часа работы - начал писать научную статью для универа, регулярно делал ctrl+s, а потом вырубили электричество. И вуаля - пустой файл.

С обнулением файлов, которые были созданы и сохранены на диск давно, открытых на запись в момент краха - я не сталкивался ни разу за 3 года использования XFS. Если присмотреться - жалобы на потери данных на XFS в основном не новее 2008 года. Может быть разработчики исправили этот досадный недостаток.
Ну а в остальном для повседневных задач хранения информации, торент-помойки, и особенно для работы с бооольшими файлами - лучше XFS не найти на мой взгляд. Рейзер у меня разваливался, ext3 разваливался. Единственная ФС которая у меня еще ни разу не разваливалась это XFS. Обнуление новых файлов было, но полного краха ни разу.
А возвращаясь к теме о NILFS - в теории на ней потеря данных возможна только в пределах чекпоинта, которые создаются раз в несколько секунд. Если её как следует допилят - то думаю что это будет идеальная ФС для хранения документов, и просто важных данных. А для всего остального видимо будет BtrFS.

> А для всего остального видимо будет BtrFS

Эта та FS, маинтейнер которой не знает алгоритмов?

Фиг знает, что там не знает маинтейнер, но идея замечательная - не он же один её делает...

> Фиг знает, что там не знает маинтейнер, но идея замечательная

Действительно, замечательная: спустить всё дисковое пространство в туалет. Ещё давайте slab-аллокатор заменим на что-нить, так чтоб у продавцов железо пошустрее разбирали..

>Там место свободное медленно освобождается, он может говорить что нет места на разделе, хотя по идее дофига

А если сделать rmcp?

Кстати, скорость высвобождения места, насколько я понял, настраивается в nilfs_cleanerd.conf

Насчет обнуления файлов в XFS — это с барьерами или без было?

Барьеры не так давно появились (где-то в районе 2.6.17), плюс их можно отключать (не помню, как там у XFS по дефолту, может и отключены...)

Обнуление было со включенными барьерами, к сожалению.

Вот когда сделают именованные снапшоты, попробую еще раз пересесть на него :)

Да, именованных снапшотов весьма недостает...