Для включения в будущее ядро 6.17 предложены оптимизации и новые возможности, повышающие производительность Btrfs:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63630
Хорошая ФС
Хорош пока не потерял данные.
До первого отключения света
> До первого отключения светаУ меня он пережил 1000 целенаправленных дергов питания при тестах. Это уже достаточно "отключений света", или где?
Достаточно одного во время важной операции, а не теста
> Достаточно одного во время важной операции, а не тестаУ меня как-то слетало питание - при конверсии схемы RAID. Это достаточно важная операция?
Оно после ребута - без проблем продолжило конверсию. Прекрасно живя с смесью уровней RAID в процессе. Устроено оно так, что ему пофиг. А cow обеспечивает недеструктивность таких операций.
RAID не показатель, он для того и нужен, чтоб страховать косяки
> RAID не показатель, он для того и нужен, чтоб страховать косякиКонверсия типа страйпинга RAID - такая весьма отдельная операция. И последнее что вы бы хотели - чтобы при чем-то таком слетело питание. Потому что операция длинная, а классический RAID при таком - если это вообще можно - вероятно будет угроблен совсем. В btrfs оно просто сильно иначе устроено на эту тему и недеструктивное/относительно безопасное и на отлично с смесью уровней живет.
Отключение света не страшно btrfs, если ты сам не отключишь cow, тогда да могут быть последствия, но тут уж ты ссзб.
> Отключение света не страшно btrfs, если ты сам не отключишь cow, тогда
> да могут быть последствия, но тут уж ты ссзб.Тут еще от гунявости накопителя зависит. Совсем похабные SSD с горбатым FTL - могут грубо пролюбить огроменную чушку - мега на 32 - при слете питания. Это в общем то запроектная авария для любой ФС - и там что угодно в принципе бывает. При том с любыми ФС. Если в каком NTFS у вас 32 мега под MFT профакается - вам тоже мало не покажется.
ну про 32 мега ты загнул, обычно пролюбливается 1 блокчтобы столько пролюбить это надо рейд без батарейки, было у меня такое, кеш не зафлашился, побились корни - не спас BTRFS
а второй раз глюканула из-за кривых DKMS модулей, намертво завис - только power off, zero log пришлось запустить, все хорошо пашет до сих пор
в общем падает она от питания, очень редко, но падает, с другими фс такое не особо замечал, реже, сильно реже
NTFS тоже умирал при аппаратных глюках, из-за разогнанного кирпича в частности, но никогда из-за питания
> ну про 32 мега ты загнул, обычно пролюбливается 1 блокЭто размер одного Erase Group. В SSD прицеплено N * чипов NAND, для скорости операций контроллер с ними параллельно работает. Ну а NAND стереть можно - только здоровенным Erase Block по нескольку мегов. Erase Group = N * EraseBlock, и стирание происходит такими юнитами. Оно же и юнит кантования по крупному всяких дел FTL-а. И оно какого-то вот такого размера и может пролюбиться при worst case, если фирмвара накопителя потерю питания нормально не обыгрывает.
И да, так в труху может уделаться - что угодно в принципе.
> чтобы столько пролюбить это надо рейд без батарейки, было у меня такое,
> кеш не зафлашился, побились корни - не спас BTRFSЭто всего лишь - обычный SSDшник так может приколоться. Точнее - поганенький, где FTL достаточно индусский. С другой стороны а откуда вы то знаете насколько он похабный у вашего SSD? Косяки даже у жирных энтерпрайз моделей к тому же бывают.
> а второй раз глюканула из-за кривых DKMS модулей, намертво завис -
Ну вот там мог и RAM побиться. Нвидия таким манерам разнесла юзерам немало файлух. Юзеры EXT4 и XFS сперва вообще не догоняли - почему на них "рояль с неба внезапно упал".
> в общем падает она от питания, очень редко, но падает, с другими
> фс такое не особо замечал, реже, сильно режеЧто-то таков возможно только с очень кривыми накомителями, делающими то что вон там выше. Но на них и другие ФС таки - выносит. Ибо пролюбить чушку в 32 метра или сколько там у кого, под служебными структурами - весьма такое себе.
> NTFS тоже умирал при аппаратных глюках, из-за разогнанного кирпича в частности, но
> никогда из-за питанияЯ выуживал данные из нескольких трупиков оного по линии кривой RAM. Подстава в том что "вчера все збс было - а сегодня в бсод комп уносит". Да, и соседний комп с виндой - тоже. У майкрософт такой качественный драйвер что некоторые крахи от кривых метаданных в нем с винтукея до десятки живут ажно.
Лучшая ФС. Использую дома с 2016 года.
сочувствую. btrfs тупо жрёт место непонятно куда
Примерно 5% под метаданные, какой ужас
А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS?
> А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS?Это все на самом деле очень зависит от характера использования ФС. Но в среднем по больнице разница обычно минимальна. Это не значит что так же будет в всяких эзотеритических случаях, разумеется.
Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок, плюс хвосты/слэк конечно же. USN журнал - по вкусу, кому как, за умолчания не в курсе. При компрессии write amplification жестокий, что для ФС 80-х годов прошлого столетия как бы ожидаемо.
> Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок,Миллион файлов. Хы-хы. Этот антиквариат от 300К файлов в 1 дире - становится неюзабельным нахрен. А теперь берем сабжа, кладем 300К файлов в диру там. Ну и вот сравниваем side by side у кого там какой перфоманс операций, и вообще.
Неюзабельность там в другом: для проверки или дефрагментации тома вся MFT и прочие мапы грузятся в RAM целиком, то есть большие или определённым образом повреждённые тома могут оказаться непроверяемыми на железе в наличии.
https://www.opennet.me/openforum/vsluhforumID3/137435.html#94Есть такая информвция с Windows, достоверность не проверял:
"Для NTFS без включённого сжатия в реальных сценариях получается примерно так:
• При последовательной (большой) записи:
– Фактически записывается на 10…20 % больше, чем вы отдаёте «на выход» (коэффициент ~1,1–1,2).
• При случайной записи мелкими блоками (несколько КБ и меньше):
– Дополнительные операции с MFT, журналом, bitmap’ами и т. д. могут дать усиление до 1,5–2,0.Итоговые «усреднённые» цифры для NTFS без сжатия:
• Большие файлы (последовательные потоки) → write amplification ≈1,1–1,2
• Мелкие файлы или случайный I/O → write amplification ≈1,3–1,7
• В пиковых, крайне фрагментированных сценариях или при очень мелком I/O рост может достигать ≈2,0"
"В NTFS сжатие касается только потока данных самого файла (Data-составляющей). Вся служебная «обвязка» — MFT-записи, журнал транзакций (USN-журнал), битмапы свободных кластеров, индексы каталогов и пр. — остаётся несжатой"C включённым в BTRFS сжатием "по умолчанию в Btrfs поведение очень похоже.
• «compress=…» (lzo/zstd/zlib) на монтировании влияет только на данные (Data-chunk-и).
• Метаданные (B-деревья, extent-записи, bitmaps и т. п.) по умолчанию не сжимаются и пишутся «как есть».Если вы пропишете в /etc/fstab или в команде mount опцию
compress=zstd:1
— это затронет только потоки пользовательских данных. Метаданные будут занимать столько же места, сколько и без сжатия.Важно: в ядре есть экспериментальная опция compress-metadata, которая пытается сжимать часть метаданных, но она считается нестабильной и в большинстве дистрибутивов по умолчанию не включена. На практике:
Подавляющее большинство «обычных» метаданных Btrfs не сжимается.
Сжатие «Data» уменьшит лишь объём пользовательских данных, но не снимет оверхед на COW-алокацию метаданных и чанков"
А ZFS? Это вы сами выясняйте как работает ZFS кому надо.
Не 5%, меньше:# btrfs filesystem df /
Data, single: total=39.01GiB, used=32.09GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=2.00GiB, used=1.02GiB
GlobalReserve, single: total=68.52MiB, used=0.00B
Какой маленький раздел, милота =)❯ btrfs filesystem df /
Data, single: total=469.01GiB, used=413.49GiB
System, DUP: total=64.00MiB, used=80.00KiB
Metadata, DUP: total=7.00GiB, used=4.14GiB
GlobalReserve, single: total=512.00MiB, used=0.00B❯ btrfs filesystem df /media/shmurdyak
Data, single: total=1.63TiB, used=1.35TiB
System, DUP: total=64.00MiB, used=272.00KiB
Metadata, DUP: total=5.00GiB, used=2.25GiB
GlobalReserve, single: total=512.00MiB, used=0.00BКороче, понты оно жрёт на самом деле.
https://www.opennet.me/openforum/vsluhforumID3/137411.html#264 Включение сжатия в BTRFS уменьшает размер записываемых данных, насколько я не знаю.
> https://www.opennet.me/openforum/vsluhforumID3/137411.html#264 Включение сжатия
> в BTRFS уменьшает размер записываемых данных, насколько я не знаю.Насколько сожмутся - настолько и уменьшает, от данных и алго сжатия зависит. Это ессно похуже чем архиватором - блоки мельче для рандомного доступа, что несколько ухучшает сжатие. Зато распаковка - на лету, прозрачно, незаметно.
"Нет, к сожалению, дело не в том, что включив сжатие, вы «срежете» весь 3–4 MiB оверхед в 2–4 раза. Сжатие влияет только на объём данных, которые вы помещаете в блоки «Data», но:Метаданные (B-деревья, extent-записи и т. п.) по-прежнему пишутся целиком в своём размере
Минимальные аллокации пулов (chunk-групп) тоже не «не сожмётся» — они резервируют своё место заранее
DUP-дублирование метаданных остаётся в силеИтого:
– Пользовательские 4 KiB при CR=4× превратятся в ~1 KiB «Data», т.е. пишем на диск в 4 раза меньше пользовательских данных
– Но сверху «накладные» метаданные и аллокации (скажем, 50–100 KiB при COW-операции + ещё дублирование) никуда не денутсяПример грубых чисел для одной маленькой операции:
• Без сжатия:
– пользовательских 4 KiB → пишем 4 KiB Data
– метаданных COW, B-деревьев и т. д. → ~60 KiB
→ ~64 KiB реальных записей• С компрессией CR=4×:
– пользовательских 4 KiB → пишем ~1 KiB Data
– метаданных всё те же ~60 KiB
→ ~61 KiB реальных записейПолучается, что общий write-amplification упал не в 4 раза, а лишь на долю, соответствующую тому, как сильно вы сжали сами данные. При большом CR (текст, логи) экономия на «Data» будет существеннее, но «метаданные + аллокации» всегда будут давать заметный базовый оверхед.
Вывод:
– Сжатие в Btrfs позволит вам уменьшить объём записываемых пользовательских данных в CR раз, но write-amplification совсем не «умножится» на обратный коэффициент сжатия.
– Наоборот, доля неизбежных метаданных при маленьких операциях делает эффект сжатия на общую запись довольно скромным."
Проверяйте кому надо, я сам не проверял. 3–4 MiB взято отсюда: "Вот почему при записи нескольких KiB вы можете увидеть на диске «отдачу» в мегабайты:Copy-on-Write.
– Любое изменение (новый файл или модификация уже существующего) требует аллокации новых блоков и записи обновлённых метаданных (B-деревьев, битмапов, extent-записей).
– Даже если вы пишете 4 KiB, под «новые» метаданные выделится целая страница B-дерева (обычно 16–64 KiB), плюс придётся перекопировать (и записать заново) узлы дерева вверх до корня.
Групповая аллокация (block-groups).
– Btrfs резервирует «пулы» под данные и под метаданные: по умолчанию для метаданных это группы по 32 MiB, для данных — по 1 GiB.
– При первом COW-запросе в новом пуле он «открывается», выравнивается по 1–2 MiB и помечается как «занятый», даже если вы в итоге записали только 4 KiB.
Дублирование метаданных (DUP).
– Системные и метаданные (B-деревья) по умолчанию хранятся в режиме DUP, то есть каждый блок пишется дважды в пределах одного устройства для повышения надёжности.
– Это ещё +100% к тому, что уже написано.Суммарно получается:
• Metadata CoW (несколько десятков KiB)
• Аллокация блока на 1–2 MiB (минимальный «шаг» пулов)
• Дублирование (×2)
→ «Вытекает» примерно 3–4 MiB реальных операций записи на диск даже при чистых 4–8 KiB пользовательских данных"
> Вывод:
> – Сжатие в Btrfs позволит вам уменьшить объём записываемых пользовательских данных
> в CR раз, но write-amplification совсем не «умножится» на обратный коэффициент
> сжатия.
> – Наоборот, доля неизбежных метаданных при маленьких операциях делает эффект сжатия
> на общую запись довольно скромным."Я не знаю что это за вода - но реально...
1) Мелкие файлы вообще могут уйти - в metadata. Сразу инлайном. Это быстрее и компактнее.
2) Сжатие кроме всего прочего повышает вероятность что файло уместится in-place.
3) Write amplification - очень зависит от сценария, и в многих сценариях btrfs мало чем хуже остальных, и параметры таковы что паритсья об этом просто незачем. Это может волновать всяких нагруженных БД пишущих кучу мелких блоков, с синхронизацией, но на таком cow делать - вообще "не очень" на уровне идеи. А если у меня прогноз протирания SSD - через 150 лет - да мне и его протирание через 75, в принципе, один хрен, по большому то счету.
4) В зависимости от накопителя скорость чтения может и улучшится - на тормозных накопителях.
5) А места займет - таки меньше. Удобно каким LZO или ZSTD допустим систему компресануть. Бинари раза в 2-3 жмутся, меньше места жрет, в том числе и как снапшоты и проч.
Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла), то есть такой момент, там понятно куда, но пока не исправлено.
Что пока не исправлено? Ваше знание обсуждаемого предмета?
> Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла),
> то есть такой момент, там понятно куда, но пока не исправлено.О чем вы там? В более-менее свежих ядрах там все известные случаи - устранены. И в целом оно - just works.
Единственное что юзать это лучше с новыми ядрами, хотя-бы 6.x. Оно почти никогда не регрессует ибо девы трезво оценивают что делают - а вот известные проблемы и "особенности" чинят довольно активно.
>> Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла),
>> то есть такой момент, там понятно куда, но пока не исправлено.
> О чем вы там? В более-менее свежих ядрах там все известные случаи
> - устранены. И в целом оно - just works.
> Единственное что юзать это лучше с новыми ядрами, хотя-бы 6.x. Оно почти
> никогда не регрессует ибо девы трезво оценивают что делают - а
> вот известные проблемы и "особенности" чинят довольно активно.Свободное место может утекать при перезаписи частей файла. Долго объяснять, сделай файл размером в 1000 МБ, в середину запиши 100 мег, общее место используемое им с большой вероятностью окажется 1100, или точно больше 1000. Причём увидишь это только по уменьшению свободного на разделе, а никак не по самому файлу.
> Свободное место может утекать при перезаписи частей файла. Долго объяснять,Нет уж, вот извольте.
> сделай файл размером в 1000 МБ, в середину запиши 100 мег, общее место используемое им
> с большой вероятностью окажется 1100,С хрена ли? То-есть, если посмотреть вот прям сей момент - может быть и так. Ибо CoW запишет 100 мегов в сторонку (кроме случая когда файл помечен как nocow), а деаллокация случится - не сразу. Но. Есть такая штука - GC. Он подгребает неиспользуемые блоки. Либо в фоне, либо "когда приперло". И через некоторое время он на отличненько почистит те 100 мегов в середине как свободные. И они будут доступны для использования чем-то еще.
> или точно больше 1000. Причём увидишь это только по уменьшению свободного
> на разделе, а никак не по самому файлу.В силу логики работы CoW и аллокации в btrfs цифря свободного места - на самом деле достаточно приблизительная.
Свободное место на фс вообще - довольно абстрактное понятие. Представляете, можно выжрать все место в файловой системе (почти любой, кроме самых ограниченных) - забив ее файлами нулевого размера. Суммарный размер файлов будет - ноль! Но место куда-то денется. В этом месте мы узнаем о метаданных и что они тоже - место занимают, оказывается.
> сочувствую. btrfs тупо жрёт место непонятно кудаПонаделал снапшотов и забыл стереть? У н00бов с виртуалками тоже такое бывает :)
Просто придут те кто потерял данные из-за сбоев btrfs и тебе наваляют.
>"и тебе наваляют. "А зачем вы свои комплексы на всех проецируете?
>А зачем вы свои комплексы на всех проецируете?Чтов эти "Все" не теряли свои данные из за твоих росказней про надежность бэтера.
> Чтов эти "Все" не теряли свои данные из за твоих росказней про
> надежность бэтера.Я вот юзаю btrfs уже дофига, в куче конфиг - и ничего не потерял. А сказочники мне - надоели. Модеры, нельзя ли их отсюда - убрать? Пусть где-нибудь еще упражняются в свеой культуре уровня гопника.
Ошибка выжившего. Здесь все - 4% истинных линуксоидов - говорят, что ext4 сверхнадежна и "уронить" её очень сложно. А у меня при копировании с NAS на диск с "неубиваемой" ext4 появилась "ошибка копирования" и диск перестал определяться. После всех проверок в Linux выяснилось, что суперблок затерт, резервные блоки не существуют, но теперь уже с ntfs этот диск работает и ошибок нет.
Так что там с надёжностью?
Ntfs может долго на посыпавшемся диске работать. Не очень хорошо, правда. Btrfs в случаях неисправного оборудования статистически лучше.
> Ntfs может долго на посыпавшемся диске работатьТолько при каждом подключении выдаёт сообщение, что диск надо бы и проверить..
> Только при каждом подключении выдаёт сообщение, что диск надо бы и проверить..При том если на это еще и удумать согласиться - то это как раз его порой и добивает окончательно в вон том случае.
> Ntfs может долго на посыпавшемся диске работать. Не очень хорошо, правда.Ну да, только он постепенно деградирует а в какой-то момент - хлобысь - не монтируется - и внутри уже везде труха! И даже если что и удастся оттуда отковырять - то основательно попорченое к этому моменту. Ибо в таком режиме оно могло делать хзчто довольно долго.
> Btrfs в случаях неисправного оборудования статистически лучше.
Он по крайней мере орать начинает на csum error и проблему можно заметить на подлете. А не когда том уже загажен в вермишель и там живого места нет.
> Ошибка выжившего.И у всего миллиарда юзерей FB - тоже? И у кастомеров оракла который эту штуку в Unbreakable сватает? Да черт, даже редхат опять стал заигрывать с оным, в федору не только напихали но и дефолтом по моему уже сделали. Правда поздняк, от редхата все адекватные спецы блочно-файлушного уровня с их XFS франкенштейном - свинтили. И теперь вокруг btrfs отвисают чего-то. Даже бывший майнтайнер XFS, задолбаный ботами гугла с CVE в коде "от дидов" (XFSv4) :D.
Вообще, я лучше буду - выжившим. А тот дымящийся скелет потрогавший провод - экспериенс, таки, не накопил - по техническим причинам. Выжившим быть - прикольнее.
> Здесь все - 4% истинных линуксоидов - говорят, что ext4 сверхнадежна
> и "уронить" её очень сложно.Совсем ее разломать, до уровня когда и fsck обделается и правда - требует неких усилий. Но ничто не есть мировая константа. И это знание тоже.
Сторажи стали - быстрее, емче, дешевле, и... гораздо хлипче! Потоки данных увеличились. Соотношения - изменились. То что было надежным вчера - сегодня реплэит на протертом SSD журнал с трухой, а fsck получив ЭТО - завершает cccombo-breaker, делая тому окончательное фаталити. Так что оно потом не монтируется, не чинится, и даже датарек с ЭТИМ - конкретно задолбается. Автыры EXT4 чешут репу, пилят CRC журналу. Даже если это и сажает скорость - вермишель вместо фс еще хуже. Чуть позже оказывается что и вермишель выданная SSD как метаданные - ведет к тому же результату. Автыри чешут репу еще раз. И начинают пилить чексуммы и для метаданных. И вот ... простая, быстрая ФС. Или таки - уже нет?
И XFS следовало примерно тем же маршрутом. Они правда сову на глобус чуть лучше смогли и там чексумы вроде - даже и данным перепали таки. И даже рефлинки каким-то чудом. Но снапшоты в норм виде, нормальный менеджмент девайсов, пространства, схем RAID и проч от этого же не появится. Так что получилось - ни два ни полтора какое-то. Сложность уже почти как у btrfs, а фич почти как у EXT4. Зачем такое надо только RH и знает.
> А у меня при копировании с NAS на диск с "неубиваемой" ext4 появилась "ошибка
> копирования" и диск перестал определяться.Если диск перестал определяться - больше всего ЭТО похоже на проблему или кончину, пардон, накопителя. По линии фирмвары или его общего физического состояния. От этого никакая фс вообще не помогает, внезапно! Ну нет, если там RAID - как в btrfs/zfs/etc - тогда накопитель заменить - и порядочек.
> После всех проверок в Linux выяснилось, что суперблок затерт, резервные
> блоки не существуют,Сие как-то достаточно необычно. И похоже на сбой железа.
> но теперь уже с ntfs этот диск работает и ошибок нет.
Но я так то видел и битые NTFSы. Самые разные. Например немоунтабельный экспонат выносящий в BSOD все от винтукея до десятки. Наимный юзер принес его на соседний комп - а тот тоже в бсод хрясь. Юзер в панике - а как данные то вынуть? NTFS3G таки - прожевал более-менее (а если б он и брякнулся, оно в usermode ж было).
Не знаю, где ты ее "Дофига" используешь, но я два раза для теста пробовал ее под фс для портеджей. Оба раза заметное на глаз проседание по скорти относиттельно ext4 и отсутствие возможности смонтировать череез 3 месяца. Ядра естественнно последние. С ext4 проблем не было ни когда.
По этому, я в целом за то, чтоб вы тестировали бэтера, даже в продакене. Но не надо заливать шлак в неокрепшие умы.
> Не знаю, где ты ее "Дофига" используешь,Много где. В разнообразных сценариях. От флешек до серверов. Ничего, живое.
> но я два раза для теста пробовал ее под фс для портеджей. Оба раза
> заметное на глаз проседание по скорти относиттельно ext4 и отсутствие возможности
> смонтировать череез 3 месяца. Ядра естественнно последние.А вот уверенности в стабильности работы системы - ноль. Может у вас там ядра глючные и рушат все?
Я на btrfs билды кернелей гоняю. Чартерными рейсами. И на этом вашем ext4 cp --reflink для иерархии чтобы сделать "дифференциальный" ребилд с минимальным твиком параметров под соседний выводок - не того! Рефлинк сильно быстрей полной копии, а загаживать билды для одних систем чтобы отребилдить для других мне не с руки. Рефлинки делаются быстро, места жрет только на дельту, ну а на EXT4 такое конечно невозможно.
> С ext4 проблем не было ни когда.
Без сообщений об ошибках и конкретных сведений мы говорим ни о чем. В принципе для разовых биддов EXT4 немного пошустрее.
Но весьма зависит от того что и где на самом деле. Например если в 1 дире дофига файлов - EXT4 весьма отстоен бывает. Btrfs'у же 300К файлов в 1 дире в разумных пределах похрен.
> По этому, я в целом за то, чтоб вы тестировали бэтера, даже
> в продакене.Его уже в целом миллиард хом фэйсбука оттестил так что многим и не снилось.
> Но не надо заливать шлак в неокрепшие умы.
Вот и не заливайте. Особенно касается всяких гентушников - которые часто пытаются косплеить системщиков, не умея это делать. За что потом и страдают, да еще делая глобальные выводы из своей кривизны рук. За это же гентушников не любят и в багтреках программ - вечно лезут ко всем с уникальными невоспроизводимыми багами.
>Много где. В разнообразных сценариях. От флешек до серверов. Ничего, живое.Оно ЖИВОЕ!!! Ж8[ х ]
>А вот уверенности в стабильности работы системы - ноль. Может у вас там ядра глючные и рушат все?
Я очень понимаю отсутствие у вас уверенности. Уверенность появляется когда сам собираешь ядра под все своё оборудование втч сетевое, серверное и портативное. А когда за тебя ядра убунта собирает, уверенности взяться неоткуда, а это да.
Но ты же типа "Я на btrfs билды кернелей гоняю", может намекнёшь, по доброте душевной, как бы так собрать ядро с О2, чтоб оно именно глючило, а не неработало или работало?>Например если в 1 дире дофига файлов - EXT4 весьма отстоен бывает. Btrfs'у же 300К файлов >в 1 дире в разумных пределах похрен.
Бэтер в принципе медленнее ext4, и деградирует по скорости со временем жизни ФС. Я врать не буду, по 300к файлов в один каталог не складываю(голова же не только чтоб в неё есть)
по этому могу поверить, что если в каталог ext4 без ума валить файлы, то ext4 по скорости начнёт деградировать до бэтера :)>Его уже в целом миллиард хом фэйсбука оттестил так что многим и не снилось.
Хорошо хоть мордакнига тебе докладывает о своих проблемах. :)
>За это же гентушников не любят и в багтреках программ - вечно лезут ко всем с уникальными невоспроизводимыми багами.
Ты всерьёз полагаешь, что пользователь Генту будет задавать вопросы таким как ты?! Не льсти себе! С уровня Генту, с таким же успехом можно обратиться к гадалке.
>Без сообщений об ошибках и конкретных сведений мы говорим ни о чем.
С чего ты взял, что я с тобой на эту тему консультируюсь? Конкретно та проблема исправлена примерно в ядре 6.6, но осадочек остался.
Я знакомлю людей только со своим опытом, и в отличии от тебя не пытаюсь агитировать, подписывая под себя весь мир. Уверен, что грамотные люди сделают выводы, остальные обречены на повторение ошибок.
> Оно ЖИВОЕ!!! Ж8[ х ]Дохлые накопители и ФС гораздо хуже как по мне :P
> Я очень понимаю отсутствие у вас уверенности. Уверенность появляется когда
> сам собираешь ядра под все своё оборудование втч сетевое, серверное и портативное.Внезапно, я именно это и делаю. А еще я знаю что лишь процентов 20 из тех кто ЭТО делает - реально понимают что и нафига они делают. И в ядре есть ряд опций - и взаимодействий - с которыми можно и откушать. Или которые просто плохо протестированы.
> А когда за тебя ядра убунта собирает, уверенности взяться неоткуда,
Самое плохое что в делах системных есть - это САМОуверенность. И да, через примерно 10 годиков - убунта наконец стала ставить NoHz+Full Dynticks+1000Hz так же как это делал я. Правда у меня нормальный десктопный экспериенс был на 10 лет раньше них, во. Самое стебное что изначальный конфиг базирован на них.
> Но ты же типа "Я на btrfs билды кернелей гоняю", может намекнёшь,
> по доброте душевной, как бы так собрать ядро с О2, чтоб
> оно именно глючило, а не неработало или работало?Я даже могу намекнуть что огребал в сабже баги. На ваше счастье - в RC. И поэтому вы на своем окороке их - не получите. Refactor иногда бывает refucktor'ом.
А еще в ядре много опций. Не все комбо и взаимодействия хорошо протестированы. И на этом поле можно обломаться. Я проверял. Чем конфиг дальше от майнстримового, тем вероятнее.
> Бэтер в принципе медленнее ext4,
А вы создайте 300К файлов в дире EXT4 и мы поговорим об этом еще раз. Особенно если вас такое угораздит на механике. Чтоб еще веселее - оно деаллокацию ЭТОГО не умеет. И даже если вы сотрете это - размер диры будет как с 300К файлами. И тупить будет - пока не сотрешь. Я так по приколу сравнивал side by side, btrfs лучше с 300К в дире в целом.
> и деградирует по скорости со временем жизни ФС.
EXT4 вообще-то тоже. Диры, вот, могут - раздуваться, не сдуваться, и тормозить потом. И дефрагер у ext4 не особо эффективный.
> Я врать не буду, по 300к файлов в один каталог не складываю
А вот попробуй - и расскажи как тебе ЭТО. По моему - "не очень".
> (голова же не только чтоб в неё есть)
1) Если ФС будет диктовать структуру данных ограничениями - это плохая ФС.
2) Эту структуру придумал - не я. Я ее лишь менял и перепаковывал. И там было вот так. Заодно стресстестик прикольный.> по этому могу поверить, что если в каталог ext4 без ума валить
> файлы, то ext4 по скорости начнёт деградировать до бэтера :)Оно намного хуже бтра при этом себя ведет.
> Хорошо хоть мордакнига тебе докладывает о своих проблемах. :)
Разработчики btrfs у меня на виду и более-менее честно коммуницируют что и как в их творении, в отличие от фанов [чего угодно]. Честное понимание свойств дизайна - мое все.
> Ты всерьёз полагаешь, что пользователь Генту будет задавать вопросы таким как ты?!
Я всерьез считаю что у многих гентушников ЧСВ превышает квалификацию и понимание процессов. И просто для понимания - я автор этой новости.
> Не льсти себе! С уровня Генту, с таким же успехом можно
> обратиться к гадалке.Это вы так свой уровень чтоли описали? Прикольное описание.
>>Без сообщений об ошибках и конкретных сведений мы говорим ни о чем.
> С чего ты взял, что я с тобой на эту тему консультируюсь?
> Конкретно та проблема исправлена примерно в ядре 6.6, но осадочек остался.А та - это какая? Нельзя ли поконкретнее? Я вот прям реально жирных багов - в ядрах 6.x вроде вообще особо не припоминаю. Интересно же что я пропустил. Конечно в сабже тоже чинят странные баги. И даже в EXT4. Но это обычно весьма экзотичные вещи которые при обычной эксплуатации увидеть - малореально.
> Я знакомлю людей только со своим опытом, и в отличии от тебя
> не пытаюсь агитировать, подписывая под себя весь мир.И при этом даже сообщение об ошибке в качестве пруфа что это не агитация привести не можете?
> Уверен, что грамотные люди сделают выводы, остальные обречены на повторение ошибок.
Теодор Тсо считается за достаточно грамотного? А то он вообще свой дизайн как-то уже не особо рекомендует - и тоже норовит с авторами сабжа поотвисать. И категорически отвергает идеи типа EXT5, ибо - нахрен надо. Это отработанный материал - а не дизайн фс. Теодор в отличие от фанатов марки - в курсе и честен с нами. А кто такой Тсо - фанаты EXT4 должны бы знать.
Лучшая из имеющегося.
Хуже придумать трудно.
Твои фантазии никому не интересны.
>Лучшая ФС. Использую дома с 2016 года.С 2016 года сколько ты данных понерял? Только честно.
Чем фолианты от hugepages отличаются?
https://lwn.net/Articles/937239/
> Чем фолианты от hugepages отличаются?Вообще совсем другая ипостась.
Hugepage - страница памяти более чем традиционные 4кб. Теоретически, снижает нагрузку на трансляцию адресов и paging (TLB и проч). Практически - это не халявный маневр. Ибо если используется не весь объем такой страницы - окей, RAM теряется вникуда, потери RAM от фрагментации возникают.
Folio - совсем другая ипостась. Традиционно ФС ковыряли данные блоком по 4 кило - одна страница. Это же причина любить по дефолту 4 кило блоки в фс. Это все неплохо работало, и весь обвес апей и проч был построен вокруг этого. Но с пришествием сверхскоростного IO вдруг оказалось что ковырять потоки в многие гигабайты в секунду по 4 кило за присест вызывает дофига оверхеда. Поэтому ряд API были отрефакторены, чтобы работать сразу с "подшивкой" страниц, когда вместо 1 страницы вон те апя ворочают сразу "folio" из эн страниц. С пропорциональным снижением оверхеда на это все - ибо за присест ворочается не кусочек 4 кило а более солидный кус, так что в целом меньше распасов и оверхеда.
Почти совсем готова к использованию.
Уже 8 лет.
Дай угадаю: ты фанат иксов?
> Экспериментальная
> ОжидаетсяА когда данные исчезнут или файлы станут "битыми" (привет, ext4), разработчики разведут руками (как всегда) и заявят, что "в наших тестах все было нормально"..
В ext4 никогда такого не бывает.
> В ext4 никогда такого не бывает.Именно поэтому они CRC к журналу экстренно привинтили - а то на кривом железе оно могло вообще все развермишелить оказывается. А теперь - и к метаданным чего-то чексуммы привинчивать начала. И чего это они вдруг?...
А, ну да, наверное потому что ничего не теряло. А каску одевают - для красоты. И бронежилет - для антуражу. А миноискатель - чтобы шикануть. И страховку - по приколу цепляют. Ведь что может пойти не так?
> CRC к журналу экстренно привинтилиЭто для journal_async_commit, если не путаю. В остальных случаях она не обязательна. Вот с block_validity непонятно... видимо какой-то скрытый баг ищут до сих пор ;)
Серьёзно?
https://www.linux.org.ru/news/linux-general/17448413
Новость 2023 года? А сейчас какой, не подскажешь? "Существует вероятность повреждения"? Видимо, эта вероятность была пренебрежимо мала, раз за 2 года не слышно было громких историй реальных повреждений данных из-за той проблемы.
> Новость 2023 года? А сейчас какой, не подскажешь? "Существует вероятность повреждения"?
> Видимо, эта вероятность была пренебрежимо мала, раз за 2 года не
> слышно было громких историй реальных повреждений данных из-за той проблемы.Я вот лично видел юзера с внезапно сдохшим EXT4. И XFS. Такой падеж ФС был загадкой - но потом какой-то btrfs'ник спалил контору: он заметил что ор про checksum error начинается после установки нвидийского драйвера. Так ALL и узнал что подарок от нвидии - выносит RAM нахрен. Это довольно часто ведет к записи трухи в метаданные ФС. С понятным результатом. Вот только с EXT4 юзер будет ничего не подозревать до упора - чексум же нет. А когда оно заметит - fsck том как раз и доломает нахрен, ибо с таким ФС не живут.
Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4 очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс, что открытый на запись файл будет замещён мусором.
> Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4
> очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс,
> что открытый на запись файл будет замещён мусором.У ext4 без полного журнала - файло при обрубившейся на середине записи модет влет остаться наполовину новым и наполовину старым. И конечно в большей части слуаев он вообще читаться не будет потом программами. ФС при этом конечно логически-консистентна по части трекинга аллокации места. Регионы под файлом корректно же трекаются. Так что fsck гонять не надо. А труха в файле - мало ли чего.
Это не проблема ФС. Это отсутствие fsync в приложениях. У sqlite/mysql/postgres часто базы в нечитабельном состоянии остаются? Без аппаратных ошибок в дисках такое прям редкость. Сами всё штатно находят, откатывают и т.д. и даже в режиме data=writeback.data=journal автоматически тоже не поможет держать файл всегда в адекватном состоянии: в процессе твоих изменений бахнул глобальный sync по таймеру и файло оказалось ни туда ни сюда (допустим, заголовок TLV вначале файла ты поправил, а данные в файл ещё не записал, или записал не все). ФС тут ни при чём на самом деле.
Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, второй после отключения света, да починилось быстро по гайдам из интернета, но с нтфс и виндой такого не бывало, уже страшно за свои данные, планирую переезжать на что нибудь журналируемое типа ext4 или xfs, смысл от снапшотов для починки системы на том же диске, если вся фс сломалась и не может быть примонтирована.
Ntfs не менее успешно корёжит и теряет файлы, но главное фрагментация ни в какие ворота.
Лет 8 на этой фс все устройства. Сломалось ровно один раз, когда из raid 1 диск наживую вытащили. Вырубил машину, воткнул обратно диск, включил, пошуршало 15 минут и всё на своих местах, всё работает.
Смотря как часто из розетки дёргать. И никаких ntfs3g или более старых версий венды. Ну и повреждения будут тихими, она ничего не сообщает. А в целом, у нтфс очень низкая производительность при работе с кучей файлов, не просто так ресурсы бандлят.
Ты тролль и сидишь на Винде, нет у тебя никакого btrfs.
Постоянные отключения света были полгода, ни одного падения фс. Знаете что я дела не так? Я сижу на Debian stable с LTS ядром и не парюсь что у меня "устаревшее" (новое я в chroot|flatpak|distrobox поставлю).
Вот тут https://www.linux.org.ru/news/linux-general/17448413 как раз о "сверхнадежной" ext4 в Debian Stable.. 😆
Новость 2023 года? А сейчас какой, не подскажешь? "Существует вероятность повреждения"? Видимо, эта вероятность была пренебрежимо мала, раз за 2 года не слышно было громких историй реальных повреждений данных из-за той проблемы.
> Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, второй после отключения светаИ ведь до сих пор попадаются люди, которые для !рабочей станции! не могут даже бесперебойник купить.
А можешь посоветовать хороший бесперебойник? Чтобы работал хорошо, и не сильно дорогой. Я вот недавно пробовал купить. И судя по отзывам, они все проблемные. В числе проблем, на которые жалуются люди:
- ИБП просто не выполняет свою функцию, то есть сразу же отключается сам, когда отключается свет. И это модели за 80 евро.
- При длительном отключении света и полной разрядке батареи - не включается сам, когда свет таки подают вновь.
- Сильно воняет, при чём долго, не только первую неделю.
- Мощные модели шумят и греются, даже если есть свет. Маломощных моделей не хватает на современный ПК + монитор.
- Неприятно пикает раз в несколько минут, при работающей розетке, и это невозможно отключить.
- Если ночью отключается свет - орёт так, что будит всех домочадцев, даже если ПК, подключенный через ИБП, выключен.
- Даже у дорогих моделей за 200 евро через 2 года сдыхает батарея.
Как там bcache? Еще не выкинули?
> Как там bcache? Еще не выкинули?Пока еще - на месте. А что будет в 6.17 - пока интрига. Что называется, следите за новостями.
Btrfs дефолтная ФС у Федоры, с версии 33. А это значит, что Btrfs станет дефолтной и в RHEL.
В шапке btrfs уже была в preview, но убрали в пользу XFS. Видимо, они что-то знали.
Была, 10 лет назад. Сейчас многое поменялось.
> В шапке btrfs уже была в preview, но убрали в пользу XFS.А заодно убрали у себя и всех блочно-файлушников - все известные имена из RHBM таки свалили. И скучковались - вот - вокруг btrfs'а почему-то.
Видимо непотребства с сратисом и попытка гальванизации древнего дизайна с потугами сделать из пенсионера чемпиона-олимпийца им как-то не того. Чексумы и рефлинки даже кой-как прикрутили, вроде бы, но я так и не понял - можно ли это уже юзать, или оно как всегда wip и экспериментальное у них. Но даже нубоватый майнтайнер с горящими глазами - в процессе успел задолбаться с легасипроблем этого антика в край - и сбежал, тоже к btrfs'никам вроде.
> Видимо, они что-то знали.
Ага, как что-нибудь еще профачить. Например блочно-файлушное направление у себя. У IBM славные традиции факапов и пролетов, еще с полуоси аж :)
Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы.
> Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы.Остальные вообще предложили на выбор покушать песок, гравий и пенопласт.
Надо было использовать ext4.
> Надо было использовать ext4.Да сами свой пенопласт не умеющий в деаллокацию дир и педальный как черти что жрите. В btrfs можно - подоткнуть энный диск -> btrfs device add -> +N места. С EXT4 так расширить себе место для хранения? Ну не то что совсем невозможно - но вы врядли захотите связываться с этим. А уж чтобы снапшот ос до апгрейда забахать на случай если результат не понравится - опять же, аналогично. Только еще поганее.
Судя по текущим бенчмаркам, это вряд ли
https://www.phoronix.com/review/linux-611-filesystems/3
Пока что XFS для типичной серверной нагрузки (СУБД) выглядит предпочтительней.
> Судя по текущим бенчмаркам, это вряд ли
> https://www.phoronix.com/review/linux-611-filesystems/3
> Пока что XFS для типичной серверной нагрузки (СУБД) выглядит предпочтительней.Ну вот под именно нагруженные базы данных CoW (по крайней мере без nocow) может и правда быть не лучшим выбором. Но это лишь 1 из кейсов, довольно нишевой.
Btrfs -- это ZFS лайт!
Аксиома Эскобара (с).
>Btrfs -- это ZFS Next!Пофиксил. Не благодари.
RAID 6 починили?
Это фс для моды, а не для работы. Ты что.
Лучшая ФС для RAID5.
Или нет?
Кто шарит, какие преимущества? Всю жизнь на ext4, но с этими бтрфс/бкачфс все так носятся, а в чем реальные преимущества то?
Или это не для десктопа штуки, а для каких нибудь серверов?
В btrfs - подтома, снэпшоты, cow, сжатие. Пользуюсь именно на десктопе, удобно
Поддерживаю эту нейросеть. Тоже всегда сидел на ext4, но потом попробовал btrfs и протащился именно со снапшотов - пару раз спасали (не от помирания системы, а от удаления файлов). Потом уже сильно позже включил сжатие, на 5950Х даже если захотеть не заметишь, зато побольше можно в один диск упихать.
Тоже давно на ext4. Считаю так - работает, устраивает? Не трогай!)
> Тоже давно на ext4. Считаю так - работает, устраивает? Не трогай!)В принципе лошади - работали же. И пахать, и почту доставлять, и в другой город съездить... зачем что-то менять, да? :)
некоторые и огород лопатой копают. вот дяревня, нет чтоб шагающий экскаватор подогнать и быренько все вскопать.
А UFS2 просто работает.