Btrfs или ext4?

И не будет, там есть install.

Fedora по умолчанию устанавливает LVM с ext4 разделами(если дать анаконде самой разметить диск). Сам подумай, на передовом дистрибутиве красношапки для всяких (поцтерринго)разработок, используется ext4 по умолчанию. Даже не смотря на то, что Леннарт что-то там кудахтал про крутость btrfs. Если даже полигон не использует btrfs, может стоит задуматься?

А так, я пробовал btrfs. Он достаточно штабилен чтобы им пользоваться для домашних утех(всякие там особые режимы со сжатием, или особые флаги не настраивал. юзал, так сказать, по умолчанию). Но до меня дошли слухи, что btrfs(от того, кто пользовался ей дольше чем я) может даже на таком непринуждённом использовании подохнуть без возможности какого-либо восстановления. Сами разрабы btrfs считают, что если ФС прожила 3 года, то это исключительный случай. И что их проверялка целостности ФС может вполне сама по себе всё грохнуть. Я не знаю, верить или не верить, но решил не рисковать. Всё же ни разу не было на моей памяти такого, чтобы ext4 грохнулась сама по себе, и невозможно было выковырять данные.

Ухх, всё, установился... Анимация стала плавнее и быстрее, но не намного. Наверное, зря я это всё затеял. Время покажет.

Поздно прочитал я этот коммент! Наверное, оставил бы ext4. Что ж, btrfs так btrfs. Посмотрим, как долго проживёт система...

Эрзент случаем не твой брателло?

какая всё-таки файловая система будет интереснее для этой задачи - btrfs или

интереснее - конечно бтрфс. Ерзент вон сколько раз работу менял, пришел - бтрфс! и опять работу искать. А если нужно чтобы не интересно, а просто хранить, то - или.

Наверное потому, что сотрясение мозга получили при прыжках в высоту?

скорее всё-таки ты проврался, как обычно

скорее всё-таки ты проврался, как обычно

Ну да, и ещё гугл проврался тоже. Все врут, и эпичный факап с дедлоком при монтировании при загрузке не существует - это всё происки гугля в войне против оракла. Правильно, так держать.

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

Тогда не забывай делать бэкапы.

Это само собой разумеющееся (независимо от выбранной FS)!

zfs

По моему локалхостоадминскому мнению btrfs на последних ядрах конфетка.
Но ядро годовой давности уже чего то не умеет,вплоть до не желания монтировать ФС.
И вообще,менее стабильное ощущение.
В общем либо самые последние ядра с миграцией потом только на будущие версии,либо с btrfs лучще повременить.

Btrfs имеет смысл для извращений типа «файлопомойка на нескольких дисках разного размера, у каждого блока две копии на разных дисках». На обычном десктопе нуегонафиг, ext4 стабильнее.

Их в любом случае нужно делать.

ext4 быстрее

Как хорошо, что я делаю бакапы. Вчера внезапно отключили свет, сегодня BTRFS не монтируется. Пока, пока, оракловская поделка, да здравствует старые добрые lvm с ext4.

ext4

Я сейчас попробую вырубить внезапно комп...посмотрим, что станет с btrfs. Если долго не будет в комментариях, значит я занят переустановкой системы))). Пока установка свежая, можно поэкспериментировать.

Только что выткнул внезапно из розетки работающий комп. Работает, как ни в чём не бывало! Может всё дело не в btrfs, а в железе?

Только что выткнул внезапно из розетки работающий комп.
Работает, как ни в чём не бывало! Может всё дело не в btrfs, а
в железе?

уж к чему к чему, а к внезапному отключению электроэнергии — btrfs стойкая.

темболее у анонимуса (как он утверждает) она даже монтироваться перестала. это вообще феноменально!

Не исключаю. Ибо всякие багованные инит скрипты сквидов, могут оказаться где угодно.

Но когда факт использования какой-либо ФС, заставляет делать бекапы чаще, ибо внезапно может настать пиздец, это не нормально.

Несколько дней назад уже ловил этот глюк без всяких отключений питания, после btrfs-convert двух переносов между дисками и переключений опций монтирования (clear_cache) mount висит в состоянии 'D' и в конце концов начинает вываливать стектрейсы в dmesg. btrfs check данные спасает, но все ошибки не исправляет (при проверке ругается на какие-то некореектные данные).

