SSD кэш для BTRFS

Btrfs ведёт себя крайне плохо то ли с LVM, то ли с LUKS (не помню, ибо не пробовал, но легко ищется на ЛОРе).

P.S. я в курсе что btrfs имеет склонность неожиданно превращаться в тыкву, не нужно меня предупреждать. Бекапы будут

Только не надейся в этом вопросе на снапшоты.

Да это понятно. Снэпшоты это защита от органической прокладки между стулом и клавой, а не от электронной между клавой и диском

Btrfs ведёт себя крайне плохо то ли с LVM, то ли с LUKS

Бред. Там были баги в этом направлении, но они давно исправлены (в ядре 3.2+).

Анон, давай не будем, а? Только позавчера у меня превратился в тыкву рут-партишн на Btrfs. Мне нравится Btrfs, но она ещё не готова. Я быстрее перейду на ZFS, чем вернусь на Btrfs, настрадался за три года, спасибо.

За эти три года у меня превращались в тыкву данные на диске восемь раз, ВОСЕМЬ раз, два раза я смог частично восстановить данные, последний раз я таки догадался не делать btrfsck, и спас данные почти полностью (кроме совсем битых). Снапшоты — это хорошо, удобно, но на такие жертвы я больше не пойду. Хватит.

Никаких, можно btrfs over bcache. А ещё можно дождаться bcachefs и/или задонатить Кенту Черезуличному на то, чтобы быстрее её пилил.

Если вспомнть сколько btrfs пилили до хотя-бы сегодняшнего состояния… Думаю bcachefs будет более-менее готов только к следующему моему капительному обновлению железа

А ещё можно дождаться bcachefs и/или задонатить Кенту Черезуличному на то, чтобы быстрее её пилил.

Это фантастика. btrfs вон пилят уже десятилетие.

Ещё никто в одно рыло не запилил надёжную современную ФС, даже ужасный Ганс Рейзер.

Есть у bcache какие-то способы посмотреть чем именно занят кэш и почему?

Да.

<знает про bcachefs>
Бекапы будут

Ты идеальный пользователь bcachefs, чего мнешься?

Да.

Какие?

Ты идеальный пользователь bcachefs, чего мнешься?

Не-не-не, btrfs это предел сырости на который я могу решиться

Не-не-не, btrfs это предел сырости на который я могу решиться

Может тогда посмотреть на zfs? Там вроде свое кеширование из коробки.

L2ARC, да. Вот только просто ARC (кэш в памяти) дублирует обычный линуксовый дисковый кэш. Удвоенный расход памяти это не хорошо.
А вообще ZFS штука вполне годная, использую на одном сервере и проблем почти не имею

Анон, давай не будем, а?

Не будь, я не против.

За эти три года у меня превращались в тыкву данные на диске восемь раз, ВОСЕМЬ раз

У меня ни разу за год. С dm-crypt. Может стоит купить компьютер вместо солянки с avito?

А чё, btrfs разваливается если ей не хватает CPU или RAM?

У меня ни разу за год.

Я тебя поздравляю. Только это ничего не значит.

А чё, btrfs разваливается если ей не хватает CPU или RAM?

Да этот анон дичь несёт, ты его слушай больше.

какие есть варианты кэширования btrfs на ssd?

Никаких вариантов нет, ибо никакой btrfs нет в природе. Есть какой-то код в непонятном статусе, релиза btrfs не было.

а эти три года у меня превращались в тыкву данные на диске восемь раз, ВОСЕМЬ раз,

Давно использую BTRFS для системных разделов, на домашнем компе у меня в него отформатирован хомяк.
Очень стабильно и надёжно работает.
Что вы такое делаете что у вас падает аж 8 раз за год?

В ZoL уже добавили fstrim?

Ой, свидетелей святой ZFS подвезли. MrClon, имей в виду — слова этого фанатика надо на пару порядков делить, что про btrfs, что про zfs.

Нет, конечно, не разваливается.

От свидетеля btrfs слышу. Вместо того, чтоб интегрировать reiser4 или помочь bcachefs они городят кривое поделие, при этом ведя себя настолько нагло, что хочется дать по рылу.

