Даже имаксы с вимами до сих пор пилят. Скоро номера версий превысят госдолг США. Наверное, всё борятся с серьезными проблемами.

я не знаю, как они это сделали, но теперь в шары влезают файлы длиной в ~260 русских букв, для вендоюзеров - щастье

Лишь бы это не было как с пакером, который может ужать 1Гб в 10 байт. Только анпакера еще нет.

блин... а я только новый диск разметил в btrfs... как жить теперь?

Поезд ушёл

И ЛОР говорит, что у Reiser4 нет шансов, хе-хе... ;)

Печаль.

UTF-8 - двухбайтный.

В каком месте он двухбайтный?

Хочется услышать Шишкина

cast post-factum

Скажите, как там интервью с Эдуардом Шишкиным? Можно ли узнать его мнение о Btrfs и отказе RedHat от поддержки этой ФС в будущем?

устаревшими в RHEL 6.8
устаревшей в рамках линейки RHEL 6.x.

RHEL6.8 не использую, и 6.9 не планирую, и тем более не планирую в них использовать Btrfs, если её там нет.

Я был уверен в том, что btrfs ещё не готова, а тут говорят, что, мол, устарела. :)

Интересно, что на вики Btrfs в графе «Additional features in development, or planned, include:» раньше было прозрачное шифрование, а теперь - нет. Передумали? Не осилили?

Reiser4

Вот кстати да, бтрфс если сдыхает, то остаётся только убегать и хоронить раздел.
Рейзер4 прекрасно реконструируется через fsck.reiser4 --rebuild-tree.
Но в ядре её нет.

Кол-во шклоты в треде

нормальная формулировка. Какая еще должна быть?)

что такое ecryptfs?

шифрование файлов (а не диска), типа encfs

А что дает вот это ФС с шифрованием?

например бэкап только изменённых файлов (а не всего диска)

Самостоятельно поднимать крышку унитаза

Но в ядре её нет.

А вы сами поднимаете крышку унитаза, или просите кого-нибудь?

Патчи Reiser4 лежат, бери не хочу. Человек с ★★★★★ должен бы уметь собирать подходящее ядро, а не жаловаться «того нет, этого нет».

Если перестали пилить код, значит, серьёзных проблем нет

facepalm

я не знаю, как они это сделали, но теперь в шары влезают файлы длиной в ~260 русских букв, для вендоюзеров - щастье

Смотря для какой файловой системы.В ALTе этой проблемой занимались с 13 года и по описанию в ихнем вики для ext2-4 многое пришлось бы пилить,с возможной поломкой совместимости (хотя было предложение в использование не удаленной старой структуры от ехт1 для использование в качестве расшерения >254 символа).Для BTRFS,XFS падчи оказались тривиальны, не удивлюсь если ихние правки наконец то вошли в серьезный дистрибутив.Самое смешное что по описанию в ихней вики для NTFS правки не потребовались :-)

А в grub/syslinux поддержка reiser4 есть? То-то же.

MAX_PATH - 16384 для уникодовых функций.

Ты поперёк чтоли читал статью ? Там же указано :

maximum total path length of 32,767 characters

Тролли 80ого левела. Объяснение реальных мотивов будет?

Systemd окончательно доломал debian testing

Угу, недавно стал загружаться через раз из-за корректных дубликатов в fstab (2 диска с noauto). Хорошо хоть старую систему не успели выпилить.

У меня с самого появления stretch работает идеально.

Проверь очистку /tmp после перезагрузки, у меня не очищает.

нет вдоль. а что надо было поперёк?

Что же что же?

А в grub/syslinux поддержка reiser4 есть? То-то же.

В SYSLINUX не знаю, не интересовался никогда. В GRUB есть. Что вы хотели сказать?

- Скажите, а что случилось с Btrfs?
- Она устарела.

таки-да ошибся не 16384 а 32768. просто в голове первое большое число после 4096 было 16384 )

Почему «в будущем», если речь только о 6.8?

Интервью в процессе.

Вижу только reiserfs в модулях

Ну хотя бы снапшоты reiser4 умеет?

Как-бы то, что он сказал правда. Только серьезные проблемы начинаются с нескольких сотен тысяч файлов, и как правило это следствие, того, что фс использовали не по назначению (сотни тысяч файлов/миллионы файлов в одном каталоге), вместо БД. Но это не отменяет того, что у ext* действительно есть такие проблемы.

Угу, правда, только не на тысячах, а на миллионах, и не мелких, а вообще. А так-то всё верно, ага.

Проверь очистку /tmp после перезагрузки, у меня не очищает.