Может всё дело не в btrfs, а в железе?

Возможно дело в luks, не знаю. Но в любом случае, висящий mount это ненормально.

Работает, как ни в чём не бывало!

После первого отключения комп загрузился, но сразу же свет отключили второй раз. Возможно btrfs в это время что-то исправляло в фоне.

вот стектрейсы: http://pastebin.com/JjtRy5LF

К стати да,у меня тоже нечто похожее.

Иногда после резета или некорректного ребута начинает проверять ФС и на этом нет,не повисает,правильнее будет сказать прекращает дальнейшею активность.
Я тогда нажимаю на резет,он запускает проверку btrfs снова она завершается нормально и он грузится нормально.

При грамотном распределении nodatacow и compress

Разъясни, пожалуйста.

Может fstab некорректно настроен?

Кажется это новая проблема в ядре 3.19.1

https://bugzilla.opensuse.org/show_bug.cgi?id=926385

https://btrfs.wiki.kernel.org/index.php/Gotchas

Расскажите пожалуйста,в чём там может быть дело.
Монтирование по UUID,так что перетасовка устройств в /dev сказываться не должна,а других причин для такого поведения на поверхности не видно.

ext4

Уже не удивляет такая ситуация. Такое впечатление, что разрабатывают кадавра голодные индусские дети.

Разъясни, пожалуйста.

А чего тут разъяснять? Логи и кэши (не только браузерные) в nodatacow, ибо нафиг не надо; медию и архивы хранить без компрессии, ибо толку ноль их жать, а ресурсов сожрёт на катание камня в гору. Конфиги можно жать в lzo или без сжатия, ибо они читаются часто, логи в zlib. Это просто логично.

медию и архивы хранить без компрессии, ибо толку ноль их жать, а ресурсов сожрёт на катание камня в гору

На самом деле btrfs не сжимает уже сжатые данные. Не знаю каким образом идет определение типа контента, но опция compress не жмет несжимаемое.

https://btrfs.wiki.kernel.org/index.php/Mount_options:

compress,compress-force Enable compression. Starting with kernel 2.6.38 you can choose the algorithm for compression:

compress=zlib - Better compression ratio. It's the default and safe for olders kernels. compress=lzo - Faster compression. compress=no - Disables compression (starting with kernel 3.6).

compress-force=<method> - Enable compression even for files that don't compress well, like videos and dd images of disks. The options compress-force=zlib and compress-force=lzo works for kernels >2.6.38.

Логи и кэши (не только браузерные) в nodatacow, ибо нафиг не надо

а как же сжатие? при nodatacow сжатие не работает

Жмет первый блок, и смотрит сжался он или нет. По словам разработчиков «This is not optimal and subject to optimizations and further development»

Ужас. Оказывается процессорное время все равно тратится на сжатие.

А вы знали, что

Most mount options apply to the whole filesystem, and only the options for the first subvolume to be mounted will take effect. This is due to lack of implementation and may change in the future.
This means that (for example) you can't set per-subvolume nodatacow, nodatasum, or compress using mount options. This should eventually be fixed, but it has proved to be difficult to implement correctly within the Linux VFS framework.

? https://btrfs.wiki.kernel.org/index.php/Mount_options

Кстати, как btrfs ведет себя на старых машинах с hdd? Можно получить небольшое увеличение производительности или CPU гоняется в хвост и гриву? Поделитесь опытом.

На самом деле btrfs не сжимает уже сжатые данные.

Enable compression even for files that don't compress well, like videos and dd images of disks.

Сам написал, сам нашёл себе опровержение. Под компрессией я подразумевал не только compress, но и compress-force.

Сам написал, сам нашёл себе опровержение. Под компрессией я подразумевал не только compress, но и compress-force.

Почему же опровержение. Если беспокоишься за ресурсы процессора, то включай compress, а не compress-force. Будет и сжатие и проц холодный.

Я уже раскурил всё это дело, ещё при переходе на сабж. У меня всё грамотно раскидано по сабволюмам с нужными мне параметрами монтирования. Я только медию храню на reiserfs-разделе, вся система располагается на одном btrfs-разделе с сабволюмами. Сам раздел не монтирую, есть subvol, на котором лежит корень, а в него уже монтируется всё остальное.

Проще. Тестировал на hdd самых разных - btrfs медленнее ехт4.