Одно то, что они себе интегрировали свой «менеджер разделов» дублируя типо присутствующую функциональность в ядре (один из главных аргументов против reiser4, кстати) и при этом никто в рассылке даже не пискнул - лишний раз доказывает преступный сговор.

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

P.S. и ZFS тоже монструозное говно с хреновым сжатием!

P.P.S кто-нибудь когда-нибудь осилит что-то на подобии squashfs, но в rw???

Не знаю.

Сам-то чё не осилил, критикун мамкин?

Что вы такое делаете что у вас падает аж 8 раз за год?

Интенсивно обновляемые git-репозитории, стабильное отключение электроэнергии. Эти две вещи не связаны, но обе повлияли на.

Слишком мало знаю (в процессе исправления этого)

Но пара идей есть...

И да, что осилять, если reiser4 готова, принимайте... но ее не принимают...

+ еще торренты (а если еще и на сжатом диске...)

От свидетеля btrfs слышу.

В отличие от пациента, я никогда не говорил и не говорю, что btrfs идеальна. Напротив, я подтверждаю, она кривая и медленная, но тем не менее во многих случаях работает.

Одно то, что они себе интегрировали свой «менеджер разделов» дублируя типо присутствующую функциональность в ядре <...> лишний раз доказывает преступный сговор

Сними шапочку из фольги и успокойся. Дублирования функциональности там нет. Подтома — не аналог LVM, multi-device RAID — не аналог md. Они работают иначе и принципиально лучше, чем «присутствующая функциональность в ядре».

сжатие кривое

Продемонстрируй.

метаданные разрастаются

Продемонстрируй.

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

chattr +C?

zfs <...> с хреновым сжатием

что-то на подобии squashfs, но в rw

Слушай, а как ты вообще можешь с таким уровнем знаний и бэкграунда что-то говорить про файловые системы? Anakros, плюсую тебя.

reiser4 готова

Не готова.

кто-нибудь когда-нибудь осилит что-то на подобии squashfs, но в rw???

Ну-ка, придумай, как изменить файл (не дописать в него!) не уничтожив данные, запакованные вначале и в конце (от других файлов) этого файла? Можно, конечно, переписывать блоки полностью, но это будет крайне накладно. В идеале можно исхитриться над f2fs+zlib, но получится говно. Можешь попробовать squashfs+overlayfs, это единственный вариант на данный момент.

Меня спросили как у меня это происходит. У меня на рут-партишн торренты никогда не качались. Разделение медии и системных/пользовательских данных — это не просто так.

Подтома — не аналог LVM, multi-device RAID — не аналог md. Они работают иначе и принципиально лучше, чем «присутствующая функциональность в ядре».

Что не мешало им пинать ногами reiser4 за аналогичный функционал, лол...

продемонстрируй

Скачай торрентами релизные диски деба (поставь все и сразу на закачку, должен быть хороший канал)

Советую делать это на отдельном разделе, во избежание.

как ты можешь... что-то говорить

Язык есть - вот и говорю :D

Вообще, я раскапывал принципы работы, так что понимаю, почему squashfs не rw. Мой крик души относился к тому, что я ни в какой фс не вижу lzma/другого алгоритма с высоким сжатием (хотя это очень бы пригодилось)

Да, тогда придется много мучатся с block suballocation (ведь для хорошего сжатия нужны большие блоки)

А я из-за этого периодически переставлял сид :D

Нада было ставить CentOS...

squashfs+overlayfs

Было. Задрало. Перелез на zram под / пока не задолбала невозможность забрать _сжатый_ образ фс оттуда без расжатия... (может такой фичреквест запилить?)

Скачай торрентами релизные диски деба (поставь все и сразу на закачку, должен быть хороший канал)

Проблема проявляется только на релизных дисках Debian? У меня на NAS три терабайта всевозможных торрентов, канал 10 MB/s в обе стороны, раздача вполне насыщает аплинк. По-моему, всё в порядке.