Советую зарепортить баг. Просто я когда-то сделал systemctl enable tmp.mount (вроде так), а tmpfs в очистке не нуждается. Вообще очистка /tmp это не фича systemd, так что вопрос к мейнтейнерам.

Снимок_дампа_снапшота.mkv.tar.rar

Вижу только reiserfs в модулях

Ну ок, GRUB поддерживает, GRUB2 не поддерживает. Убедили.

Ну хотя бы снапшоты reiser4 умеет?

Снимки умеет LVM, этого более чем достаточно, потому что Reiser4 атомарная ФС. Более другие снапшоты не нужны, потому что атомарность операций Reiser4 гарантирует, что на LVM'овском снимке будет корректное состояние ФС.

Ясно. Не нужно.

Ну дык, дистр для юзеров, которые про ZFS вообще не слышали.

Всё это происки АНБ и Госдепа, а может ещё и наше ФСБ добавилось.
То-то мне помниться они жаловались на то, что сквозное сжатие затрудняет анализ информации на конфискованных дисках.
В общем имхо это может быть звоночком к тому, что пора RedHat закопать.

Когда читал первые обзоры btrfs в начале 201х годов, то она преподносилась как продолжение ext3 и реальная альтернатива также ещё разрабатываемой тогда ext4.

Сейчас по тестам производительности ФС, которые я увидел на Phoronix, btrfs на последнем месте с большим отрывом от всех других. Кто-нибудь может это подтвердить или опровергнуть? Как реально она по скорости?

Архитектурно-то btrfs тащит. Сам недавно конвертнул весь жёсткий диск в один большой раздел btrfs, в котором сделал подтома /boot, /home, /var и пр. Тут не нужно создавать много разделов, как для ext4. Делаю снапшоты btrfs для каждого подтома - одна простая команда, делает тебе бэкап за 0 сек. Киллер-фича.

Как правило в следствие того, что проблемы начинаются когда фс используют вместо БД или неправильно организовывают структуру проекта, это как раз мелкие файлы. Никто в здравом уме, тем более не будет использовать ext* под большие хранилища. Сарказму, тут не место.

На hdd btrfs тормозная, как и любая cow-фс.

Тесты похороникса — последнее, на что нужно смотреть при принятии решения.

Делаю снапшоты btrfs для каждого подтома - одна простая команда, делает тебе бэкап за 0 сек.

Не спасает от сдохшего диска.

Делаю снапшоты btrfs для каждого подтома - одна простая команда, делает тебе бэкап за 0 сек.

Хочу напомнить, что пока этот снапшот не выгружен на удаленное хранилище, бэкапом его называть некорректно.

snapshot - ни разу не бэкап. Вот если его потом send/receive'нуть куда-нибудь, на внешний хард, например, - тогда да, бекап. Еще и инкрементальный.

Вот для чего я её, бтрфс, уж точно не советую использовать, так это для хранения образов VM. Даже с nocow атрибутом на файлах это полный треш и содомия. > 50000 экстентов за только лишь время установки гостевой ОС. Убедился лично.

ext2-то зачем ?

Для миниатюрного boot-раздела нет смысла отдавать 25-50% места под журнал. Просто монтируй с -o sync, Люк.

Речь об устаревании драйвера btrfs версии 2.6.32

Я чёт не понимаю кипеша типа «btrfs признали устаревшей». В RHEL 6 ядро 2.6.32 и соответственно код btrfs в нём юный, неокрепший, и к нынешнему моменту переписан примерно полностью. Устарела эта ветка, а не современное состояние btrfs.

вот оно что оказывается

опять лор-эффект

Для миниатюрного boot-раздела нет смысла отдавать 25-50% места под журнал.

Там не будет 25-50% места под журнал, это раз, журнал можно и отключить, это два.

Человек с ★★★★★ никому ничего не должен. Эти звёздочки, как правило, означают, что человек уже давно наблюдается у ЛОР, но никоим образом не означает уровень каких-либо знаний относительно Linux. И даже не обязывает к этому.

и отказе RedHat от поддержки этой ФС в будущем?

Btrfs и eCryptfs не рекомендованы к использованию в рамках RHEL 6.х (комментарий)

То о чём ты говоришь есть LUKS (пакет cryptsetup) и с ним всё ок. Речь идёт насколько я понял о пакете encfs, который даже при установке в убунте сообщает о том что программа является уязвимой к ряду атак.

Речь идёт насколько я понял о пакете encfs

Неправильно понял. Encfs работает через fuse, а ecryptfs в пространстве ядра.

но зачем /boot вообще журнал?вот у меня 160 метров /boot ext2, по скольку патч для btrfs пилить не хотят, а самому ядро лень переделывать.