Что не мешало им пинать ногами reiser4 за аналогичный функционал

Аналогичный чему? Какой? В reiser4 никогда не было ни подтомов, ни multi-device, ни RAID.

ведь для хорошего сжатия нужны большие блоки

Ну вот ты и сам ответил на свой вопрос.

раздача

Не в этом проблема. Дохнет от фрагментирования, не успевая дефрагментироваться по ходу дела при скачке. ext4 тоже не сладко в таком режиме, однако падений не было. reiser4 же _очень_ сильно грузил процессор (ИИ он там что-ли запускал?! Или это из-за сжатия...) но не сдавался (и не сдох)

Аналогичный чему? Какой? В reiser4 никогда не было ни подтомов, ни multi-device, ни RAID.

Зато есть поддержка на уровне api для подобных расширений (и свой inode, т.к у них там деревья). Шишкина почитай, он хорошо описывал, почему не принимали и «причины» сопротивляющихся.

Ну я и говорю — канал насыщается, значит, при всей этой фрагментации хотя бы со скоростью 10 MB/s читать получается. Ну и норм. И падений в таком режиме я тоже ни разу не наблюдал, даже когда одновременно качал очень много всего.

Ссылку? Я видел из его слов только то, что сейчас reiser4 некому поддерживать (что в самом деле так). И причёсывать для совместимости с современным VFS там тоже нужно очень много.

Я говорю как раз про старые события, Шишкин просто уже и не хочет в это дело лезть.

И я немного напутал, пинали из-за vfs:

Reiser4 может войти в состав Linux во второй половине 2010 года

Интервью с Эдуардом Шишкиным о reiser4

И причёсывать для совместимости с современным VFS там тоже нужно очень много.

Чет незаметно, раз патчи работают - значит ничего и не поломано. То шо костыли... ты код китайских вайфаев видел? Вот пока такое в ядре, претензий к качеству кода reiser4 быть не может.

Понятно, ну тут и ext загнуться может, точнее даже быстрее загнётся, почему я и предпочитаю более сложную в установке btrfs.
Можно разве что время от времени ФС от и примонтировать обратно, чтобы не копить много записей в журнале.

OCHEN' TOLSTO

ext4 практически самая устойчивая к отключению света. (устойчивее только NILFS2, но у нее больше нет достоинств

Чет незаметно, раз патчи работают - значит ничего и не поломано.

Так себе аргумент. Например, совершенно явно поломаны R/W петлевые устройства (из файлов на reiser4). Далее, в reiser4 не поддерживаются никакие фичи VFS, появившиеся после 2.6.39. Расширенные атомарные переименования (exchange, noreplace), white-out'ы, атомарные временные файлы, ... — вот это всё.

А я из-за этого периодически переставлял сид :D

А вынуть данные или распаковать бэкап ума не хватило?

Вот именно поэтому я и пользовал Btrfs.

Журнал да, делает тормоза, захламляет метаданные и вообще. Вся надежда на ZFS, но мне лень.

ext4 практически самая устойчивая к отключению света.

Чушь. Btrfs теряет меньше метаданных при отключении, проверено временем.

Поцтеринг сказал btrfs, значит btrfs. Глобально и надёжно.

Торренты ведь умеют преалоцировать место под скачиваемое. По меньшей мере в теории можно полностью исключить фрагментацию при скачивании торрентов

Но мы отклонились от темы. Кто-то тут грозился рассказать как копаться в кэше bcache. t184256

P.S. у тебя btrfs от фрагментации именно разваливается, или просто деградирует производительность? Первое как-то маловероятно звучит

А зачем? Я заодно и каждый раз окружение менял...

По-разному. Если без autodefrag то тупо деградирует, если с ним - дохнет (хз чего, отваливается в ro), если добавить nodatacow то штабильно, но уныло.

Так, стоп, ты Btrfs на HDD планируешь ставить? На SSD оно не тормозит даже от деградации (нутыпонил), разве что при записи очень жирного куска данных.

А торренты без преаллокации на HDD — это 146% фрагментация → тормоза.