Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Автор Bcachefs констатировал снижение числа выявляемых ошибок на 40%"	+/–
Сообщение от opennews (??), 04-Ноя-24, 12:19
Кент Оверстрит (Kent Overstreet), разработчик ФС Bcachefs, сообщил о снижении числа всплывающих при использовании тестового инструментария ошибок на 40%  по сравнению с прошлым месяцем, а также о кардинальном уменьшении числа сообщений о критических проблемах. В результате проделанной работы, общее качество кода повысилось и поток ошибок пошёл на убыль. Тестовый робот Syzbot выловил большую часть тривиальных ошибок вида "упс, мы забыли проверить это" и теперь находит в основном реально редкие и интересные ситуации... Подробнее: https://www.opennet.me/opennews/art.shtml?num=62169
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+11 +/–
Сообщение от Аноним (1), 04-Ноя-24, 12:19
Красава, Кент! Сразу пошел торвальдсу хвастаться
Ответить | Правка | Наверх | Cообщить модератору

	75. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 18:36
	> Красава, Кент! Сразу пошел торвальдсу хвастаться Ну а что, сам себя не похвалишь - никто не похвалит. А поработав почти 10 лет над ФС, и выкатив нечто более-менее работающее (у меня N виртуалок с этим вполне себе пашет) - почему бы и не похвастаться немного. Если в этом мире мямлить невнятную хрень - вас замнут хайпожоры. Главное чтобы баланс был между баззвордами и реальными делами. В сабже технологии достаточно продвинутые, попытка взять лучшее из других, i++'th edition. А поскольку оно появилось позже других то получило некий шанс изучить их проблемы и попробовать обойти.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от freebzzZZZzzd (ok), 04-Ноя-24, 21:47
	>bcachefs: Fix NULL ptr dereference in btree_node_iter_and_journal_peek (2024-10-29 06:34:11 -0400) выглядит безопастно (ц) и целых 4 дня назад, теперь уже точно стэйбл
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–5 +/–
	Сообщение от Аноним (127), 05-Ноя-24, 02:02
	> выглядит безопастно (ц) и целых 4 дня назад, теперь уже точно стэйбл Да вообще, на практике оно все же в целом просто работает. А на это вот нарваться - наверное можно. Но придется сделать что-то этакое. А так не ошибается тот, кто ничего не делает. В этом вашем фрибсд например - ZFS содраный с линя да - вот - своим ходом жуткий уродец ufs, с морально устаревшими технологиями ФСостроения. И из всех BSD вообще - разве что HammerFS внимания стоит. Остальное, простите, г-но. Даже по сравнению с, вот, линухом. А другой вселенной с другими реалиями у меня для вас, увы, нет.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Знатный аноним (?), 05-Ноя-24, 09:41
	>В этом вашем фрибсд например - ZFS содраный с линя да - вот - своим ходом жуткий уродец ufs, с морально устаревшими технологиями Ржём голос. В этой фразе вся суть линь-сообщества: сначала принижать то, чего нет у себя, зато как только переступили, так сразу оказывается что это они создатели всего, что есть в пингвиняшке.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от пп (?), 05-Ноя-24, 14:21
	судить по одной особи о всем сообществе это норм?, ну чем вы лучше?
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:18
	> Ржём голос. В этой фразе вся суть линь-сообщества: сначала принижать то, чего > нет у себя, зато как только переступили, так сразу оказывается что > это они создатели всего, что есть в пингвиняшке. Как говорится, у кого что болит, тот про то и говорит... 1) Я вообще не юзаю ZFS ни в каком виде. 2) Это не отменяет существование ZoL. 3) И именно оттуда BSD сейчас и тягают ZFS, независимо от того нравится вам это или нет. Вы все еще хотите поговорить про комплексы неполноценности после этого? :) И вот это - квинтэссенция вашего сообщества. Надеюсь это объясняет почему я его всерьез не воспринимаю. Ибо когда мне например потребуется помощь зала - от таких как вы я не сильно много помощи дождусь. Почему-то. А вот от тех - в линухе - вполне. Если это делать правильно.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	185. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Ананий (?), 06-Ноя-24, 09:56
	ZFS в ядро уже впилили? Или всё так же, стыдливо подгружая модульком? Не задумывался почему и откуда растут ноги у ZoL?
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 06-Ноя-24, 12:00
	> ZFS в ядро уже впилили? Или всё так же, стыдливо подгружая модульком? Ну я им и не пользуюсь ни в каком виде. Мне btrfs'а хватает и управление у него куда прикольнее. А вон те не гордые, утаскивают ошметки даже и так. Что особенно забавно. А куда они денутся с подводной лодки? У них своих програмеров вообще ни на что нет уже. Ни на дрова, ни на ФС. > Не задумывался почему и откуда растут ноги у ZoL? - Почему ноги так пахнут? - Потому что они из ж@пы растут!
	Ответить | Правка | Наверх | Cообщить модератору

3. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–18 +/–
Сообщение от Самый Лучший Гусь (?), 04-Ноя-24, 12:24
Непонятно зачем так много файловых систем в линуксе. Почему бы не взять XFS и просто всем им не пользоваться? Его хватит для большинства а тем кому не хватит будут пользоваться чем нибудь другим.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+9 +/–
	Сообщение от Аноним (4), 04-Ноя-24, 12:26
	Наверное большинство, всё-таки, как раз, тех, кому не хватило.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (5), 04-Ноя-24, 12:28
	XFS вообще не упёрся, ибо scrub'а в нём нет. Так что никаких преимуществ в ней не наблюдается.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	79. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:46
	> XFS вообще не упёрся, вместе со скрабом Исправил, не благодари. Ext4 хватает для всего.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 18:50
	>> XFS вообще не упёрся, вместе со скрабом > Исправил, не благодари. Ext4 хватает для всего. Да правильно, о том что носитель сыпался прикольнее узнать по факту в морду - когда нужное файло не прочлось. Заранее заметить надвигающуюся подставу по ору чексум в логи? Ну что вы, как можно. Поэтому вон там btrfs'ник с нвидиея спалил что эта гадость память рушит. А некоторое количество кадров с XFS и EXT4 удивленно рассматривали разнесенные фс и вопрошали "как же так? что бы это могло быть?". Такая вот разница - системные подляны как на ладони.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 19:10
	Я бы с тобой согласился если бы скраб находил и исправлял ошибки в реальном времени. Вот только существующие решения нужно запускать либо вручную, либо по таймеру С ОПРЕДЕЛЁННОЙ ПЕРИОДИЧНОСТЬЮ, и может так случиться что в промежутке между проверками твоя фс как раз и навернётся. И плацебо в виде скраба тут никак тебе не поможет.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:59
	> Я бы с тобой согласился если бы скраб находил и исправлял ошибки > в реальном времени. Чтобы рассуждать по теме - надо в ней немного разбираться. Чексумы проверяются и в реальном времени. Скраб - явный запрос пройти по ВСЕМ данным и метаданным и проверить их ВСЕ. И только. При разрушениях оперативы и нестабильном железе - ор про ошибки чексум начинается довольно быстро и это как раз дает шанс что-то сделать ДО того как оно пробьет за чексуммы, например, подгадав момет и разрушив данные еще ДО обсчета чексумм. Так что если долго в таком режиме камикадзить - может и btrfs и сабж и что там еще помереть. Но реально - те кто читает системные логи обычно успевают засечь проблему ДО того как она эскалирует. > Вот только существующие решения нужно запускать либо вручную, > либо по таймеру С ОПРЕДЕЛЁННОЙ ПЕРИОДИЧНОСТЬЮ, Булшит бинго, чексумы чекаются и при обычном IO. И даже - если избыточность есть, с исправной копии еще и чинится. Само. В рантайме. Автоматически. Без участия человека вообще. А вы можете дальше свои левые теории толкать. Только они никак не относятся к работе self heal в современных ФС. А XFS, вот, пока в этом аспекте где-то в ж.... :)
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 21:10
	> Чексумы проверяются и в реальном времени. Вот именно что только проверяются, но не исправляются. Иначе не нужен был бы скраб.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 04-Ноя-24, 22:05
	При наличии избыточности -- чинятся.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 02:23
	>> Чексумы проверяются и в реальном времени. > Вот именно что только проверяются, но не исправляются. Поразвелось тут "экспертов", не видевших технологию даже на картинке, зато имеющих ценное мнение! [3977859.721623] BTRFS error (device sdg): fixed up error at logical 10254818376 on dev /dev/sdg physical 15232844192 Да, вот так, просто при чтении с кривого носителя. Взяло и починило с нормальной копии. Потому что может. Даже на 1-дисковой конфиге такое катит (схема DUP). Так можно даже сыпучие флешки юзать, крутанув теорвер в сильно другую сторону. Ибо для проигрыша надо - чтобы не прочлось оба блока в разных смещениях. При редких сбоях... так теорвер намного прикольнее. > Иначе не нужен был бы скраб. Скраб надо чтобы пройтись по всей площади данных и метаданных. А у btrfs и bcachefs таки, вот, есть - фоновый self heal. От пользователя ничего делать не требуется вообще, если избыточность была. И это должно работать - вот так. А не всякие, бжад, fsck мануально педалируемые. А кто простите будет это все делать на серваках, эмбедовке и проч? А, никто? Значит офлайновый fsck это вообще то что должно - умереть. Ибо лишний элемент интерьера.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	112. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 04-Ноя-24, 22:06
	Обычные юзеры логи не читают.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	129. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 02:29
	> Обычные юзеры логи не читают. Тогда они идут воооон туда в лабу и отваливают круглую сумму за вытаскивание данных, если они были нужны. Судьба у них такая. И тут уж каждый сам решает как он предпочитает. Можно заметить проблему на подлете. Можно заметить ее когда она даст по морде в виде когда игнорить это уже не получается. Выбор за пользаком :)
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 05-Ноя-24, 10:27
	>  Выбор за пользаком :) Так давно выбрали уже -- виндоуз.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:26
	>>  Выбор за пользаком :) > Так давно выбрали уже -- виндоуз. Ну так хомячкам и ось^W участь - хомячья. Кому и NTFS - фс. Хотя выбрали они на самом деле уже - андроидов и эплов. И это для майкрософта все большая и большая проблема. Для IT-профи винда - неэффективная какаха с кучей подлян и мерзким вендором. Если вам такое надо - вы это и юзайте. Я это делать не буду. Мне вообще хочется увидеть в деле продвинутые системные технологии, и сабж в эту идею хорошо вписывается. p.s. и да, нескольким вон тем пользакам я таки доставал файло с их нтфс. В том числе и после того как маздайки начали в BSOD летать на попытке монтирования тома. ЧСХ - прийти на другой комп с виндой не помогает: его тоже в бсод уносит. Стабильность признак мастерства - баги в ntfs.sys местами тянутся от винтукея до десятки как минимум.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (207), 07-Ноя-24, 01:38
	Если бы эта речь была искренней, ты бы и ReFS поковырял, и VSS оценил, и мгновенный поиск за счёт MFT тоже, трезвее надо быть, и не преуменьшать любовь именно к линуксу. Аналог VSS в линуксе в мейнлайн сначала автор dattobd предлагал[1], потом Veeam со свом blkshap[2], не берут-с. Ответ на предсказуемый вопрос: чтобы на незвездолётных ФС (как ext4) не иметь недостатков LVM-снапшотов (да, diff можно класть как файл прямо на свободное место в ФС). [1] https://lwn.net/Articles/914884/ [2] https://www.opennet.me/opennews/art.shtml?num=58062
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 06:53
	> Если бы эта речь была искренней, ты бы и ReFS поковырял, Я уже не имею дел с проприетарными технологиями. Чтобы не тратить время на ненужный мне мусор. Мои юзкейсы звязаны на опенсорсность и кроссовость софта, я этим пользуюсь. Технологии майкрософт отсеиваются уже на этом. К тому же после нехилого опыта партнерства с оными у меня нет причин доверять такому апстриму. Я видел как эти господа кидают транснациональные корпорации из верха фортуны-500. Как они относятся к пользакам - я догадываюсь. > и VSS оценил, и мгновенный поиск за счёт MFT тоже, трезвее надо > быть, и не преуменьшать любовь именно к линуксу. Я видел как VSS работает. И оценил. И именно поэтому люблю btrfs'овские снапшоты. Они не ставят колом систему, в отличие от, и скорости операций сильно более приличные. Что до мгновенности, просто зайти в диру с 100К файлами на холодную на офигенном NTFS - вообще совсем не мгновенно, я проверял! Не, этот клин системы на 5 минут - точно не совпадает с моим понятием мгновенности. И когда 1 и тот же проект в лине билдуется в 2-3 раза быстрее, это тоже - аргумент. Linux сильно делает это недоразумение в файловых операциях. Позволяя ненапряжно ворочать иерархии с линухкернел размером. Я даже представить себе не возьмусь чтобы я ребилд такого размерв в винде затеял. > Аналог VSS в линуксе в мейнлайн сначала автор dattobd предлагал[1], потом Veeam > со свом blkshap[2], не берут-с. Ответ на предсказуемый вопрос: чтобы на > незвездолётных ФС (как ext4) не иметь недостатков LVM-снапшотов (да, diff можно > класть как файл прямо на свободное место в ФС). Это все прекрасно - но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (207), 07-Ноя-24, 11:01
	> но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная. Но надо! Надо считаться с тем, что половина пользователей ест ежей[1]. [1] рандомные опросы, в которых ext4+xfs занимают около 50% https://lowendspirit.com/discussion/2786/poll-which-type-of-... https://forum.endeavouros.com/t/poll-which-file-system-in-20...
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 23:45
	>> но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная. > Но надо! Надо считаться с тем, что половина пользователей ест ежей[1]. Вам надо? Прекрасно, считайтесь. А я буду - за вон те технологии. Потому что мне намного больше нравится как это все организовано. И я полагаю что хочу видеть будущее технологий этого самого как-то так. А брейнфак с RAID и прочие сратисы - ну, я не буду обо всем этом скучать. > [1] рандомные опросы, в которых ext4+xfs занимают около 50% Я про всех этих васянов и опросы - слышу впервые, от вас. Предполагается что я посчитаю это все, вместе с какой-то их i++'й васян-ос на фиг знает каком форуме за нечто авторитетное? А так про это Форд сказал что если бы он спросил что хотят его покупатели - они бы сказали что более быстрых лошадей. А я не хочу быть коннозаводчиком, я уже понял что можно - автомобили, конвейером. Такая фигня. Поэтому мне совершенно все равно что там какие-то васяны на каком-то форуме какой-то оси вещали.
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	222. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (207), 08-Ноя-24, 00:33
	> А я буду - за вон те технологии. Мы все знаем, под каждой новостью о ФС) > слышу впервые, от вас > Предполагается что я > Поэтому мне совершенно все равно > васяны > васянов Ну и самомнение. Я говорю, что не надо отрицать - ext4 и xfs пользуются. Аналог VSS бы всем пригодился изначально (лет 20 назад), когда btrfs не было. Но и сейчас многим тоже бы пригодился. Но не положено.
	Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

	223. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (223), 08-Ноя-24, 06:30
	>> А я буду - за вон те технологии. > Мы все знаем, под каждой новостью о ФС) Но вы кажется плохо представляете себе... 1) Откуда берутся новости. 2) Как разрабатывается софт и что за силы крутят шестеренки за сценой. > Ну и самомнение. Я говорю, что не надо отрицать - ext4 и xfs пользуются. И фиг бы с ними. Даже FAT пользуются. И на лошадях иногда - ездят. Не обязывает меня быть активным фанатом FAT или уметь ездить верхом. > Аналог VSS бы всем пригодился изначально (лет 20 назад), > когда btrfs не было. Но и сейчас многим тоже бы пригодился. Но не положено. Лично мне этот плач несмеяны просто похрен. Сейчас можно и сильно получше чем это.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	188. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от bergentroll (ok), 06-Ноя-24, 10:29
	Годами живу с ext4, и не припомню, чтобы ФС посыпалась. А тут, оказывается, никак без некстген-фс с регулярным чтением лога.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	191. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 12:06
	> Годами живу с ext4, и не припомню, чтобы ФС посыпалась. А тут, > оказывается, никак без некстген-фс с регулярным чтением лога. А вон там юзеры нвидии очень удивлялись когда fsck ext4 почему-то окончательно доломал им файлуху. Хотя до этого вроде все зашибись же было?! В принципе народ не понимал в чем прикол - пока какие-то btrfs'ники не заметили что ор появляется при вгрузке дров нвидии и пропалает если их снести. Можно конечно и так. Да и как вы определяли что посыпалось без чексум? На глазок чтоли? Это надежный способ для терабайтов данных то :) Не зря законы Мерфи говорят что если вам кажется что дела идут хорошо - вы просто чего-то не заметили.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 18:48
	> XFS вообще не упёрся, ибо scrub'а в нём нет. Так что никаких > преимуществ в ней не наблюдается. Более того - его там героически пытаются сделать уже лет наверное 5. Или больше. Оно уже почти вот совсем готово, вот-вот, ых, ых, ых, years++.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	6. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от ijuij (?), 04-Ноя-24, 12:30
	> зачем так много файловых систем в линуксе Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал. Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	10. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 12:39
	> Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал. И слава богу) Тут местами такие "ыксперты" попадаются, что просто ужас. > Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄 Пока ты размышляешь, он уже делает. Если у тебя получится хотя бы минимально рабочая штука то выкладывай на всеобщее о̶б̶с̶ы̶р̶а̶н̶и̶е̶ обозрение. Вдруг оно выйдет хорошим.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 17:37
	>> зачем так много файловых систем в линуксе Because we can!(C) Это то что сделало линакс грэёт энеён(С) Ж-) > Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал. Ну в принипе - да, вполне может быть. Вот зачем взрослые мужики в хоккей играют? ;) > Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄 Не-не-не - ты ни пуркуа не понял! Because we can!(C) - это про них, а не про тебя :)
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	83. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (83), 04-Ноя-24, 18:57
	> Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас > никто не слышал. Я тоже размышляю о создании файловой системы, используя > все лучшие идеи из уже существующих. 🙄 Когда размышления трансформируются в архитектуру, структуры данных, а потом и код - тогда и приходи рассказывать нам об этом. А если твой код еще и в майнлайн Linux возьмут, и он будет сравним по фичам с сабжем, я лично запилю новость про это, пожалуй. Так же как сделал это для Кента. Но придется убить несколько лет своего времени на это, путь от теории до практики в ФС нифига не близкий. Дашборд с "на 40% меньше багов" не даст соврать! Кент мог бы сказать "мой персональный ад на 40% прохладнее, фух" :)
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	8. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+9 +/–
	Сообщение от Rev (ok), 04-Ноя-24, 12:37
	Так это же древний анекдот! - Знаешь, почему в Линуксе так много файловых систем? - Нет. - Потому, что не смогли сделать одну нормальную!
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	13. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (13), 04-Ноя-24, 12:45
	>Потому, что не смогли сделать одну нормальную Как не смогли? ZFS и ext4!
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от Аноним (22), 04-Ноя-24, 12:56
	жаль, но zfs не в линуксе сделали
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от нах. (?), 04-Ноя-24, 13:28
	Ну нынешнюю - можно считать, в линуксе. В смысле - в окружении именно линуксном, а не в смысле в прожекте линукс под руководством одного пережившего свое время менеджера. К той, сановской, она сейчас имеет очень опосредованное отношение. (и, разумеется, несовместима)
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от _ (??), 04-Ноя-24, 17:40
	>>> ... не смогли сделать одну нормальную! >> жаль, но zfs не в линуксе сделали > Ну нынешнюю - можно считать, в линуксе. Да но и нормальной еЯ считать немножко перестали :) Проклятье и благословения линукс, оно так и работает (обычно) :)
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от Аноним (83), 04-Ноя-24, 18:59
	> Да но и нормальной еЯ считать немножко перестали :) > Проклятье и благословения линукс, оно так и работает (обычно) :) Дедули, валите уже на завалинку истории вместе с вашей солярой. Ваше место - там. Особенно когда воооон тот гражданин советует заменить CRC32 -> Blake2b. То что он в 34 раза медленнее считается его вообще не смущает при продвижении инноваций.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 05-Ноя-24, 10:33
	> Дедули, валите уже на завалинку истории вместе с вашей солярой. Ваше место > - там. Особенно когда воооон тот гражданин советует заменить CRC32 -> > Blake2b. То что он в 34 раза медленнее считается его вообще > не смущает при продвижении инноваций. Это в какой ФС советуют заменить?
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:38
	>> Blake2b. То что он в 34 раза медленнее считается его вообще >> не смущает при продвижении инноваций. > Это в какой ФС советуют заменить? Это дедуля с ником _ настолько не умеет в инглиш и настолько самоуверен в своей правоте что попытался дать мне мастеркласс, да еще (лол!) закинув ссыль прямо на вику btrfs'а где по его мнению Blake2b якобы-шустрее немодного CRC32, насколько я понял его идею. Идею запулить в меня прямо ссылью с опровержением сам себя я оценил. И даже перевел дедуле что там на самом деле написано, раз инглиш он знает не лучше чем ФС и алго. После этого эксперт с тезисом про немодность CRC32 куда-то тихо слился. А я не злопамятный, но злой, и на склероз не жалуюсь. И столь забавный пируэт экспертизы опеннета я забуду не скоро :) Если хочется посмотреть на позорчик - он пытался :) умничать в https://www.opennet.me/openforum/vsluhforumID3/135159.html Только на его горе я немного кодил и CRC32 и Blake2 и представляю соотношения вычислительной сложности оных. В этом месте у "эксперта" вышел небольшой фэйл :). Мое персональное мнение: это то комьюнити которые мечущиеся между виндой и BSD заслужили. Вы теперь - ну вот это вот. Как хорошо что есть комьюнити и спецы получше ЭТОГО.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 06-Ноя-24, 05:15
	Тебе книшки писать прокурор!(С) :-) Ну блин ... ну посмотри же ты в доке - что у современных ынтырпрайз стораджей там! :) Хотя ... :)
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 07:53
	> Ну блин ... ну посмотри же ты в доке - что у современных ынтырпрайз стораджей там! :) Дедуля, что ты ко мне с своими ынтырпрайзами и банками примотался? Похрен они мне! А к тебе вообще претензия что ты в 34 раза более тормозное алго посоветовал - всем вообще, с офигенным аргументом "CRC32 не модно, и вообще blake2 быстрее". А он нифига не быстрее, и я на твое горе шарю в алгоритмике достаточно, чтобы это знать. А на энтерпрайзных файлопомойках - мир не заканчивается. И CPU и RAM в других юзкейсах - под ДРУГИЕ задачи нужны бывают. ZFSники никак не могут взять в толк столь простой момент! Кент мне интересен как раз тем что тоже - general purpose. Был бы он целиком про энтерпрайз файлопомойки, со свойствами как ZFS, мне было бы похрен что там с ним вообще. > Хотя ... :) Хотя... маневр с цитированием мне вики btrfs я оценил по достоинству :)
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Минона (ok), 04-Ноя-24, 22:13
	Не, ты тёплое с мягким не путай. Та что в линуксе это OpenZFS. А сановская ZFS продолжает жить и здравствовать в Solaris.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	130. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 02:32
	> Не, ты тёплое с мягким не путай. > Та что в линуксе это OpenZFS. > А сановская ZFS продолжает жить и здравствовать в Solaris. У вас довольно интересные понятия о жизни и здравствовании :)
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 05-Ноя-24, 10:31
	> У вас довольно интересные понятия о жизни и здравствовании :) Ты суслика видишь? -- а он есть!
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:42
	>> У вас довольно интересные понятия о жизни и здравствовании :) > Ты суслика видишь? -- а он есть! Да сами и ешьте ваших сусликов. А себе я хочу - нормальный современный менеджмент оси. Без иррациональных брейнфаков на ровном месте. Управдение сторажем в стиле btrfs/bcachefs - явно укладывается в эти пожелания. Когда можно просто добавить отфонарный девайс в RAID и не париться особо - это управление сторажем как оно должно было быть с самого начала. А вон то... я не буду скучать по этому брейнфаку. Совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Минона (ok), 06-Ноя-24, 15:22
	>>> У вас довольно интересные понятия о жизни и здравствовании :) >> Ты суслика видишь? -- а он есть! > Да сами и ешьте ваших сусликов. А себе я хочу - нормальный > современный менеджмент оси. Без иррациональных брейнфаков на ровном месте. Так нормального ты не видел. > Управдение сторажем в стиле btrfs/bcachefs - явно укладывается в эти пожелания. Когда > можно просто добавить отфонарный девайс в RAID и не париться особо > - это управление сторажем как оно должно было быть с самого > начала. А вон то... я не буду скучать по этому брейнфаку. > Совсем. У btrfs RAID 5/6 с рождения сломаны. Чем ты там управлять собрался...
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 20:05
	>> современный менеджмент оси. Без иррациональных брейнфаков на ровном месте. > Так нормального ты не видел. Сейчас бы ZFSники/BSDшники с вечными тантрами, ритуалами и более 9000 сакрального знания и иррациональных ритуалов будут учить нормальному системному менеджменту. Щазззз! Вам самим мастеркласс обломился - при том от жизни. Когда все ваши BSD повылетели нахрен из прода, systemd дополнительно объяснил господам как хотели рулить сервисами. И брейнфакообразное управление сторажами - туда же отправится. По тем же причинам. Компьютерные системы должны работать и обслуживать нужды человечества. А не делать, извиняюсь, мозги ненужным знанием, туповэйтингом и чем там еще. > У btrfs RAID 5/6 с рождения сломаны. > Чем ты там управлять собрался... Ну вот RAID1 например. Хотя RAID5 уже можно - если осторожно и понимать в чем catch. Да и в целом RAID5/6 - довольно специфичные штуки. При том в btrfs можно реально подоткнуть любой девайс который был. Без этой вашей камасутры с парными девайсами, подбором размера или потерями места, и что там у вас еще за брейнфак. А рулить вон тем вон так - ну не, это уже - прошлый век.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 07-Ноя-24, 14:06
	>>> современный менеджмент оси. Без иррациональных брейнфаков на ровном месте. >> Так нормального ты не видел. > Сейчас бы ZFSники/BSDшники с вечными тантрами, ритуалами и более 9000 сакрального знания > и иррациональных ритуалов будут учить нормальному системному менеджменту. Щазззз! Вам > самим мастеркласс обломился - при том от жизни. Когда все ваши > BSD повылетели нахрен из прода, systemd дополнительно объяснил господам как хотели > рулить сервисами. И брейнфакообразное управление сторажами - туда же отправится. По > тем же причинам. Сейчас бы локалхостеры не рассказывали нам за системный менеджмент. > Компьютерные системы должны работать и обслуживать нужды человечества. А не делать, извиняюсь, > мозги ненужным знанием, туповэйтингом и чем там еще. Ненужного знания не бывает. >> У btrfs RAID 5/6 с рождения сломаны. >> Чем ты там управлять собрался... > Ну вот RAID1 например. Хотя RAID5 уже можно - если осторожно и > понимать в чем catch. Да и в целом RAID5/6 - довольно > специфичные штуки. > При том в btrfs можно реально подоткнуть любой девайс который был. Без > этой вашей камасутры с парными девайсами, подбором размера или потерями места, > и что там у вас еще за брейнфак. А рулить вон > тем вон так - ну не, это уже - прошлый век. В RAID1 и в ZFS можно любой девайс вокнуть.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (221), 08-Ноя-24, 00:09
	> Сейчас бы локалхостеры не рассказывали нам за системный менеджмент. Сейчас бы сбитым летчикам aka "классическим" *BSD/*nix админам да за локалхосты. Локалхосты теперь - они и их практики. А я как раз умею в продвинутые современные технологии, системда, виртуализация, генерация системных образов под задачи. И "локалхостов" у меня уже изрядно. И это как раз мотивирует чтобы.. 1) Менеджмент был простым, логичным и ненапряжным. И райдов, и сервисов, и вообще - всего. 2) Системы умели в self repair единичных upsets без участия человека. 3) Была нормальная диагностируемость, а не как в окаменелом д@рьме без чексум. 4) Времена деплоя и рекавери должны быть минимальные. Это все не про тех с иррациональными ритуалами марки "мы так привыкли". > Ненужного знания не бывает. Этот мир большой и сложный, все знания невозможно вместить в 1 голову. Поэтому приходится агрессивно оптимизировать что и почему изучать. Будем честны, мне не пригодятся знания о разведении лошадей или починке тележных колес кувалдой. Поэтому лучше вгрузить какие-то более актуальные и полезные знания вместо этого. > В RAID1 и в ZFS можно любой девайс вокнуть. Только результат насколько я понимаю - другой. И вообще менеджмент в целом - ну, вон там архитект думал как сделать менеджмент простым и логичным. А вон те развели стандартную энтерпрайз канитель с неудобными допущениями и ритуалами. Этим prev и next gen технологий и отличаются, в next стараются устранить факапы prev. gen. Сабж целиком про это. Поэтому имеет некий пойнт. Чисто технически, как дизайн.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Минона (ok), 08-Ноя-24, 13:44
	>> Сейчас бы локалхостеры не рассказывали нам за системный менеджмент. > Сейчас бы сбитым летчикам aka "классическим" *BSD/*nix админам да за локалхосты. Локалхосты > теперь - они и их практики. > А я как раз умею в продвинутые современные технологии, системда, виртуализация, генерация > системных образов под задачи. И "локалхостов" у меня уже изрядно. Ты изрядно отстал от современных технологий. > И это как раз мотивирует чтобы.. > 1) Менеджмент был простым, логичным и ненапряжным. И райдов, и сервисов, и > вообще - всего. > 2) Системы умели в self repair единичных upsets без участия человека. > 3) Была нормальная диагностируемость, а не как в окаменелом д@рьме без чексум. В ZFS есть и self repair и чексумы И менеджмент куда проще возни с btrfs. > 4) Времена деплоя и рекавери должны быть минимальные. > Это все не про тех с иррациональными ритуалами марки "мы так привыкли". >> Ненужного знания не бывает. > Этот мир большой и сложный, все знания невозможно вместить в 1 голову. > Поэтому приходится агрессивно оптимизировать что и почему изучать. > Будем честны, мне не пригодятся знания о разведении лошадей или починке тележных > колес кувалдой. Поэтому лучше вгрузить какие-то более актуальные и полезные знания > вместо этого. А вот не факт что тебе это не пригодится. >> В RAID1 и в ZFS можно любой девайс вокнуть. > Только результат насколько я понимаю - другой. И вообще менеджмент в целом > - ну, вон там архитект думал как сделать менеджмент простым и > логичным. А вон те развели стандартную энтерпрайз канитель с неудобными допущениями > и ритуалами. Этим prev и next gen технологий и отличаются, в > next стараются устранить факапы prev. gen. Сабж целиком про это. Поэтому > имеет некий пойнт. Чисто технически, как дизайн. Так ты не пользовался ZFS, откуда тебе знать результат. И в дизайне ФС ты профан.
	Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

	225. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 09-Ноя-24, 07:27
	> Ты изрядно отстал от современных технологий. Вы с вашими парадигмами вообще - сбитые летчики. Слушать таких "профи" на тему как надо было - себя не уважать. Сорян но я попробую другие вещи, посмотреть не получится ли лучше. Мои технологии как раз эффективны. Их хайповость и пафосность - второй вопрос. Чисто технически я не спасую зарубиться с кем угодно по времен операций и результату. А то что я не энтерпрайз и повернут на кастоме - и что? Это не делает все это "отсталым". Особенно учитывая что многое из этого - мелочевка, а не ваши энтерпрайз-помойки с завалами корпоративного булшита, который мне - отвратителен. > В ZFS есть и self repair и чексумы В ней ни безгеморной эксплуатации (внемайнлайновый выкидыш), ни эффективных структур, без сотен рамы тормоз, ни нормального управления. Первый блин - комом. А судя по истории с рефлинками в ZoL, управление релизами - не лучше. > И менеджмент куда проще возни с btrfs. Вон там сэр уже рассказал как оно с RAID. Ну вас таких простых нахрен, я буду за "device add <whatever>" -> +N места, как в btrfs и сабже. Правильное руление фс и райдом - это так, имхо. > А вот не факт что тебе это не пригодится. В пиковом случае допустим "своп" ака подгрузка знания "as needed". Это такая оптимизация, в моей голове сидит довольно много довольно сложных технологических стеков в интересных мне направлениях. Это то что и позволяет мне обставлять господ типа вас в определенных номинациях. Я сомневаюсь что вы сможете конкурировать со мной на моих полях. В этом и пойнт, не хочу быть легкозаменимым корп винтиком, которого толи AI вынесет, толи дешевый индус. > Так ты не пользовался ZFS, откуда тебе знать результат. Я так, смотрел краем глаза, ну и вон там аноним - с RAID подтвердил мои идеи, какое там управление. И именно от такого я и хочу уйти в "device add" -> +N места. Даже в RAID. Это круто, хорошо и правильно. > И в дизайне ФС ты профан. А таки я посмотрел на то как разные ФС устроены - и почему так. И составил свое мнение о работе архитектов. В ZFS вообще половина мест "почему так" - "мы так привыкли". Будем считать что я не фанат такого rationale в архитектурах. Предпочитаю более понятные мне решения, которые облегчают мою жизню.
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	226. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 09-Ноя-24, 10:11
	> И именно от такого я и хочу уйти в "device add" -> +N места Всё продолжаешь сказки рассказывать, сказочник? :) Ну давай, собери raid1 из 2-х дисков по 10 ГБ, потом добавь к ним ещё один на 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо?
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	228. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от maximnik0 (?), 09-Ноя-24, 14:39
	>Ну давай, собери raid1 из 2-х дисков по 10 ГБ, потом добавь к ним ещё один на 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Можно, именно увеличить так объем.Но данные на 20 Гб понятно дело будет не отказоустойчивы.Это даже на офтопике можно сделать на некоторых хитрых Raid контроллерах (//в основном Intel ).Там даже одно время запатентовали 2-е гибридные диски _ часть диска в raid1 а другая часть в raid0 . Другое дело как правильно организовать данные,что и к чему присоединять ,вот вопрос, все таки очень не простая проблемная конфигурация.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	230. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 09-Ноя-24, 19:47
	Ага, а можно просто примонтировать новый диск в какую-нибудь папку и получить +полную ёмкость диска, только речь не об этом и не о преобразовании в raid0 или линейный массив, а о расширении обычного отказоустойчивого массива, будь то raid1, raid5 или  raid10. Тут товарищ доказывает (на примере raid1, который и не raid1 вовсе, а raid 1E), что можно добавить к массиву диск и получить "+N" ГБ свободного пространства. Но это ложь, расширить такой массив так, чтобы его объём увеличился на объём целого диска нельзя. В случае с "raid1" мы всегда получим половину от общего объёма дисков, да и то с оговоркой: максимальный полезный объём каждого диска в массиве будет не больше суммарной ёмкости остальных дисков (по крайней мере в с лучае с raid1, на других не проверял). Т.е., если мы к массиву raid1 из 3-х дисков по 10 ГБ добавим ещё один диск ёмкостью 50 ГБ, то ёмкость получившегося массива всё равно будет 30 ГБ ((10+10+10+30)/2), а не 40 ГБ ((10+10+10+50)/2). И уж конечно ни о каких дополнительных "+50 ГБ" тем более речи не может идти.
	Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

	234. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (234), 11-Ноя-24, 05:33
	> Можно, именно увеличить так объем.Но данные на 20 Гб понятно дело будет > не отказоустойчивы. В https://www.opennet.me/openforum/vsluhforumID3/135225.html#189 на минуточку показано... 1) Как сделать 1-дисковый btrfs. 2) Как прямо на лету добавить в эту ФС еще 2 диска. 3) Как это прямо на ходу сконвертить в RAID1. Это ессно только 1 раз надо, покуда это Single -> RAID1. Когда оно уже RAID1 - для очередного девайса только "device add" надо. И может rebalance, если остальные девайсы почти полные. 4) Проверено что в получившееся фактически лезет примерно 20 Гб при помощи dd. Вот это - менеджмент ФС как он должен был быть с самого начала. А не тот брейнфак "даже в офтопике" или что там. Прикинь, RAID1 в btrfs расширяется добавкой девайса в комп и вон тем "device add", после чего в RAID1 просто отрастает +N места. За такие свойства btrfs и сабж и считают next gen.
	Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

	235. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 11-Ноя-24, 08:26
	Всё, сдаюсь! Ты меня добил, на этот раз окончательно. Прямо-таки обескуражил. И должен признаться, виноват в этом я сам, т.к. я стал жертвой собственного воображения. Поддавшись твоим восторженным эпитетам в адрес БТРФС и рассказам об "ассиметричной аллокации", я убедил себя что приводимое тобою значение "+N" означает увеличение расширяемого массива на величину, равную полной ёмкости добавляемого диска ))) Теперь я понимаю, что это твоё "+N" означает всего-навсего "энную", или говоря по-русски -- некоторую величину. В свете этого мои пассажи про смешанные "зеркально-линейные" массивы выглядят не более чем забавным анекдотом )) Но в таком случае не очень понятно чем ты вообще гордишься. Тем что в БТРФС в принципе можно добавить диск или расширить массив? Так с mdadm и LVM при добавлении диска доступный объём тоже вроде увеличивается, а не уменьшается... Или тем что эту операцию можно проделать одной командой? Ну да, можно, только я сомневаюсь что это для кого-то может иметь значение. Или ты гордишься тем, что БТРФС умеет в raid 1Е? Но и mdadm умеет создавать массивы по такой схеме... К тому же я ведь тебе уже объяснял, что эта схема не только теряет всякий смысл при колличестве дисков более 3-х, но и с 3-мя дисками большинство предпочтёт собрать raid5 и выиграть лишнее пространство. Ты сам-то никогда не задумывался на тем, почему raid 1E сегодня практически нигде не используется? Да просто потому что он никому не нужен! )) И что остаётся? Остаётся только то, что БТРФС умеет это всё вместе: и расширять массив (чего пока не умеет ZFS, но умеет mdadm и lvm), и создавать массивы типа raid 1E (которые никому не нужны), и при этом делать это с помощью одной команды (сомнительное преимущество, которое может быть нивелировано в каких-то других моментах). И тут бы порадоваться за БТРФС, если бы она только на втором десятке лет жизни не была такой сырой и глючной ))) Подумать только: за почти 20 лет так и не двести до ума raid5/6 -- одну из важнейших функций данной файловой системы! И какой тогда толк от всех этих чудес, если часть из них никому не нужна, часть можно реализовать и с помощью других инструментов, а оставшиеся работают только на бумаге?
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	240. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 11-Ноя-24, 16:20
	> диска ))) Теперь я понимаю, что это твоё "+N" означает всего-навсего > "энную", или говоря по-русски -- некоторую величину. Именно так. Для сферического RAID1 в вакууме ожидаемый +N в идеале порядка dev_sz/2 но как вы понимаете, при "динамической" аллокации места и сильном дисбалансе возможны варианты. Собственно если говорить о минусах такой схемы (не бывает чтобы только плюсы) в такой конструкции свободное место предсказывать - значительно сложнее. > пассажи про смешанные "зеркально-линейные" массивы выглядят не более чем забавным анекдотом )) До вас дошло. Неужто посмотрели на структуру этих штук с buckets/chunks? Это иначе сделано. И не совсем RAID1 - в блочном его понимании. Но более удачного устоявшегося названия для такой структуры в природе не существует. Поэтому так. И у кента с "2 репликами" - будет примерно эквивалентная по смыслу штука. > Но в таком случае не очень понятно чем ты вообще гордишься. Удобным простым и логичным управлением этой штукой, в виде как это и должно быть. Что с RAID, что без. Просто увеличить. Просто убавить. Можно девайс добавить. И вынуть. Двигая только реально размещенный там объем. DUP тоже делается 1 командой. И можно легко grow такой ФС сделать на вооон той жирной флехе которая была крупнее образа допустим. Теперь попробуйте аналог ЭТОГО сколхозить чем-нибудь другим, а теперь еще grow этого покажите, да? Актуально для случая деплоя образа на более жирную чем образ флеху (sd/eMMC в моем случае). > операцию можно проделать одной командой? Ну да, можно, только я сомневаюсь > что это для кого-то может иметь значение. Значение для меня имеет общее сочетание - что тупых потерь "из за размера девайсов" нет или минимум возможных, и все просто и логично рулится. Можно в рантайм переиграть все параметры, жестко и мягко, вплоть до смены схемы хранения. И это относительно безопасные операции в отличие от "тупого" рестрайпа по всей площади например. > объяснял, что эта схема не только теряет всякий смысл при колличестве > дисков более 3-х, но и с 3-мя дисками большинство предпочтёт собрать > raid5 и выиграть лишнее пространство. RAID5 довольно специфичная штука, а с учетом роста емкости девайсов и ненулвеого BER это еще и довольно сыкотное комбо. Ибо что делать если "копии не сошлись"? Там же само по себе нет диагностики какой из девайсов прогнал. Как впрочем и на RAID1 классическом. Донавесить это - еще целый отдельный уровень канители. И все получается хреново, сложно и криво. Разница примерно как между настройкой IPSec и Wireguard примерно. И, конечно, для себя я второе предпочитаю. > только то, что БТРФС умеет это всё вместе: и расширять массив > (чего пока не умеет ZFS, но умеет mdadm и lvm), и > создавать массивы типа raid 1E (которые никому не нужны), Ну так я и сказал что мне его менеджмент и видится - nexg gen. И Кенту - тоже. Вон те приключения с chunk/buckets были нужны - для вот этого вот. И это имхо было хорошо и правильно. > БТРФС, если бы она только на втором десятке лет жизни не > была такой сырой и глючной ))) У меня этого btrfs'а - как у д@рака фантиков. И каких-то проблем с этого я так и не поимел, невзирая на сказ анонимусов. А когда при валидации -RC я натыкался на баги btrfs, девы были круты, эффективны и очень компетентны. Они явно знали что делали (хотя я конечно нехило помог бисектом) - и заруливали это или форвардили причастным из других подсистем с офигительной скоростью. Так что мне совершенно не на что жаловаться. И я ни разу не видел чтобы они сделали что-то столь же некомпетентное как релиз рефлинков в ZFS. > этих чудес, если часть из них никому не нужна, часть можно > реализовать и с помощью других инструментов, а оставшиеся работают только на > бумаге? Ну вон у Кента тоже Erasure Coding пока недопиленый. И чего? А реально работает - вот, механика с репликами. Т.е. примерно то что btrfs'ники обозвали RAID1. У него чуть круче ибо скрещено с кешом/фронтэндом/бэкэндом. Прикольная идея, при создании реплик свойства стоража еще учесть.
	Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

	241. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 11-Ноя-24, 20:44
	> но как вы понимаете, при "динамической" аллокации места и сильном дисбалансе возможны варианты. Не, там без вариантов. Я в ходе своих экспериментов даже формулу открыл, по которой максимальный полезный объём диска в массиве "raid1" (в понятиях btrfs) равен суммарной ёмкости всех остальных дисков )) > Это иначе сделано. И не совсем RAID1 - в блочном его понимании Так это очевидно что это не raid1, я если помнишь сразу так и сказал что это raid1 1E (или его разновидность), а не raid1. Будь это raid1, у тебя ёмкость массива была бы равна ёмкости одного диска при любом количестве дисков. > Удобным простым и логичным управлением этой штукой, в виде как это и должно быть. Что с RAID, что без. Просто увеличить. Просто убавить. Можно девайс добавить. И вынуть. Удобно, спору нет. > Значение для меня имеет общее сочетание - что тупых потерь "из за размера девайсов" нет или минимум возможных, и все просто и логично рулится. Так и с LVM нет никаких потерь (подозреваю что и на ZFS тоже), и тоже всё просто и логично рулится. > Можно в рантайм переиграть все параметры, жестко и мягко, вплоть до смены схемы хранения. А вот это уже сомнительное достоинство, ибо такие фокусы чреваты потерей данных, особенно в случае с btrfs. > RAID5 довольно специфичная штука Не более специфичная чем RAID 1E > а с учетом роста емкости девайсов и ненулвеого BER это еще и довольно сыкотное комбо С учётом того, что значения BER производители дисков берут с потолка, а у ZFS к тому же есть такая штука как draid (правда на 3-х дисках его не собрать), страхи относительно ненадёжности RAID5 сильно преувеличены. > Ибо что делать если "копии не сошлись"? А что btrfs делает в таких случаях?
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

	233. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 11-Ноя-24, 05:26
	> Всё продолжаешь сказки рассказывать, сказочник? :) Ну давай, собери raid1 из 2-х > дисков по 10 ГБ, потом добавь к ним ещё один на > 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо? У вас с математикой хреново. Из (10+10+20) при 2 копиях никак не получится 30 гигз. Но демо незнания математики продемонстрировано отлично. А на 20 таки получится. RAID1 в общем случае ополовинивает место из-за того что копий 2. Только у классической версии еще дурацкости с потерями места на разных девайсах, нуждой непременно четного количества девайсов и прочего характерного булшита в уровне менеджмента. Это и дает место дизайнам типа btrfs и сабжа, которые дадут мастеркласс фекальям мамонта как надо было.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	237. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 11-Ноя-24, 10:00
	>[оверквотинг удален] >> дисков по 10 ГБ, потом добавь к ним ещё один на >> 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо? > У вас с математикой хреново. Из (10+10+20) при 2 копиях никак не > получится 30 гигз. Но демо незнания математики продемонстрировано отлично. > А на 20 таки получится. RAID1 в общем случае ополовинивает место из-за > того что копий 2. Только у классической версии еще дурацкости с > потерями места на разных девайсах, нуждой непременно четного количества девайсов и > прочего характерного булшита в уровне менеджмента. Это и дает место дизайнам > типа btrfs и сабжа, которые дадут мастеркласс фекальям мамонта как надо > было. У тебя с математикой тоже туго. Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных. ЗЫ: И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов?
	Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

	238. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 11-Ноя-24, 15:50
	> У тебя с математикой тоже туго. > Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных. Btrfs таки - запишет. "В среднем" будут копии на 20 + 50/50 на 10-х в пару им. Реально это ессно гибкая динамическая аллокация места RAID на дисках, оно работает и для других соотношений. В отличие от вашего брейнфака с мапингом 1:1! Я вон там показал, прям с командами - на такое комбо реально втолкалось около 20 гиг, ибо я предпочитаю не тестировать безглючность показометров а фактически затестить полученное. > ЗЫ: > И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов? Смотря что понимать под "непременно" и "требуется". В degraded то режиме он и с 1 диском зацепится, только это уже не RAID1 как таковой будет.
	Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

	242. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 12-Ноя-24, 09:23
	>> У тебя с математикой тоже туго. >> Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных. > Btrfs таки - запишет. "В среднем" будут копии на 20 + 50/50 > на 10-х в пару им. Реально это ессно гибкая динамическая аллокация > места RAID на дисках, оно работает и для других соотношений. В > отличие от вашего брейнфака с мапингом 1:1! Я вон там показал, > прям с командами - на такое комбо реально втолкалось около 20 > гиг, ибо я предпочитаю не тестировать безглючность показометров а фактически затестить > полученное. Аха, запишет. А после записи твой диск на 20 вдруг сдох -- все данные на нем выше 10 гиг идут в нирвану, копий то нету на других членах это недореид1. >> ЗЫ: >> И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов? > Смотря что понимать под "непременно" и "требуется". В degraded то режиме он > и с 1 диском зацепится, только это уже не RAID1 как > таковой будет. Ну т.е. ты снова нагазовал.
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	236. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 11-Ноя-24, 09:48
	>[оверквотинг удален] > Я так, смотрел краем глаза, ну и вон там аноним - с > RAID подтвердил мои идеи, какое там управление. И именно от такого > я и хочу уйти в "device add" -> +N места. Даже > в RAID. Это круто, хорошо и правильно. >> И в дизайне ФС ты профан. > А таки я посмотрел на то как разные ФС устроены - и > почему так. И составил свое мнение о работе архитектов. В ZFS > вообще половина мест "почему так" - "мы так привыкли". Будем считать > что я не фанат такого rationale в архитектурах. Предпочитаю более понятные > мне решения, которые облегчают мою жизню. Сколь на картину не смотри, коль ты профан в искусстве -- ты ничего там не увидишь.
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	239. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 11-Ноя-24, 15:53
	>> что я не фанат такого rationale в архитектурах. Предпочитаю более понятные >> мне решения, которые облегчают мою жизню. > Сколь на картину не смотри, коль ты профан в искусстве -- ты > ничего там не увидишь. Самокритика - это хорошо. Ибо от вас я вообще никогда не видел ни малейшего понимания как работает всякая системщина и алгоритмика, чисто потребительский апломб с попытками примазаться к тому к чему вы никакого отношения не имеете. Да и вообще, таланты и что ваше сообщество может - было отлично показано на примерах релиза с профачеными рефлинками. Это то что хайпожоры типа вас из себя реально представляют. Пафоса много, дела чуть. Не люблю когда наобещали больше чем по факту могли, для ФС это хреново.
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	243. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Минона (ok), 12-Ноя-24, 09:28
	>>> что я не фанат такого rationale в архитектурах. Предпочитаю более понятные >>> мне решения, которые облегчают мою жизню. >> Сколь на картину не смотри, коль ты профан в искусстве -- ты >> ничего там не увидишь. > Самокритика - это хорошо. Ибо от вас я вообще никогда не видел > ни малейшего понимания как работает всякая системщина и алгоритмика, чисто потребительский > апломб с попытками примазаться к тому к чему вы никакого отношения > не имеете. Это у тебя нету понимания даже того что такое RAID1. А об устройстве ZFS и подавно. > Да и вообще, таланты и что ваше сообщество может - было отлично > показано на примерах релиза с профачеными рефлинками. Это то что хайпожоры > типа вас из себя реально представляют. Пафоса много, дела чуть. Не > люблю когда наобещали больше чем по факту могли, для ФС это > хреново. Что-то я не видел тут ссылок на твой гитхаб с патчами btrfs о которых ты тут вещал. Специалист ты наш...
	Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

	158. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (158), 05-Ноя-24, 17:57
	нам нормально.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	64. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 17:56
	> жаль, но zfs не в линуксе сделали Да и нормальной эту архаичную груду костылей можно назвать лишь с большой натяжкой.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	91. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–4 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 19:33
	>> жаль, но zfs не в линуксе сделали > Да и нормальной эту архаичную груду костылей можно назвать лишь с большой натяжкой. По управлению схемами хранения и месту - дико сливает и сабжу и btrfs. И снапшоты какие-то дурацкие. И управление памятью дурное. А заодно еще и внемайнлайновый выкидыш - у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа!
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 20:27
	Да там при ближайшем рассмотрении вообще всё оказывается через одно место сделанным. Например чтобы заставить ZFS монтировать датасеты в правильном поядке нужно задействовать специальную, прикрученную изолентой службу zfs-mount, иначе фс будет монтировать их в соответствии с их именами, а не точками монтирования (!). Или вот ещё какой прикол обнаружил: https://i.postimg.cc/26frGVd5/Screenshot-2024-10-17-17-53-42... Т.е. автоматическая подмена вышедших из строя дисков работает только применительно к тому vdev, на котором расположены данные, но не работает в отношении к vdev, на котором расположены, скажем, метаданные, при том что для таких устройств в руководстве даже отдельно оговорено что они должны иметь избыточность равную избыточности основного массива. Т.е. избыточность их беспокоит, а выход из строя дисков не беспокоит )) Там значит система сама подкинет spare диск, а тут сиди и глазами следи. Шизики! Или уже набившая оскомину невозможность расширения raidz массивов... Как объединять диски в масиивы они придумали, а как потом эти массивы расширять они не придумали... И у кого-то ещё поворачивается язык нахваливать эту ФС, приписывая ей какаие-то невообразимые свойства, а их создателей гордо именуя Инженерами с большой буквы :)
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (1), 04-Ноя-24, 22:11
	> Да там при ближайшем рассмотрении вообще всё оказывается через одно место сделанным. > Например чтобы заставить ZFS монтировать датасеты в правильном поядке нужно задействовать > специальную, прикрученную изолентой службу zfs-mount, У ZFS вообще очень странные понятия о менеджменте. Вон там в советах какие-то дикие тантры с экспортом, импортом, еще черти чем. Был бы btrfs какой - просто зацепили бы пул к другой машине и дело с концом. Без вот этого всего. ИМХО Кент был прав сдирая принципы менеджмента - вот оттуда. Vdev оно конечно не умеет - да и зачем? Там фича в простом менеджменте а не в том чтобы фигурно и концептуально по@#$ться неизвестно зачем. Ну саням то понятно зачем оно - у них вообще без этого RAIDов в оси не было, тут уж нравится, не нравится а что-то придумать придется.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (158), 05-Ноя-24, 18:04
	Вот не нужно гнать на солярис: был там софтверный райд (через metainit), был и аппаратный.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:47
	> Вот не нужно гнать на солярис: был там софтверный райд (через metainit), был и аппаратный. Оно все же ни в какое сравнение с тем что можно md+dm+lvm изобразить. Но вот менеджмент таких конструкций - это боль. И именно это дало новое дыхание "интеграшкам". Когда архитект Крис Мэйсон осознал что управление сторажем с несколькими девайсами - вовсе не обязано быть тем жестким брейнфаком, если парадигмы аллокации немного пересмотреть. Это и есть - прогресс. Это навсегда войдет в историю технологий хранения, и новые дизайны будут пытаться усовершенствовать идею - потому что делом показано что так можно было. И Кент тоже - вот - проникся.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (110), 04-Ноя-24, 21:57
	> у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа! Шо, прям убил? Он его в окно от расстройства выбросил что ли?
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	115. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (1), 04-Ноя-24, 22:15
	>> у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа! > Шо, прям убил? Он его в окно от расстройства выбросил что ли? Нет, он просто занятый человек - и у него не было времени отношаться с столь дурацкой проблемой, которая не очень просто чинится если система не бутабельна вообще. Я то прошареный, у меня grub и он даже и кернел в случае чего-то этакого может из снапшота читануть, так то оно ессно взлетит - хоть и с мануальным пилотированием слегка (указать правильнй рутфс, etc). Так и бутлоадер - средство отката снапшотов.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от Аноним (118), 04-Ноя-24, 22:25
	> Нет, он просто занятый человек - и у него не было времени отношаться с столь дурацкой проблемой, которая не очень просто чинится если система не бутабельна вообще. Странно, что настолько занятой человек добрался до zfs. Я вот тоже занятой — я просто гружу предыдущее ядро и не страдаю.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 02:44
	> Странно, что настолько занятой человек добрался до zfs. Было время - добрался.  Но ФС с снапшотами по задумке должна была облегчать восстановление системы - а не привносить новые, блин факапы с ней. И за это тот чел отругавшись свалил на btrfs, угумс. > Я вот тоже занятой — я просто гружу предыдущее ядро и не страдаю. Ну мало ли, может он сэкономил, вот, на инсталле бутлоадера где можно выбрать. Какойнить EFI на минималках линухкернел может вообще сам пнуть. В любом случае - внемайнлайновость это всегда заявка на неприятные сюрпризы такого рода. Кому как а мне нафиг надо рутфс который может не подцепиться. А вот снапшоты на нем - весьма полезны для парирования системных факапов как раз.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (110), 05-Ноя-24, 09:57
	> Ну мало ли, может он сэкономил, вот, на инсталле бутлоадера где можно выбрать. т.е. какой-то ССЗБ из вашего рассказа получается. Сначала навертел чего-то странного, потом не справился с последствиями. А ругался на zfs
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от Аноним (-), 05-Ноя-24, 19:49
	> т.е. какой-то ССЗБ из вашего рассказа получается. Этот ССЗБ так то живет - сильно получше вашего. И должность у него - сильно покруче того что вам даже чисто теоретически светит. И я думаю что умение признавать ошибки - и переигрывать решения, если туго идет - очень помогло ему стать именно таким. > Сначала навертел чего-то странного, потом не справился с последствиями. А ругался на zfs Ну он и справился - реинстальнув btrfs. Который так не отваливается. Дешево и сердито. А вы там преодолевайте искусственные трудности во имя луны, если оно вам зачем-то надо.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (110), 05-Ноя-24, 21:07
	> Этот ССЗБ так то живет - сильно получше вашего. И должность у него - сильно покруче того что вам даже чисто теоретически светит. ну, если бы у меня все было настолько сильно в шоколаде, то пожалуй я бы нанял себе админа — дешевле будет > И я думаю что умение признавать ошибки - и переигрывать решения, если туго идет - очень помогло ему стать именно таким. было время — поставил zfs, не стало времени — узнал, что не знает, чего ожидать. Это какие-то метания, а не переигрывание. Человек с должностью "сильно покруче" должен уметь оценить свои силы (и не только свои) и принимать взвешенные решения. > А вы там преодолевайте искусственные трудности во имя луны, если оно вам зачем-то надо. так я не про трудности, просто история интересная. Она вообще выглядит так, будто кто-то налил человеку в голову "маркетинга", расписав светлое будущее и забыв упомянуть проблемы. А потом еще про btrfs налили. Больше не могу придумать, что было бы в голове занятого человека на высокой должности, что он решил пойти походить по граблям, при том, что эти грабли везде обсуждают
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (182), 06-Ноя-24, 08:13
	> ну, если бы у меня все было настолько сильно в шоколаде, то > пожалуй я бы нанял себе админа — дешевле будет Пускать стороннего админа на свой ПЕРСОНАЛЬНЫЙ комп/ноут?! Я такой фигни даже у сверхжирных топов от айти с персональными джетами не встречал. Это очень спорная идея, ибо Evil Maiden attack, и вообще ну нахрен, имхо. > было время — поставил zfs, не стало времени — узнал, что не > знает, чего ожидать. Это какие-то метания, а не переигрывание. Переигрывание - перейти на btrfs ;). Дабы более на такие приколы не нарываться в принципе. > Человек с должностью "сильно покруче" должен уметь оценить свои силы (и не только > свои) и принимать взвешенные решения. Не бывает людей которые вообще не ошибаются. Зато бывают те которые легко и быстро исправляют свои факапы, минимизируя урон. И если вопрос встал ребром то могут отманеврировать. За что их экспертизу и ценят. Но я лично вообще не думаю что вы всерьез видели менеджмент нормальных западных мегакорп чтобы с вами про их менеджмент имело смысл разговаривать. > так я не про трудности, просто история интересная. Она вообще выглядит так, > будто кто-то налил человеку в голову "маркетинга", расписав светлое будущее и > забыв упомянуть проблемы. Это примерно так и происходит - в том числе и на опеннете. ZFSники явно занимаются over-advertise, и даунплеем проблем и особенностей. Это выходит боком их репутации, когда случается вот что-то такое. > А потом еще про btrfs налили. Больше не могу придумать, что было бы в голове > занятого человека на высокой должности, что он решил пойти походить по граблям, при том, > что эти грабли везде обсуждают Btrfs никаких особых грабель лично мне не подкладывал. Более того - именно этому типу я в случае чего подскажу и что делать, и где с адекватными btrfs'никами обсудить. Это вообще мой друг, и познакомились мы на почве линуха. Я ж сказал - при интересе к линуху можно отхватить множество интересных знакомств с мощными людьми по всему глобусу. И это круто.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	68. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:16
	> Как не смогли? ZFS и ext4! > ZFS Её уже научили отключать CoW и расширять массивы?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	92. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 19:39
	>> Как не смогли? ZFS и ext4! >> ZFS > Её уже научили отключать CoW и расширять массивы? Ее научили в рефлинки. Првда, натягивали сову на глобус i++ лет, а потом - тестировать фичу решили - прямо на юзерях! Активировав по дефолту. Казалось бы, что может пойти не так?! И тут гентушники такие, перекомпилявшие игого - хлобысь! Затестили минное поле ударным забегом по нему. Так тоже можно, конечно...
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (118), 04-Ноя-24, 22:17
	только минное поле оказалось не связано не с рефлинками
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 02:46
	> только минное поле оказалось не связано не с рефлинками Да, его разложили еще супер-правильные господа из саней ажно. А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло. А кроме везения - надо было бошкой думать до того как активировать по дефолту, всем, совсем не тестированую фичу. Хотя думать надо было на тему - зачем вообще релизить нетестированый шит, для начала. Может, сперва ФС надо тестировать а потом - релизить? Наоборот - фигня получается.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (110), 05-Ноя-24, 09:34
	> А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло. оно сработало, когда вышли новые coreutils, так что да, рефлинкам просто не повезло > А кроме везения - надо было бошкой думать до того как активировать по дефолту, всем, совсем не тестированую фичу. или тестированную на недостаточно новом наборе софта — не всем дано быть гентушниками. Кстати, а когда в coreutils дефолт для рефлинков меняли они чем думали и как тестировали? > Хотя думать надо было на тему - зачем вообще релизить нетестированый шит, для начала Перестаньте платить им деньги, это лучшее стимулировние… Если бы Линус и компания не релизили нетестированный шит, то я бы до сих пор сидел без видеодрайвера — оно все еще периодически падает и вешает систему. Кстати, насколько помню, чтобы новые "фичи" заработали надо выполнять zfs upgrade, что само по себе не происходит. Так что совсем "по дефолту" оно было выключено
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 05-Ноя-24, 20:06
	>> А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло. > оно сработало, когда вышли новые coreutils, так что да, рефлинкам просто не повезло Эти кореутилсы "виноваты" - только тем что удумали по дефолту юзать фичи ФС, если уж они вывешены. И только. Как именно user-mode программа может быть "виновата" в том что кернел вообще и ФС в частности творит фигню при использовании фич ФС - оставим на совести "экспертов" от ZFS. Заодно спасибо за эпический хайлайт уровня. Вы не понимаете как работает ОС, ФС, и софт, но пытаетесь продвигать ценное мнение. За это я и не жалую такие комьюнити. > или тестированную на недостаточно новом наборе софта — не всем дано быть гентушниками. Это не извиняет релиз кривой ФС, сыпящейся при легитимных операциях, доступных в дефолтной конфиге. Специальный перк - если до этого активно напирали на integrity данных. > Кстати, а когда в coreutils дефолт для рефлинков меняли они чем думали и как тестировали? В майнлайновых ФС рефлинки нормально работают. А якорить whole shebang нагибая эффективность системных операций ради внеядерных выкидышей - зачем? Пусть сами и...тся как хотят. Если у них релизеры ламо, это их проблемы. > Перестаньте платить им деньги, это лучшее стимулировние… Ну я и не плачу ZFSникам нихрена. И все мои технологии сейчас - в основном вокруг btrfs. Но, может быть, со временем что-то и с сабжем будет. Это зависит от Кента. > Если бы Линус и компания не релизили нетестированный шит, то я бы > до сих пор сидел без видеодрайвера — оно все еще периодически > падает и вешает систему. А у меня вот - стабильно как скала. Но, может, секрет в том что я таки - пришел и помог зарубить пару багов? Да, так в опенсорсе можно было :). И теперь баги - у вас. А у меня - все прекрасно. Меня такой расклад - вполне устраивает. > Кстати, насколько помню, чтобы новые "фичи" заработали надо выполнять zfs upgrade, что > само по себе не происходит. Так что совсем "по дефолту" оно было выключено Это видимо на pre-existing конфигах. А на новых - как я понимаю оно сразу "мордой о порог". И вот тут к господам релизерам ТАКОГО, разводившим маркетинговый булшит на тему стабильности и интегрити данных сразу довольно много интересных вопросов появляется. Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниями. По моему - никак не стыкуются, и это толпа рас314-ев, а не релизеры, уж простите за мой французский.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (110), 05-Ноя-24, 21:40
	> Эти кореутилсы "виноваты" - только тем что удумали по дефолту юзать фичи ФС, если уж они вывешены. И только. это не корутилсы виноваты. Мне просто не нравится, что обвиняют рефлинки, хотя это не они. В остальном, кроме "виноватых", есть еще и осознанный выбор пользователей, используют ли они окаменевший дебиан или острие прогресса в виде арчей и прочего > Это не извиняет релиз кривой ФС, сыпящейся при легитимных операциях, доступных в дефолтной конфиге. А веселые релизы btrfs и, теперь, bcachefs мы так уж и быть простим? Вообще странная позиция про извиняет/не извиняет, если в каждой софтине прописан отказ от гарантий, претензий и прочего > В майнлайновых ФС рефлинки нормально работают. ну, как и в zfs > Ну я и не плачу ZFSникам нихрена но хочу обширного тестирования на бесконечном количестве произвольных конфигураций > И все мои технологии сейчас - в основном вокруг btrfs им хоть платите? Чтобы не тестировали на живых людях > А у меня вот - стабильно как скала. Но, может, секрет в том что я таки - пришел и помог зарубить пару багов? Да, так в опенсорсе можно было :). И теперь баги - у вас. А у меня - все прекрасно. Меня такой расклад - вполне устраивает. А как же ваша позиция, что трудности тестирования не извиняет релизы кривых проектов? Почему одиним проектам вы помогаете, а другие упрекаете в недостаточном тестировании? В принципе тут не озвучивалось, но в zfs вы баги открывали? Если да, то мои вопросы не в тему. А проблема с драйвером касалась не только меня и грамотные багрепорты уже были (потому что когда багрепорты заводили я был еще со старым ядром и рабочим драйвером). > Это видимо на pre-existing конфигах. А на новых - как я понимаю оно сразу "мордой о порог" тут соглашусь, с новыми гентушниками получилось не очень. Но благодаря их страданиям в дебиане будет более-менее отлаженный > Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниям вы еще верите обещаниям разработчиков?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 08:57
	> это не корутилсы виноваты. Мне просто не нравится, что обвиняют рефлинки, хотя это не они. А мне не нравятся - рас314и как релиз менеджеры, и вы правы в том что root cause - не рефлинки, а ЭТО. Совершенно рас314ский менеджмент релиза! Вывалить свежезапиленую фичу без тестирования? Врубив по дефолту? С аргументом "а иначе как тестировать?!" Отличный план релиза фс кичившиейся интегрити данных, 10 из 10! Для сравнения - я никогда не видел авторов btrfs делающих такие распасы. Они куда честнее маркируют фичи - предупреждая если нечто экспериментальное и не включая это по дефолту. > А веселые релизы btrfs и, теперь, bcachefs мы так уж и быть простим? Баги конечно бывают у всех, но чтобы настолько рас314ски отнестись к релизу, пользователям и их данным? Не видел! [такого у бтрфсников]. Да и там тестовые боты пачками и юзеры с -RC легионом. > прописан отказ от гарантий, претензий и прочего Эк кич по части интегрити данных резко слетел :) > ну, как и в zfs ZFS единственная ФС которая так обделалась в этой фиче. Сделав ее позже всех. Будучи первым массовым CoW по сути. >> Ну я и не плачу ZFSникам нихрена > но хочу обширного тестирования на бесконечном количестве произвольных конфигураций Для btrfs я нечто такое практикую: отстроить -RC под актуальные мне конфиги мне не сложно. Ну я и валидирую что меня ждет в будущем. В том числе и - вот - btrfs. >> И все мои технологии сейчас - в основном вокруг btrfs > им хоть платите? Чтобы не тестировали на живых людях Таки неск раз я им приносил шикарные баги - с бисектом. И благодаря этому они в релиз не попали. Судя по коментам btrfs'ников они очень довольны были. Не, для out of tree вы такое сами, это не обсуждается. > А как же ваша позиция, что трудности тестирования не извиняет релизы кривых > проектов? Почему одиним проектам вы помогаете, а другие упрекаете в недостаточном > тестировании? Потому что вон те господа - сделали мне вон то сильно проще и удобнее, замайнлайнив свою фс. А вот так в раках валидации -RC относительно своих конфиг я и им занесу багов, при том сразу с бисектами. Да и дизайн у них - интереснее. Не только на энтерпрайзы целит, и менеджмент простой и приятный. > В принципе тут не озвучивалось, но в zfs вы баги открывали? Если > да, то мои вопросы не в тему. Нет. Я вообще out of tree технологиями - не пользуюсь. А в btrfs я не только открывал баги. Я почти готовые решения приносил в виде бисектов. И вы можете догадаться сколько после этого живет баг. Да, через сутки я уже типично гонял валидацию фикса и после подтверждения он улетал в -RC очередной. Это - нормальные воркфлоу релиза. Кернела вообще. > были (потому что когда багрепорты заводили я был еще со старым > ядром и рабочим драйвером). А вот проблемы выкидышей - это проблемы выкидышей. Как репортить на майнлайн - в том числе и эффективно участвуя в гасилове при помощи например бисекта, если прокатило - я в курсе. Но там люди подыгрывают друг другу. > тут соглашусь, с новыми гентушниками получилось не очень. Но благодаря их страданиям > в дебиане будет более-менее отлаженный Да мне пофиг - я out of tree не пользуюсь вообще, а после такого шоу с рас314ским релизом - да чур меня, или как слить репутацию в моих глазах ниже Кента. Этот в отличие от - таки накодил ребилд снесенных метаданных, держит марку! >> Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниям > вы еще верите обещаниям разработчиков? Даже Кент свои обещяния - выполняет. А те и вовсе - будучи опытными не дают нереалистичных обещаний. И да, я хочу получать объективные данные о свойствах дизайна, а не булшит от фанатов. Зачем мне залеты от неверного планирования?!
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 05-Ноя-24, 09:49
	Ну если btrfs'ники не стесняются выпускать некондицию и тестировать свою поделку на юзерах, то почему разрабы zfs не могут делать так же? Чем они хуже?
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	42. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (42), 04-Ноя-24, 14:09
	- Потому, что файлов много!
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	14. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от DEF (?), 04-Ноя-24, 12:46
	Когда в XFS завезут коровы, чексуммы, сжатие, дедупликацию, скраб, собвольюмы - тогда может быть.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	23. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от Аноним (22), 04-Ноя-24, 12:57
	дык сделали уже, и первую буковку с X на Z заменили.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от DEF (?), 04-Ноя-24, 13:10
	Сколько буковки не меняй, но в ядро этот раздутый комбайн не попадет никогда. Лицензию надо менять, а не буковки.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 19:14
	> Лицензию надо менять И дизайн.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 19:41
	>> Лицензию надо менять > И дизайн. Начиная с управлением памятью, местом, заменой ископаемых околоблочных структур, ... и - что останется то? А, ну вот если нормально сделать - что-то типа сабжа и подучится. Только нахрен вам тогда старое название? Сами по себе три буковки никакого волшебства сами по себе не гарантируют :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 21:03
	> Начиная с управлением памятью, местом > местом Ой, кому кому, но только не фанатикам btrfs заикаться об управлении местом ))) До таких курьёзов как невозможность удаления файлов по причине отсутствия свободного места zfs бесконечно далеко. Что касается сабжа, то его вообще обсуждать бессмысленно, ибо он вообще ещё никем и нигде не используется. И неизвестно когда начнёт.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 22:23
	> Ой, кому кому, но только не фанатикам btrfs заикаться об управлении местом > ))) До таких курьёзов как невозможность удаления файлов по причине отсутствия > свободного места zfs бесконечно далеко. В ZFS просто какой-то кривой и странный менеджмент. Никакие докапывания до частностей не поставят этот брейфак в 1 ряд - с вон тем. В btrfs можно просто добавить или вынуть девайс, даже в RAID'е. И место поюзается - адекватно, без бреда с выравниваниями и проч, аллокация места динамическая, чанками (bucket'ами в сабже, примерно 1 фиг в итоге) а RAID переопределен в духе "раскинь этот экстент на 2 разные девайса" (не важно какую именно пару, лишь бы место под нужный тип записи было). Так что Кент и взял за основу те идеи. Next gen файлух - это вот так, и ни...т! > Что касается сабжа, то его вообще обсуждать бессмысленно, ибо он вообще ещё никем > и нигде не используется. И неизвестно когда начнёт. Моя пачка виртуалок, пусть и не сильно критичных, с этим не согласны. Там уже есть этого слегка. В целом оно относительно юзабельное. В тяжелый серьезный прод, ессно, не стоит пока.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 22:56
	Впервые слышу про проблемы с выравниванием и аллокацией на zfs. Как это выглядит хоть?
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (133), 05-Ноя-24, 02:53
	> Впервые слышу про проблемы с выравниванием и аллокацией на zfs. Как это > выглядит хоть? Ну вот смотри, допустим у нас 2 винча по 5 терабайт и 1 на 6. Btrfs из этого сделает примерно (5+5+6) / 2 == 8 TiB RAID1. А на ZFS ты чего из такого делать будешь, сколько получится и как это работать будет? А теперь еще подоткнуть 4-й на 8 терабайт без заморочек? И чтоб это RAID1 осталось и примерно 4 терабайта отросло? Управление btrfs и сабжа - ну вот как-то так. Это круто и удобно. И даже схему можно сменить без особых напрягов, за счет природы cow это сильно менее сыкотный маневр. У btrfs можно даже "soft restripe" сделать, когда новая схема аплаится только к новым записям, а старые - в прошлой схеме, вполне валидное комбо, как и разные схемы данных и метаданных. У сабжа есть небольшие отличия, но общая логика аллокации места на девайсах (chunks/buckets) та же самая и оно на уровне дизайна может все то же самое, так же. По тем же причинам. Отличия в основном сводятся к названию и деталям типа размера чушки аллокации места на девайсе.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 05-Ноя-24, 04:40
	> у нас 2 винча по 5 терабайт и 1 на 6. Btrfs из этого сделает примерно (5+5+6) / 2 == 8 TiB RAID1. А на ZFS ты чего из такого делать будешь, сколько получится и как это работать будет? На ZFS я соберу draid1, который при том же уровне надёжности даст мне на 25% больше полезного места, чем твой raid 1E. Кстати непонятно как у тебя получилось 8 TiB вместо 7.5. Разве объём входящих в массив дисков не выравнивается по меньшему из них? > А теперь еще подоткнуть 4-й на 8 терабайт без заморочек? И чтоб это RAID1 осталось и примерно 4 терабайта отросло? С 4-мя дисками ни о каком raid1 не может быть и речи. Естественно я соберу raid10 если нужна повышенная надёжность и draid1, если в приоритете полезный объём. Подоткнуть естественно не получится, поэтому просто пересоберу массив. Тут к сожалению ZFS похвастаться нечем. > разные схемы данных и метаданных. Такое ZFS тоже умеет. И да, я так и не понял, какое отношение это всё имеет к выравниванию?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 05:48
	> На ZFS я соберу draid1, который при том же уровне надёжности даст > мне на 25% больше полезного места, чем твой raid 1E. Кстати > непонятно как у тебя получилось 8 TiB вместо 7.5. Разве объём > входящих в массив дисков не выравнивается по меньшему из них? У btrfs RAID не блочный в его классическом понимании. Как впрочем и у сабжа. И это 1 из причин по кторым я считаю это next gen. 1) Они аллоцируют место на девайсах чанками (block group, bucket). 2) Для аллокатора RAID1 - "закинь 2 копии блока в 2 девайса в чанки этого типа". Если хотели записать мег в файло, валидно записать мег на dev1 и мег на dev2. А потом на dev1 и dev3, допустим. Заметьте: на dev1 занято +2 мега, но на dev2/dev3 только по мегу. Видите, можно ассиметрично аллоцировать. Однако, constraint схемы "всегда есть 2 копии на разных девайсах" выполнен. 3) Единственное ограничение для RAID1 в такой парадигме: в пуле долдно быть больше свободного места на остальных девайсах чем на добавляемом пустом. Иначе все же придется сделать тот самый непонятный "ребаланс". Который на самом деле существует - для вот этого. Без этого возможна ситуация когда на новом девайсе место еще есть, а на всех остальных уже выюзано и constraint выполнить не удается. Технически у btrfs block-groups (чанки) бывают для данных и метаданных и могут быть разной схемы хранения. У bcachefs более мелкие buckets, но идея похожа, она трекает "число желаемых реплик" и суммарно логика действа весьма сравнимая. Хоть и есть отличия в деталях. При этом логические смещения и физические, ессно, полностью декоррелированы. Но constraints схемы выполнены и отказ любого из девайсов не фатален. Если в упомянутом примере dev1 вылетел, окей, но dev2 + dev3 суммарно содержали и первую запись, и вторую. И можно недостающую копию отстроить из этого. Просто менее тупое управление местом чем блочное с выравниванием. И тут вы мне рассказываете как вы там место "сэкономите". > С 4-мя дисками ни о каком raid1 не может быть и речи. В btrfs мы говорим про RAID1 с любым числом девайсов >= 2. При именно 2 девайсах на выравнивание совсем забить не получится ибо - constraints схемы. Но если девайсов например 3, все намного интереснее - см выше про асимметричную аллокацию. > Естественно я соберу raid10 если нужна повышенная надёжность и draid1, если > в приоритете полезный объём. Подоткнуть естественно не получится, поэтому просто пересоберу > массив. Тут к сожалению ZFS похвастаться нечем. А в btrfs - я просто подцеплю 3й, 4й, i++ винч. И получу +n места в пуле. И все. И да, RAID1 из 3 дисков? Не проблема. Лишь бы свободное место было для удовлетворения constraints "2 копии на разные девайсы". Кенту такая механика аллокации тоже зашла - ибо это и есть next gen. Без делания мозга вон тем. Просто добавил диск и получил +N места. Рулить такой штукой куда как прикольнее. При том девайсы и вынуть можно. Если constraints схемы все еще получается обеспечить. При том удвинуто будет только реально аллоцированое место. Т.е. если на винче на 8Тб успело поюзаться 100 гигз, ворочать будут только эти 100 гигз и времена операции будут сильно более другие чем рестрайп штуки такого размера. У btrfs еще и backrefs есть чтобы быстро понять кому принадлежит вот это (и легко удвинуть его "отсюда"). Это же позволяет отращивать размер - и уменьшать его - без особых траблов. В том числе и вынув девайс из пула, даже с RAIDом. >> разные схемы данных и метаданных. > Такое ZFS тоже умеет. И да, я так и не понял, какое > отношение это всё имеет к выравниванию? У btrfs и сабжа сильно более другой подход к аллокации места на девайсах. Сюрприз. Именно поэтому они и next gen в основном. Теперь можно не делать мозг вашим брейнфаком. Можно просто добавить диск. Даже в RAID1. Не парясь выравниванием и проч. В самом плохом случае ребаланс потребуется, но зачастую и это - опциоонально. Так что по менеджменту это ... сильно более крутая штука. Это управление сторажами как оно должно было быть. И сабж предсказуемо слизал эти идеи.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 14:05
	Лично для меня основной минус ZFS - это не добавление (добавить - проблема не большая, см. ниже), а невозможность убрать диск из пула вообще. Хотя есть частичный лайфхак - см. ниже С выравниванием вообще проблем никаких - поставь min_auto_ashift=12 например, и будет тебе счастье. Если хочется иного - там 3 пары по 2 шт. ashift'ов - для zpool, для zvol и для самих дисков, один из которых read-only (physical_ashift). Добавить в zpool диски в случае mirror можно парой, при чём размер дисков добавляемой пары не обязательно должен совпадать с имеюшимися или друг с другом - однако добавится место, равное размеру меньшего из добавляемых. В результате если есть zpool c mirror (RAID1) из дисков 3+4Tb, то размер доступного места в пуле будет 3Tb, и остальной 1Tb можно использовать отдельно (например создать временный zpool), однако вернёмся к теме добавления. При добавлении в zpool 3Tb c mirror пары дисков в 5Tb и 6Tb, аналогично добавится 5Tb места, при этом zpool превратится в RAID10. При замене первого диска на 3Tb на больший диск например в 6Tb и выполнении resilver, по умолчанию добавится 1Tb места, так как меньший биск первой пары - 4Tb. И так далее. Если у тебя нет желания платить за надёжность 50% "налога" RAID1, то ты будешь использовать raidz, и если позже появится желание увеличить существующий размер raidz1 (~RAID5), raidz2 (~RAID6) или raidz3 (это где 3 диска резервных) - то по очереди меняй КАЖДЫЙ диск в raidz и делай resilver: при замене последнего мелкого диска на более просторный и окончании последнего resilver'а, доступное место увеличится кратно размеру наименьшего диска в zpool'е. Либо ты можешь добавить ещё один raidz1, raidz2 или даже mirror или даже просто 1 диск (если хочется риска) к zpool'у и так увеличить его размер. Если со временем планируешь докупить дисков, чтобы увеличить отказоустойчивость zpool'a - советую сразу создавать не raidz1, а raidz2 в котором один компонент отсутствует - virtual storage например, и потом просто отключаешь его, и всё. По факту у тебя тогда будет raidz1 с возможностью апгрэйда на raidz2. Когда купишь ещё один диск - подключишь его, и после resilver'а parity синхронизируется. Если подключить как hot spare, то вроде бы даже resilver сделается автоматически. Я всё сказал.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 14:38
	Добавлю, что в сценарии с заменой меньшего диска на больший в RAID10 из (3Tb+4Tb)+(5Tb+6Tb)=8Tb, ничто не мешает переместить диск 5Tb из второго субкомпонента в первый, таким образом увеличив доступное место следующим образом: (5Tb_old+4Tb)+(6Tb_new+6Tb)=10Tb
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	171. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 05-Ноя-24, 22:17
	> Лично для меня основной минус ZFS - это не добавление (добавить - > проблема не большая, см. ниже), а невозможность убрать диск из пула > вообще. Хотя есть частичный лайфхак - см. ниже Вы только что сказали, что будете перестраивать райд? И проблемы с выравниванием. А в btrfs я подцеплю i++'й девайс, скажу btrfs device add, на чем действо завершено, +N места в ФС, даже если это RAID. Ну, может, rebalance еще пнуть (опционально). А можно и device remove, удвинет данные на другие девайсы. Даже с RAID1. И я просто выну девайс после завершения операции. Потому что никакая парность и выравнивание там не упали, только constraint что должно быть скажем минимум 2 девайса с пустым местом (для RAID1). > С выравниванием вообще проблем никаких - поставь min_auto_ashift=12 например, Я так понял что потери места при сильно разных девайсах - будут. А там - таки нет. Ибо другие стратегии аллокации места. Возмжность просто изъять девайс следствие того что никаких "выравниваний" и "парных девайсов" более нет. Есть девайсы с свободным местом, constraints схему, и аллокация bucket/chunk-ов на них под обеспечение. > ashift'ов - для zpool, для zvol и для самих дисков, один > из которых read-only (physical_ashift). В вашем спиче много ненужных сущностей о которых я не хочу ничего знать после того как увидел технологии аллокации Мэйсона. Кент тоже внял и сделал примерно это же. У него есть отличия в деталях но общая логика действа примерно та же. И я думаю что будущее будет - вот так. > Добавить в zpool диски в случае mirror можно парой, А в btrfs можно добавить 1 произвольный, прям в RAID1. И получить +N места. И изъять тоже. Вот прям 1 девайс. Из RAID1. Он удвинет данные с девайса, -1 кандидат на который пары блоков кидать, -N места в ФС. Менеджмент ФС и RAID как он должен был быть с самого начала. > с другом - однако добавится место, равное размеру меньшего из добавляемых. А там - можно и добавить и вынуть 1 девайс. Прям в RAID1. Получив (или лишившись) примерно (DevSz/2) места, /2 возникает - "потому что в схеме RAID1 записей 2". Т.е. добавив 8 ТБ винч ожидается примерно +4ТБ места как RAID1. Или вынимая, -4ТБ (симметрично). > В результате если есть zpool c mirror (RAID1) из дисков 3+4Tb, > то размер доступного места в пуле будет 3Tb, и остальной 1Tb А btrfs и сабж - аллоцируют пространство chunk/buckets и пар никаких нет. Есть схема, есть constraints, есть девайсы с свободным местом. Add +1 девайс в фс, remove -1. И все. Так намного круче. > добавления. При добавлении в zpool 3Tb c mirror пары дисков в > 5Tb и 6Tb, аналогично добавится 5Tb места, Вернемся. Я забыл про брейнфак с "парами", выравниванием и "min(dev1, dev2)". И это было прекрасно. > например в 6Tb и выполнении resilver, по умолчанию добавится 1Tb места, > так как меньший биск первой пары - 4Tb. И так далее. А в случае btrfs и сабжа - можно об этом позоре забыть. Нет больше никаких пар. > окончании последнего resilver'а, доступное место увеличится кратно размеру наименьшего > диска в zpool'е. И опять этот брейнфак с девайсами и выравниванием. Увы и ах. А вон те схемы этим позором не снабжены. > Если со временем планируешь докупить дисков, чтобы увеличить отказоустойчивость zpool'a > - советую сразу создавать не raidz1, а raidz2 Я посоветую сам себе... 1) Не юзать внемайнлайновые технологии, дабы избежать кучи гимора и проблем с багрепортом. 2) Особенно от тех кто эвон как релизнул рефлинки, даже Кент на их фоне - паинька мальчик. 3) Не делать себе мозг ненужными сущностями, выравниваниями, min(dev1,dev2) и прочим кривым архаичным менеджментом. Уже можно намного лучше чем это. 4) Поменьше слушать советчиков с опеннета и побольше юзать критическое мышление и свою голову.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	178. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 06:42
	> А в btrfs я подцеплю i++'й девайс, скажу btrfs device add, на чем действо завершено, +N места в ФС, даже если это RAID Лол, до меня кажется дошло... Ты добавляешь диск к массиву, но до ребаланса данные расположенные на этом диске никакой избыточностью не обладают. Я правильно понимаю? Другими словами, ты просто добавляешь одиночный диск в систему. Но ведь и на ZFS я точно так же могу подоткнуть диск, создать на нём пул и назначить ему точку монтирования! И на LVM! )) И получу те самые 40 ГБ из моего примера! Ты это называешь "ассиметричной алокацией"? Прикалывашься?
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	179. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 06:46
	Точнее не 40, а 30 ГБ (в случае с raid1).
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	184. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (184), 06-Ноя-24, 09:55
	> Лол, до меня кажется дошло... Ты добавляешь диск к массиву, но до > ребаланса данные расположенные на этом диске никакой избыточностью не обладают. НЕ дошло. До добавки девайса - избыточность обеспечивали уже имевшиеся в ФС девайсы. А это +1 девайс в список возможных кандидатов куда писать парные блоки. Ребаланс опционален, нужен для более равномерной нагрузки и использования места. Иначе возможен случай когда суммарное свободное место остальных девайсов меньше чем на добавленном, в какой-то момент может оказаться что там еще есть место, а больше нигде нет, и constraint RAID1 не выполнен -> no free space left. Ребаланс пролечит это, я ж показал пример асимметричной аллокации, когда на 1 девайс 2 мега, на 2 по 1, но вылет любого из 3 девайсов ОК. Да, при вылете того который с 2 мегами записи, парные ему блоки раскиданы на 2 и 3 девайсе, и что?! Constraint выполнен, перестроить копию можно. Единственный известный мне случай ТОГО - runtime конверсия Single в RAID1 путем btrfs device add 2го девайса. Ну тут уж ой, избыточности в ФС еще не было. А, да, так можно было. И назад тоже. > Я правильно понимаю? Нет. > Другими словами, ты просто добавляешь одиночный диск в систему. Нет. Я добавляю место в фс. Появляется +1 девайс, кандидат для получения парных блоков. На нем тоже начинает жраться место. Что до этого записи вели к паре блоков на 2 разные девайса, что после. Constraints не нарушался и не нарушается. Такой вот runtime-reconfigurable RAID. > Но ведь и на ZFS я точно так же могу подоткнуть В btrfs три винча по 6 терабайтов, например, дадут (6 + 6 + 6) / 2 = 9 терабайтов RAID1. И даже ОК если будут разные по размеру девайсы. Ожидаемое место - в районе (сумма емкостей / 2). Т.е. скажем 6 + 8 + 10 дадут ожидаемое место порядка 12 терабайтов (24 / 2). Да, на более жирном может оказаться больше блоков. Но всегда будет парный им - либо на 1, либо на 2 девайсе, так что вылет любого из 3 все еще ОК! > диск, создать на нём пул и назначить ему точку монтирования! И на LVM! )) На LVM ты сойдешь с ума при попытке собрать что-то минимально сравнимое с этим... > И получу те самые 40 ГБ из моего примера! Ты это называешь > "ассиметричной алокацией"? Прикалывашься? Попробуй собрать RAID1 из 3 винчей на 6, 8 и 10 Тб и расскажи сколько получится? Отдельный бонус если ты не спятишь при этом :) А в btrfs что, жмешь device add на все что хочется подоткнуть - и все действо. Можно и remove, если столько места не надо. Взял да и вынул из скажем 6 дисков 1. И останется 5-дисковый RAID1. Абсолютно валидный, не degraded, вылет любого из 5 - ОК. То-есть видите, емкости совпадать не обязаны. И девайсы именно парами быть не обязаны.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	196. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 21:51
	> НЕ дошло. До добавки девайса - избыточность обеспечивали уже имевшиеся в ФС девайсы. Таки дошло. Добавляя диск к массиву без перебалансировки ты просто создаёшь смешанный зеркально-линейный массив, на котором избыточность имеют только те данные, что расположены на зеркале. Что ты собственно и подтвердил. Только зачем ты называешь это "расширением массива" если по факту до ребаланса добавленный диск частью зеркала не является? > В btrfs три винча по 6 терабайтов, например, дадут (6 + 6 + 6) / 2 = 9 Вот только это не raid1, а raid 1E (raid10 на нечётном количестве дисков). Будь это raid1 ты бы  при любом числе дисков получил не более 6 ТБ. У ZFS такого нет ввиду бессмысленности данной схемы при числе дисков более 3-х. Да и с 3-мя дисками многие предпочтут raid5, ибо он при сравнимой надёжности предоставляет больше полезного пространства. > На LVM ты сойдешь с ума при попытке собрать что-то минимально сравнимое с этим... Сравнимое с чем? С raid 1E? Не знаю как LVM (я как-то пробовал -- не получилось), но mdadm тоже может создавать такие массивы. > Попробуй собрать RAID1 из 3 винчей Напоследок повторю ещё раз: это не RAID1, а RAID 1E! Учи матчасть.
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	200. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 23:27
	> Таки дошло. Добавляя диск к массиву без перебалансировки ты просто создаёшь смешанный > зеркально-линейный массив, Completely missed point. Повторю еще раз - посмотрите как сделаны структуры сабжа и btrfs. У btrfs (и сабжа) аллокация работает - в других терминах. Там _нет_ статической аллокации места RAID, пар девайсов и проч. И нет линейного маппинга 1:1 (о чем вон тот мсг про чексумы прямо пишет, есть логические адреса, есть физические, и это разные вещи!). Именно для этого нужны block group/chunks/buckets. В этих юнитах отжирается место на девайсе. Это юниты в которые аллокатор отправляет запрошенную запись с нужной избыточностью на энные девайсы. Если девайс больше - на нем будет больше chunks/buckets, и будет та самая асиммметричная аллокация. Заметьте, в этом определении не фигурирует возможность существования без избыточности. Если уже заказана схема RAID1, и аллокатор не смог пульнуть на ДВА девайса при записи, WRITE FAILS, "no space left on device" или что там за резон что так не вышло. Подоткнутый девайс лишь +1 кандидат куда можно парные блоки скидывать. По мере записей он будет взят в оборот. > на котором избыточность имеют только те данные, что расположены на зеркале. Это не так. Избыточность имеет ВСЕ что записано после заказа схемы RAID1 (для трансформации single -> RAID1 конечно, надо balance пнуть, ибо записанное в 1-дисковую ФС было изначально заказано как "single" в данных и "dup" в метаданных). Технически это было так: block groups старых записей имели тип "single". Или в терминах сабжа - число реплик было = 1. Конверсия в RAID1 отращивает вторую копию. Заметьте, при этом совершенно оки-доки если это 3 девайса 10+10+20, на ЭТО лезет примерно 20. Технически на 20 будет примерно в 2 раза больше chunks, а парные ему блоки записей - раскидаются 50/50 между теми по 10. Вылет 20-го ессно требует чтение блоков с обоих 10-х, но какая разница, constraint схемы держится. > Что ты собственно и подтвердил. Только зачем ты называешь > это "расширением массива" если по факту до ребаланса добавленный диск частью > зеркала не является? Он станосится частью RAID1 после первой же записи где аллокатор решил взять в пару его и запулил парный кому-то еще блок туда. И сие позволяет кроме всего прочего - весьма резвое изъятие девайса. Без ребаланса туда будут попадут только некоторые новые записи, и то - не все. И если кто передумает и решит вынуть это из пула, move away придется сделать только для вот этих кусков. И вполне может быть что дофигатерабайт винч реально был заюзан на 100 гигс, и удвигается только 100 гигз. С сильно другим временем изъятия девайса чем полный рестрайп! Это делается так: проход по block groups, смотрение чье сие, копирование в другой BG данных для поддержки constraints опосля изъятия, апдейт указателей на новое место, GC группы, и так пока на изымаемом девайсе не останется юзаемых блочных групп. Это _не_ рестрайп всей площади. Это "деаллокация". Уменьшение ФС делается аналогично, только целью деаллокации BG является "хвост" фс. >> В btrfs три винча по 6 терабайтов, например, дадут (6 + 6 + 6) / 2 = 9 > Вот только это не raid1, а raid 1E (raid10 на нечётном количестве дисков). RAID1, определенный в этой парадигме, "уровня аллокатора" - это "закинь копии на какие-нибудь 2 девайса". Пары девайсов ессно динамически варьируются, место на них аллоцируется chunks/buckets. А не линейным маппингом вовсе. > Будь это raid1 ты бы  при любом числе дисков получил не более 6 ТБ. Это очень креативное переосмысление что такое RAID1. Constraints именно такой, "кинь 2 копии на 2 девайса". То что на уровне аллокатора принимаются решения о гранулярной аллокации места на девайсах, и вот эта запись на мег юзанула dev1+dev2 а та dev1+dev3, выжрав 2 мега на dev1 и по мегу на dev2 и dev3 - вопрос номер два. Как я уже сказал оно может в асимметричную аллокацию вот таким манером. Пытаться рассматривать не-блочный дизайн как привычный вам блочный рещительно не катит. Забудьте про это и посмотрите как это работает на уровне структур. > У ZFS такого нет ввиду бессмысленности данной схемы при числе дисков более 3-х. У ZFS этого нет в силу архаичности технологий аллокации. Но уже придумали способ лучше, и next gen теперь будут делать - вот так. Не, вы не натянете это на глобус по простому. Это надо очень сильно структуры ФС и аллокатор перепахать, в самом core аллокации. > Да и с 3-мя дисками многие предпочтут raid5, ибо он при сравнимой надёжности > предоставляет больше полезного пространства. У него есть ряд специфичных проблем перфоманса и надежности, которые трудно заделать на все сто. Тем более что с вашим ZFS если размер дисков разный - брейнфак опять же получается. > Сравнимое с чем? С raid 1E? Не знаю как LVM (я как-то > пробовал -- не получилось), но mdadm тоже может создавать такие массивы. С точки зрения constraints которыми оно оперирует - это обычный RAID1, "2 копии на 2 девайса". То что при N девайсов вариантов какие это пары для конкретной записи (выбирается на ходу) много - кто бы сомневался. Поэтому оно и живет с 3 дисками, записывая 20 на 10+10+20 :). Каждому блоку записанного существует пара. Просто в силу нелинейного мапинга она может быть и на ином девайсе. >> Попробуй собрать RAID1 из 3 винчей > Напоследок повторю ещё раз: это не RAID1, а RAID 1E! Учи матчасть. Технически это именно RAID1, и его именно так называют авторы - идея "2 копии на 2 девайса" осталась. Просто реализация... очень креативная. Это не очень хорошо описывается в классических блочных терминах ибо это не совсем оно. Но наиболее близкое описание этого творения инопланетян в земных терминах - такое.
	Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

	202. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 07-Ноя-24, 00:18
	Ты описываешь RAID 1Е, которому сто лет в обед. Я даже готов признать что данные на новый диск начинают писаться сразу в режиме рейда, но тогда если не делать ребаланс мы получаем явные проблемы с управлением свободным пространством, а после ребаланса теряем все преимущества "ассиметричной аллокации". И зачем оно надо? Также есть большие сомнения относительно надёжности схемы, в которой "Если девайс больше - на нем будет больше chunks/buckets". Что случится если девайс, на котором "chunks/buckets" больше чем на других девайсах, выйдет из строя? Откуда брать данные для восстановления? > Это очень креативное переосмысление что такое RAID1 Нет. Просто это не RAID1. Совсем. Безотносительно аллокации и прочих деталей. > У ZFS этого нет в силу архаичности технологий аллокации. У ZFS этого нет по причине ненужности. При 3-х дисках выгоднее raid5, а при большем количестве дисков -- raid10, raid5/6 и их производные. Видимо у btrfs действительно всё очень плохо с raid5/6 раз они решили изобрести подобный велосипед.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	212. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 08:10
	> Ты описываешь RAID 1Е, которому сто лет в обед. Это не оно. Как я уже сказал, фишка - в аллокации свободного места чанками, скрещеной с схемой избыточности. Более крутой и мощный superset. Позволяющий даже сосуществование N разных схем хранения в 1 фс, с разными constraints. Чанки могут частично использоваться, их может подгребать GC, у них может быть разный целевой usage или схема. У них даже разный размер может быть, если надо. Buckets примерно так же. Де факто логика обоих несколько конвергирует, с разных точек. Это не аллокация всей площади, не тупой 1:1 mapping. Это нарезка свободного места девайсов по кусочкам, с переигровкой, GC и проч, аллокатор решает на основании желаемого числа реплик/схемы куда, чего и как он пишет. Это не райды в блочном понимании, просто логика действа и свойства примерно как RAID1, по этой причине так и обозвано. Это не совсем точно отражает суть, но нет устоявшегося названия этой технологии. Этакий "пофайловый" RAID: теоретически в такой структуре можно даже было бы назначить разным файлам разные схемы хранения/избыточность, если научить аллокатор решать какую схему кому назначать. > Я даже готов признать что данные на новый диск начинают писаться сразу в режиме рейда, Если это уже было заявлено как RAID1, constraints RAID1 выполнялись до добавления диска и выполняются после добавления диска. Нет окон времени при которых constraints нарушены. > но тогда если не делать ребаланс мы получаем явные проблемы > с управлением свободным пространством, Они не с управлением, а с нагрузкой на девайсы и возможным перекосом с недоиспользованием свободного места в экстремальных краевых случаях когда большой пустой девайс добавили в очень забитый пул с мизером free space. > а после ребаланса теряем все преимущества "ассиметричной аллокации". Оно, напротив, предотвращает откровенно кривые случаи упомянутые выше, когда на большом новом девайсе навалом места - но решительно некуда разместить парный блок для выполнения constraints RAID1. В этом случае "no free space left" наступит раньше чем это могло бы быть. > И зачем оно надо? Это основа device add/remove, разных схем хранения в 1 пуле, простого расширения и уменьшения, вот этого всего. По своему красиво придумали, так и видно архитекта. > Что случится если девайс, на котором "chunks/buckets" больше чем на > других девайсах, выйдет из строя? Откуда брать данные для восстановления? С других девайсов. Я ж привел пример: если вылетел девайс с 2 мегами записей, мег с одного поменьше, мег с другого поменьше. А суммарно - полная копия того что на большом было. Просто раскидано по нескольким. Это автоматически обеспечено constraints схемы хранения и желанием аллокатора кинуть 2 копии на РАЗНЫЕ девайсы. >> Это очень креативное переосмысление что такое RAID1 > Нет. Просто это не RAID1. Совсем. Безотносительно аллокации и прочих деталей. По constraints это - RAID1. За что так и обозвано. Технологии аллокации и управления и правда рядом не стояли с блочным RAID1. > У ZFS этого нет по причине ненужности. При 3-х дисках выгоднее raid5, > а при большем количестве дисков -- raid10, raid5/6 и их производные. Я уже понял что удобный, простой и логичный менеджмент - без делания мозга - не про ZFS, так что им оно и не нужно. Да и не смогли бы они даже если б и захотели. Сильно дофига переделывать. Так что оно умрет кривым и мучительным уродом по менеджменту. А уже можно было - вот так вот. Просто device add того что было - и особо не делать мозг... > Видимо у btrfs действительно всё очень плохо с raid5/6 раз они > решили изобрести подобный велосипед. Упомянутая механика работает для всех схем хранения BTRFS. В зависимости от схемы constraints, конечно, меняются. Более того. Возможно сосуществование нескольких схем хранения в одной ФС. Soft конверсия уровня RAID это именно оно. У вас будет одновременно старая схема хранения в старых chunks и новая - в новых записях. Это совершенно валидное комбо для такого дизайна. Он также штатно живет с разными схемами избыточности данных и метаданных. По тем же причинам.
	Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

	199. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 23:21
	> Попробуй собрать RAID1 из 3 винчей на 6, 8 и 10 Тб и расскажи сколько получится? ~# lsblk: NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS sda           8:0    0    6G  0 disk sdb           8:16   0    8G  0 disk sdc           8:32   0   10G  0 disk ~# mdadm --create /dev/md0 -l raid10 -n 3 -p n2 /dev/sd[a-c]; ~# mdadm -D /dev/md0:            Version : 1.2      Creation Time : Wed Nov  6 20:08:15 2024         Raid Level : raid10         Array Size : 9429504 (8.99 GiB 9.66 GB)      Used Dev Size : 6286336 (6.00 GiB 6.44 GB)       Raid Devices : 3      Total Devices : 3        Persistence : Superblock is persistent        Update Time : Wed Nov  6 20:09:02 2024              State : clean     Active Devices : 3    Working Devices : 3     Failed Devices : 0      Spare Devices : 0             Layout : near=2         Chunk Size : 512K Consistency Policy : resync               Name : linux:0  (local to host linux)               UUID : 85411b14:0050b7dd:8bfa0d68:dc04959d             Events : 17     Number   Major   Minor   RaidDevice State        0       8        0        0      active sync   /dev/sda        1       8       16        1      active sync   /dev/sdb        2       8       32        2      active sync   /dev/sdc Потом просто накатываешь сверху LVM, создаёшь на нём любую ФС и получаешь готовый raid 1E.
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	201. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 23:46
	>         Array Size : 9429504 > (8.99 GiB 9.66 GB) А btrfs и сабж таки сделают что-то близкое к 12 из этого. И без брейнфака с размерами девайсов, рестрайпом по всей площади, и даже - возможностью относительно просто и быстро вынуть девайс, например. А вон там - больше долботни И хреновее результат. Одновременно. Бонусом btrfs и сабж за счет чексум - при расхождении копий видят которая из 2 кривая и чинят ее из исправной (self heal). А на обычном RAID вы видя что копии не сошлись - какие выводы сделаете? Что вы f...d up? :))
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	203. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 07-Ноя-24, 00:52
	> А btrfs и сабж таки сделают что-то близкое к 12 из этого А mdadm и raid5 сделают что-то близкое к 13, из этого же: Raid Level : raid5 Array Size : 12572672 (11.99 GiB 12.87 GB) Used Dev Size : 6286336 (6.00 GiB 6.44 GB) Raid Devices : 3 Total Devices : 3 > И без брейнфака с размерами девайсов И никакого брейнфака. Просто вбил две команды -- и готово. > Бонусом btrfs и сабж за счет чексум - при расхождении копий видят которая из 2 кривая и чинят ее из исправной (self heal). > А на обычном RAID вы видя что копии не сошлись - какие выводы сделаете? Что вы f...d up? :)) Не знаю как с этим у mdadm (не интересовался), но при создании массива средствами LVM можно указать ключ --raidintegrity=y, который деделает то же самое (правда в этом случае становится невозможным изменение размера LV, если мне не изменяет память). У ZFS с этим естественно вообще никаких проблем.
	Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

	213. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (213), 07-Ноя-24, 08:29
	>> А btrfs и сабж таки сделают что-то близкое к 12 из этого > А mdadm и raid5 сделают что-то близкое к 13, из этого же: Да, только если у вас не дай боже например девайс не помрет полностью, а, допустим, начнет ерунду выдавать/бэд вылезет и проч - и что вы будете с тем RAID5 делать? Вы видите что (Block1 XOR block2) != parity... и... который из трех девайсов нам в этом шиткомбо прогнал?! Btrfs то узнает - какой. Даже в вот именно этом случае. По чексумам. Но вон там у вас так сразу чексум - нетути. Донавесить еще и это? Brainfsck++! > Raid Level : raid5 > Array Size : 12572672 (11.99 GiB 12.87 GB) > Used Dev Size : 6286336 (6.00 GiB 6.44 GB) И толку с него такого, если он невосстановимо десинкнется после первой же трухи/бэда на любом из трех девайсов? Если кто думал что девайсы только целиком отказывают - это мягко говоря не так. И почему-то такие как вы предпочитают не вспопинать про такие failure modes. Неудобный топик, понимаю. Но я то себе не враг игнорить такое. >> И без брейнфака с размерами девайсов > И никакого брейнфака. Просто вбил две команды -- и готово. Вон там видите ли в целом соотношения лучше. И добавить. И изъяьть. Просто +N или -N места. И даже схему изменить. И сейчас. И попозже/дефернуто. > Не знаю как с этим у mdadm (не интересовался), но при создании > массива средствами LVM можно указать ключ --raidintegrity=y, который деделает то же > самое (правда в этом случае становится невозможным изменение размера LV, если > мне не изменяет память). У ZFS с этим естественно вообще никаких проблем. Никаких проблем. Кроме того что это все брейнфак VS "btrfs device add/remove" который просто и прозрачно ведет к тому же самому без всех этих извратов и ограничений. Поэтому я буду - за вот такое управление сторажами. Не без причин считая что будущее - это так. И Кент крут тем что тоже это понял.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	180. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (-), 06-Ноя-24, 06:48
	Теперь понятно, что ты используешь термин "выравнивание" не по назначению - индустрия под этим термином понимает выравнивание логических блоков до физических либо flash erase blocks. То, что ты ошибочно называешь этим термином - называется не так. Не делай так больше. Так же понятно, что у тебя какая-то фиксация на RAID1 и ты смирился терять 50% объёма массива на чётность. Однако я не настолько богат, по-этому приведу ещё такой пример, в котором при не равном размере трёх дисков (как corner case) потеря места на чётность всё-таки меньше 50%, и неразмеченного места нет (всё место используется): При создании zpool'а из диска на 4Tb и пары дисков на 6Tb, структура схематически может выглядеть так: raidz1(диск_4Tb+раздел_4Tb_на_диске_6Tb+раздел_4Tb_на_диске_6Tb)+mirror(раздел_2Tb_на_диске_6Tb+раздел_2Tb_на_диске_6Tb)=(8Tb+2Tb)=10Tb, что экономит 2Tb по сравнению с твоими мэйнлайн-привязанностями, и спасает от выхода из строя любого диска. PROFIT!
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	186. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (184), 06-Ноя-24, 10:02
	> Теперь понятно, что ты используешь термин "выравнивание" не по назначению - индустрия > под этим термином понимает выравнивание логических блоков до физических либо flash > erase blocks. То, что ты ошибочно называешь этим термином - называется > не так. Не делай так больше. Выравнивание бывает разное. Я имел в виду то которое по емкости девайса. У btrfs и сабжа по сути есть добавочный слой logical <-> physical offset. В конечном итоге buckets/chunks и их обвес - про это. И про аллокацию места на девайсе более гранулярно и гибко. > Так же понятно, что у тебя какая-то фиксация на RAID1 и ты > смирился терять 50% объёма массива на чётность. Учитывая что туда можно подоткнуть что попало из того что было - вместо выискивания подходящих, и именно парных девайсов... это не такой уж и плохой tradeoff? А если кто не ссыт экспериментировать - в btrfs можно сделать метаданные RAID1, или даже RAID1C3/C4 (3 или 4 копии). А данные RAID5. Это все же несколько стремновато, но самого фатального - write hole по метаданным - при этом не будет. А под данными ее по метаданным все же отловят чексумы. Это не очень протестировано и имеет особенности, но так можно было. А в целом мне нравится - вот такое управление местом. Device add -> +N места. Или device remove, -N места. Это правильное управление ФС и райдом. > что экономит 2Tb по сравнению с твоими мэйнлайн-привязанностями, и спасает от > выхода из строя любого диска. PROFIT! Но не спасает от брейнфака в менеджменте всей этой вундервафли...
	Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

	177. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 06:09
	Только что ради интереса создал на btrfs raid1 из трёх дисков (10+10+20 ГБ). После ребаланса получил доступный объём массива чуть менее 10 ГБ. Собственно как и должно быть при raid1, хотя схема размещения данных и метаданных при -dconvert=raid1 -mconvert=raid1 какая-то стрёмная (если прибавить ещё ключ -sconvert, то получается классический raid1). Т.е. это даже не raid 1E, при котором у меня должно было получиться около 15 ГБ. При этом я также пробовал конвертировать массив в raid5 и получил чуть менее 20 ГБ доступного пространства, т.е. снова как и положено при raid5. В обоих случаях массив ожидаемо был подстроен под размер меньших дисков, никакого дополнительного пространства я не получил. Что я делаю не так? Куда делась ассиметричная аллокация? Подтверждений твоим дифирамбам в адрес интуитивности управления btrfs я кстати тоже не обнаружил. > И тут вы мне рассказываете как вы там место "сэкономите". Естественно сэкономлю, ибо полезный объём массива raid5 (S*(N-1)) очевидно больше чем у raid 1E (S*N/2), о котором я подумал после прочтения твоей простыни и которого в упор не обнаружил, и уж конечно больше чем у raid1 (S).
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 06-Ноя-24, 11:18
	> Только что ради интереса создал на btrfs raid1 из трёх дисков (10+10+20 > ГБ). После ребаланса получил доступный объём массива чуть менее 10 ГБ. Вы пробовали записывать данные и посмотреть сколько влезет? > Собственно как и должно быть при raid1, хотя схема размещения данных > и метаданных при -dconvert=raid1 -mconvert=raid1 какая-то стрёмная (если прибавить ещё > ключ -sconvert, то получается классический raid1). У btrfs нет классических RAID'ов... ;) ... > Куда делась ассиметричная аллокация? Подтверждений твоим дифирамбам в адрес > интуитивности управления btrfs я кстати тоже не обнаружил. Везде обмануть пытаются. Специально для вас, только сегодня! Повтор эксперимента со всеми командами. Можете проверить все сами! 1) Команду mkfs можно и менее навороченную, пофиг. 2) Выхлоп очевидных команд заскипан для компактности. # fallocate  -l $((1024*1024*1024*20)) btrfs20.bin # fallocate  -l $((1024*1024*1024*10)) btrfs10-1.bin # fallocate  -l $((1024*1024*1024*10)) btrfs10-2.bin # losetup /dev/loop0 btrfs20.bin # losetup /dev/loop1 btrfs10-1.bin # losetup /dev/loop2 btrfs10-2.bin # mkfs.btrfs -O extref,skinny-metadata,no-holes,block-group-tree,no-holes -L exp20-10-10 -d single -m dup --checksum xxhash /dev/loop0 # mount /dev/loop0 /mnt/20-10-10/ # btrfs device add /dev/loop1 /mnt/20-10-10/ # btrfs device add /dev/loop2 /mnt/20-10-10/ # btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/20-10-10 # btrfs fi sh /mnt/20-10-10/ Label: 'exp20-10-10'  uuid: f79cc5ba-db24-4a09-abf2-d98ee1b34f39     Total devices 3 FS bytes used 160.00KiB     devid    1 size 20.00GiB used 1.28GiB path /dev/loop0     devid    2 size 10.00GiB used 1.25GiB path /dev/loop1     devid    3 size 10.00GiB used 32.00MiB path /dev/loop2 # cd /mnt/20-10-10 # dd if=/dev/zero of=test.zero bs=1M dd: error writing 'test.zero': No space left on device 20190+0 records in 20189+0 records out 21170413568 bytes (21 GB, 20 GiB) copied, 644.474 s, 32.8 MB/s По моему тут даже дятлу видно что на 20 + 10 + 10 RAID1 из 3 девайсов записалось примерно 20 гиг, (20+10+10) / 2 == 20. "Пилотирование звездолета с гипердрайвом, for dummies". Наслаждайтесь. > и которого в упор не обнаружил, и уж конечно больше чем у raid1 (S). "Штиpлиц выстрелил в упор. Упор упал". Видимо, как-то так. Или у меня особый, уличный btrfs который таки записывает 20 гигз на 20+10+10 RAID1.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	195. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 21:45
	> Вы пробовали записывать данные и посмотреть сколько влезет? Нет, не пробовал. Признаю свою ошибку (доверился показаниям файлового менеджера). Сейчас перепроверил -- всё так и есть. Ну, почти. Поначалу я подумал что после перебалансировки действительно доступна половина от общего объёма дисков, но перепроверив на схеме 10+10+50 я получил те же 20 ГБ доступного объёма, что и со схемой 10+10+20, словно это не raid 1E, при котором должно быть доступно 15 ГБ, а raid5 )) И естественно никакой ассиметричной аллокации я снова не увидел. Либо у меня что-то не работает, либо btrfs вместо raid 1E (или "raid1" твоей терминологии) создаёт raid5 и выводит фальшивую информацию о массиве. Как бы то ни было, это в любом случае возвращает нас на исходные позиции. Конечно же это никакой не raid1, а скорее нечто подобное raid 1E, да и то если предположить что оно работает, ибо лично я даже этого не увидел. А если не делать балансировку, то это твоё "расширение" массива равносильно простому добавлению диска и монтированию его в любой удобный каталог, только хуже, т.к. неизвестно какие (и сколько) данные пишутся на зеркало, а какие в линейный массив (а до ребаланса новый диск, как мы уже выяснили, частью зеркала не является, т.к. не содержит копий старых данных). Короче, не ФС, а один головняк.
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	198. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 22:54
	P.S. Попробовал создать на этих же дисках (10+10+50) raid 1E с помощью mdadm -- ожидаемо получил 15 ГБ доступного пространства. Всё заработало с первого раза, в отличие ОТ ;)
	Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

	205. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (205), 07-Ноя-24, 01:13
	> P.S. Попробовал создать на этих же дисках (10+10+50) raid 1E с помощью > mdadm -- ожидаемо получил 15 ГБ доступного пространства. Всё заработало с > первого раза, в отличие ОТ ;) Только наверное 10+10+20? И вон то тоже с 1 раза работает. Вы просто побоялись сделать шаг, думая что там пустота. И в упомянутом случае у вам 15 а там честные 20, продолбали 25% А для 50+10+10 в случае btrfs ожидаемый RAID1 будет 20. Ибо забитые под завязку 10 и 10, на которых 20 суммарно. И еще 20 из 50 занято на 50'ом. Плюс 30 непоюзаных поугаев на 50-ке, ибо просто нет второго девайса куда 2-ю копию приткнуть. Если добавить еще 10 попугаев, отрастет на +10 (ибо на 50-ке еще 30 было не занято, можно до 10 гигс раскидать на новый девайс + 10 гигс из тех 30 свободных). Если не лениво можете проверить. Интересно же протестить мои знания механики "гипердрайва" в деле.
	Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

	209. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 07-Ноя-24, 02:39
	Нет, именно 10+10+50. Чтоб наверняка, да. Причём проверил снова и получил те же цифры: btrfs ("raid1") = 20 ГБ; mdadm (raid 1E) = 16 ГБ; mdadm (raid5) = 20 ГБ. Также проверил raid1 btrfs на схеме 10+20+30 и получил 30 ГБ. Так что вряд ли я ошибся. Походу каждая комбинация даёт разный результат. Просто мне идея создания массивов на дисках разного размера в голову никогда не приходила, поэтому я поначалу что и raid 1E и raid5 подстраиваются под меньший из дисков (как в raid1), а оказывается что это не так. Потом начитавшись твоих опусов подумал что raid 1E всегда даёт половину от общего объёма дисков независимо от их размера -- оказалось что это тоже не так. Все схемы дают свой результат, и как выяснилось btrfs тут вовсе не уникальна. Ради интереса, собери и ты raid1 btrfs на 10+10+50. Я удивлюсь если у тебя получатся другие цифры.
	Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

	214. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (213), 07-Ноя-24, 08:38
	> создания массивов на дисках разного размера в голову никогда не приходила, > поэтому я поначалу что и raid 1E и raid5 подстраиваются под > меньший из дисков (как в raid1), А вот Крису Мэйсону пришло в голову что менеджмент ФС может быть и куда дружественнее. Без этого делания мозга поиском одинаковых девайсов, запасов железа на складах и прочего брейнфака. Когда просто сделал device add тому что было, получил +N места, вот и вся возня с менеджментом ФС. Да, для этого он, конечно, развернул механику аллокации не имеющую ничего обшего с RAID1 на блочном уровне. Но т.к. constraints такие же (2 копии, на пару девайсов) это обозвали так. Учитывая что Кент содрал идею в этом смысле почти 1 в 1 - можно говорить уже о некоем новом классе этсамого. Но я не знаю более подходящих названий этого.
	Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

	204. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 01:06
	> Нет, не пробовал. Признаю свою ошибку (доверился показаниям файлового менеджера). Мне mc показывал 20 гигз, т.е. не врал. Но да, я не уверен что ВСЕ закоулки околофсной механии ядра линя и прог, из эпохи царя гороха с другими реалиями, сразу просекают столь радикальные изменения ландшафта. > но перепроверив на схеме 10+10+50 я получил те же 20 ГБ доступного Я команды накидал - желающие могут проверить сами. Nothing up in my sleeve. Зачем мне себя обманывать? :) > объёма, что и со схемой 10+10+20, словно это не raid 1E, Это не RAID1E а переосмысленный "RAID1 уровня аллокатора". Он кидает 2 копии записываемого на 2 разные девайса. Просто смещения и пары девайсов runtime selectable теперь. Механика с buckets/chunks и трансляции логика <-> физика нужны поэтому. А архитект малаца, смотрите, дети, "землянин увидел гипердрайв". Не верит что работает :) > что-то не работает, либо btrfs вместо raid 1E (или "raid1" твоей > терминологии) создаёт raid5 и выводит фальшивую информацию о массиве. Землянин смотрит на сглючивший навигатор. Что-то не так, но что?! Холст, голография. Никаких нарушений законов природы. Информация корректна. Асимметричная аллокация и трансляция логики/физики. Всего лишь. > Как бы то ни было, это в любом случае возвращает нас на исходные > позиции. Конечно же это никакой не raid1, а скорее нечто подобное raid 1E, Это очень расширенное и продвинутое понимание RAID1. Core идеи остался, 2 копии, на 2 девайса. Просто не 1:1 mapping, девайсы попарно не фиксированы. Бедный землянин, не понимает что за нафиг с гипердрайвом :) > да и то если предположить что оно работает, ибо лично я даже этого не увидел. А таки - не нарушает никаких законов природы. И работает так как я и предсказал. Забавно, да? Если вы хотите понять как это: забудьте про классические RAID. И смотрите на структуры и аллокатор. Тогда все просто и логично. Да, так можно было. Почему до этого доперли только сейчас, кто его знает. Мы еще много до чего не доперли, и возможно еще и не такое. > А если не делать балансировку, то это твоё "расширение" массива равносильно > простому добавлению диска и монтированию его в любой удобный каталог, Нет. Оно прозрачно подхватывается той механикой и теперь парные блоки можно и на это складывать. И - вот - у вас RAID1 и конвертируется из single в run time, и расширяется на ходу. И убавляется - кстати - тоже. Покуда constraints "закинь это на какие-нибудь 2 девайса" все еще выполнимы. > сколько) данные пишутся на зеркало, а какие в линейный массив (а > до ребаланса новый диск, Там нет никаких линейных вещей. Есть buckets/chunks/whatever как юнит аллокации, динамическая (де)аллокация места на девайсах, девайсы, желаемое число копий которые "на какие-нибудь 2 девайса" пытаются закинуть. "В какой-нибудь подходящий chunk/bucket". На выбраной паре девайсов это еще и физически разные локации в общем случае. Ну как тебе азы управления гипердрайвом? Уже делишь на ноль? Я понимаю что полет мысли архитекта был довольно крут, но если подумать - все просто и логично и позор лишь в том что раньше никто не допер до ЭТОГО :) > как мы уже выяснили, частью зеркала не является, т.к. не содержит > копий старых данных). Это не важно. Ибо копии были на девайсах добавленых ранее и constraints RAID1 вида "отказ любого 1 девайса ОК" - остается. > Короче, не ФС, а один головняк. Напротив. Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было - и все управление "гипердрайвом" по сути. Но для совсем безграбельной навигации лучше понимать тот трюк "изнутри", тогда все просто, логично и единственный вопрос - почему так раньше не делали?! Как-то так мы и узнаем кто крутой архитект и кто двигает технологии вперед.
	Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

	210. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 07-Ноя-24, 03:23
	> А таки - не нарушает никаких законов природы. И работает так как я и предсказал. Забавно, да? Нет. Забавно то, что btrfs работает даже хуже чем предсказал я. Я-то был уверен что её "raid1" при любых размерах дисков даст половину от общего объёма (как минимум), но выяснилось что ничего подобного нет. На каких-то комбинациях даёт половину, на каких-то нет. И никогда больше половины. И во всех случаях raid5 как минимум не хуже. > Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было Ага. Правда непонятно для чего это может понадобиться. Для того, чтобы можно было расширить доступное пространство и удалить файлы, которые в btrfs при недостатке свободного места удалить невозможно? )))
	Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

	215. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 08:45
	> Нет. Забавно то, что btrfs работает даже хуже чем предсказал я. Я-то > был уверен что её "raid1" при любых размерах дисков даст половину > от общего объёма (как минимум), но выяснилось что ничего подобного нет. > На каких-то комбинациях даёт половину, на каких-то нет. И никогда больше половины. Что логично если 2 копии. Но вообще я люблю делать "невозможное". Так что... дедуп, рефлинки, sparse файлы, сжатие и проч - все же могут внести коррективы на тему того сколько и чего. У меня спокойно лежит 5 образов по якобы 5 терабайтов на 10 Тб девайсе. Конечно это рефлинки одного и того же. Но формально как бы 25 гигз суммарно и cow поддерживает иллюзию что они независимые. Конечно это имеет свои лимиты. Но для тех целей - сработает. > И во всех случаях raid5 как минимум не хуже. Удачи тебе с обычным RAID5 на всяких md и проч. Особенно когда на 1 девайсе вылезет труха или бэд. ZFS имеет какие-то шансы, но в лине это внемайнлайновый выкидыш с 1 стороны, и нормальный менеджмент ТОГО уровня - ему не грозит. В силу архаичности внутреннено устройства. А уж можно было - эвон как. >> Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было > Ага. Правда непонятно для чего это может понадобиться. Для того, чтобы можно > было расширить доступное пространство и удалить файлы, которые в btrfs при > недостатке свободного места удалить невозможно? )))
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	197. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 06-Ноя-24, 22:04
	> У btrfs нет классических RAID'ов... ;) Конечно есть. raid5 или зеркало из двух дисков вполне себе классические.
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	206. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (205), 07-Ноя-24, 01:18
	>> У btrfs нет классических RAID'ов... ;) > Конечно есть. raid5 или зеркало из двух дисков вполне себе классические. Как максимум это иллюзия. Под капотом совсем другая механика трансляции и аллокации, не имеющая ничего обшего с той блочно-девайсной логикой. То что оно в сильно некоторых частных случаях похоже - может быть, но и только. Представляете, btrfs даже с смесью разных схем может жить. Видели "soft" рестрайп? Это делается так: существующие block groups остаются с старой схемой, а в новых записях аллокатор удовлетворяет требования новой схемы. На уровне стуктур фс это совершенно валидно - и по этой причине конверсию схем можно относительно безопасно вырубать, возобновлять и проч - и это реально работает. Я пару раз случайно проверял. Все же советую забыть про то что вы знали - и посмотреть на эти структуры. Вы будете удивлены "как можно было". Мне кажется вы имеете некие шансы осознать, просто паттерны "мытакпривыкли" застилает глаза и мешает что возможны менее идиотские варианты аллокации. А так можно было. И профессионализм архитекта познается - вот так.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	208. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 07-Ноя-24, 02:22
	Пофиг абсолютно какая там механика если они дают тот же результат, что и обычные схемы.
	Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

	216. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 07-Ноя-24, 08:48
	> Пофиг абсолютно какая там механика если они дают тот же результат, что > и обычные схемы. Они дают тот же результат только в некоторых случаях. В обшем случае - имея дело с btrfs или сабжем - лучше понять механику chunks/buckets, для понимания что на самом деле ожидается. Нет, пытаться примотать привычные вожжи к бортовому компьютеру - хреновая идея. Даже если это и можно при очень сильном желании, это очень субоптимальная идея. Вам придется жить с тем фактом что есть другое семейство технологий аллокации, отличное от того к чему вы привыкли.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	229. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от нах. (?), 09-Ноя-24, 19:14
	> С 4-мя дисками ни о каком raid1 не может быть и речи. > Естественно я соберу raid10 если нужна повышенная надёжность и draid1, если > в приоритете полезный объём. Подоткнуть естественно не получится, поэтому просто пересоберу > массив. Тут к сожалению ZFS похвастаться нечем. в смысле? (я не уверен за _d_ raid) Фича добавлена пол-года назад. Она немного странненькая, потому что нет понятия ребалансировки (размазанное по четырем дискам - так и будет 4way, т.е. будет в общем случае читаться медленней чем файлы записанные уже после подключения пятого). Но в общем-то если файлы тебе дороги - ты и сам вряд ли захочешь их "балансировать".
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	231. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 09-Ноя-24, 19:52
	Какой командой это делается? Потому что я некоторое время назад проводил опыты и у меня ничего не работало.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от нах. (?), 10-Ноя-24, 18:51
	> Какой командой это делается? configure && make Поскольку надо собирать либо master (не надо) либо 2.3(RC хзкакой он сейчас, бери последний) В 2.2 из твоего девуана фича бэкпортирована не будет. А дальше просто zpool attach, как обычно. (самое смешное что код написан - в 2021м. Но не был принят beсause of lack of resources, разумеется. Ну, лучших фс для линуксов у меня для вас - нет.)
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	29. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от НяшМяш (ok), 04-Ноя-24, 13:23
	> коровы The reflink feature, available since kernel version 4.9 and enabled by default since mkfs.xfs version 5.1.0, allows creating fast reflink'ed copies of files as well as deduplication after the fact, in the same way as btrfs. > чексуммы xfsprogs 3.2.0 introduced a new on-disk format (v5) that includes a metadata checksum scheme called Self-Describing Metadata. Based on CRC32, it provides additional protection against metadata corruption (e.g. on unexpected power losses). Checksums are enabled by default when using xfsprogs 3.2.3 or later, but can be disabled (necessary for read-write mounts on older kernels) using the -m crc=0 switch when calling mkfs.xfs(8) > дедупликацию Existing filesystems can be deduped using tools like duperemove or hardlink(1) from util-linux. > скраб xfs_scrub. Правда, пока экспериментально > собвольюмы А вот это вряд ли будет.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	34. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от нах. (?), 04-Ноя-24, 13:35
	> xfsprogs 3.2.0 introduced a new on-disk format (v5) that includes a metadata checksum scheme > called Self-Describing Metadata только метаданные и с теми непонятно что делать (не вижу рядом "и мы их научились дублировать, и раскладывать по разным носителям). Вряд ли у них есть интеграция с dm-raid чтобы при проблемах с первой копией просто попробовать вторую (у свинологии есть но она не поделится, возьмите ваш гнутый гепеле и засуньте себе - вооонтуда, а потом дальше кукарекайте как он защищает ваши права)
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 22:23
	> только метаданные и с теми непонятно что делать (не вижу рядом "и > мы их научились дублировать, и раскладывать по разным носителям). Ну как, констатировать - "ааа, факап!" и - загуглить картинку-демотиватор "хочется подарить некоторым", попроси такой у коллег :) > Вряд ли у них есть интеграция с dm-raid чтобы при проблемах с > первой копией просто попробовать вторую (у свинологии есть но она не > поделится, возьмите ваш гнутый гепеле и засуньте себе - вооонтуда, а > потом дальше кукарекайте как он защищает ваши права) Хыхыхы, ну вот поэтому мы и юзаем btrfs какой, где это все прекрасно работает. Без костылей. Прямо под GPL. Да даже у кента - ЭТО - уже работает худо-бедно. Так что если кто думал трясти жабой на фичу которая стремительно стала commodity - пусть попробует.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 19:58
	>> коровы > The reflink feature, available since kernel version 4.9 and enabled by default > since mkfs.xfs version 5.1.0, Таки - да. И самый позор что эта сова на глобусе смогла ZFSников обставить. И по крайней мере - без фееричных багов с потенциальным дестроем пула по причине "гентушник удумал пересобирать игого, а тот юзал рефлинки в хвост и гриву". >> чексуммы > xfsprogs 3.2.0 introduced a new on-disk format (v5) that includes a metadata > checksum scheme called Self-Describing Metadata. Это булшит бинго, господа! 1) Нормальной конверсии v4 -> v5 они никогда так толком не сделали. 2) Зато сделали нудеж что мол ваш немодный том перестанет поддерживаться после какого-то года. 3) Нет чексум данных, так что вероятность обнаружения кривого железа резко понижается. 4) И таки с scrub/online check они там уже i++ лет как пытаются что-то изобразить. As in "пытался совершить посадку самолет номер 13" - с той разницей что пилот предусмотрительно одел парашют и съ...ся заранее и теперь предпочитает с btrfs'никами отвисать почему-то :) > Based on CRC32, it provides additional protection Т.е. еще и выбрать тип нельзя. А заодно - удачи с снапшотами, управлением местом, дедубликацией, не говоря уж про смену уровней райда на ходу и прочих продвинутостей характерных для СОВРЕМЕННЫХ дизайнов. И не, та жуткая этажерка наслоений с md, dm, lvm и проч пытающаяся соорудить эквивалент вон того - администрированию не подлежит. Ибо страшное как апокалипсис. Особенно при обломе операций, крахах в этом процессе и проч. В этом смысле "интегрированные дизайны" где все это дело подвязано на логику cow/write anywhere - очень сильно впереди, по общей сложности и безграбельности такого действа. Сэмулить это более классическим дизайном - редкая порнография, когда все получается хреново и сложно. > Existing filesystems can be deduped using tools like duperemove or hardlink(1) from > util-linux. Hardlink - ламерская штука по сравнению с множественным референсом блоков. У меня есть эн виртуалок с диском формально на 20 гигз, у которых процентов 80 блоков совпадает. Не, хардлинком это не вариант - это независимые VM. Сделаные рефлинками с образа. А потом, вот, процентов 20 содержимого - разъехалось для поддержки абстракции что это отдельные файлы. А как ты это хардлинками? А, никак? Ну тогда у тебя каждая такая штука будет по 20 гигз жрать, от и до. >> скраб > xfs_scrub. Правда, пока экспериментально И так уже i++ лет... >> собвольюмы > А вот это вряд ли будет. Потому что не есть нормальный CoW, а так, жалкая пародия на фоне сабжа и btrfs'а. Хромая утка фсостроения. Майнтайнер видимо начал понимать где именно он видел перспективы делать из ежа птицу путем раздачи ему постоянных пинков. Самое прикольное что в btrfs и сабже есть это простое, прозрачное управление. С возможностью передумать насчет схемы хранения, добавить-вынуть девайс и проч - без делания мозга выравниванием под RAID и проч, ибо управление местом совсем иначе. Можно просто взять и просто расширить хранилку. Тем что есть. Или переиграть параметры. На ходу. Без долгих опасных операций по всей площади, чреватых 100% факапом при крахе какого-нибудь рестрайпа.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	38. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Someone (??), 04-Ноя-24, 14:02
	Вот из-за отсутствия всего перечисленного "ненужно" я и выбрал эту ФС и ни разу не пожалел.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	52. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (52), 04-Ноя-24, 16:17
	>Когда в XFS завезут коровы, чексуммы, сжатие, дедупликацию, скраб, собвольюмы - тогда может быть. Ресайз в минус, упаковку хвостов файлов.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	61. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 17:46
	В самой распоследней - есть, анонс прямо тут был, ЕМНИП...
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (52), 05-Ноя-24, 08:58
	Была новость, что толи работают над этим, толи только хотят. Но вот, что сделали, не было пока.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (13), 04-Ноя-24, 12:52
	>Почему бы не взять XFS Оно уже перестало ломаться и бить файлы при скачке напряжения или отключении света?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	25. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Someone (??), 04-Ноя-24, 13:05
	Лет эдак десять не могу воспроизвести эту ошибку. Пришлите пожалуйста дамп и скриншоты этой ошибки.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от akteon (?), 04-Ноя-24, 13:45
	это вы с ext3 путаете ...
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	62. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 17:50
	Ну да - XFS умно зануляет, а не тупо бъёт :) Но если питалово нормальное (а у вас на лаптопах именно так) - то и не вспомню даже чтоб (С)
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Олег (??), 04-Ноя-24, 16:44
	У вас полное непонимание работы фс Они разные, под разные задачи и нельзя одну допилить до вида идеальной
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	76. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:39
	> Они разные, под разные задачи Да неужели? и чем же интересно отличаются задачи btrfs и bcachefs?
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 18:43
	> Непонятно зачем так много файловых систем в линуксе. Почему бы не взять XFS и > просто всем им не пользоваться? Его хватит для большинства а тем кому не хватит > будут пользоваться чем нибудь другим. Вот и пользуйся своим убогим XFS, делаемым какими-то нонеймами, в стиле "а давайте попробуем натянуть сову^W COW на глобус^W не-cow дизайн?!". Это настолько "успешно" было - что за@#$шийся в край майнтайнер - чуть не единственное имя немного отличное от нуля в редхатопомойке среди блочнофайлушников - послал все это к черту и сбежал. И теперь отвисает с btrfs'никами почему-то. А по менеджменту ФС, схем райдов и места вида "добавил девайс, сменил схему хранения на лету, да еще scrub прогнал что все збс" - XFS рядом с btrfs/bcachefs не стоял, не стоит, и не будет в обозримом будущем чем-то сравнимым. Потому что ЭТО должно быть на уровне базовых структур ФС вколочено. А потом прикрутить на сопли - не получится нормально! Так что имхо сам свой XFS недоделаный юзай. Еще и форматы несовместимо ломанули - без миграции - ну я и смигрировал мои XFS на btrfs, раз такое дело пошло. Менеджить это все - намного удобнее стало, чексумы сразу и у данных и метаданных, расширить место легко, в RAID1 можно подтыкать все что под руку попало, без делания мозгов выраваниванием, офлайн дедупалки есть, вот это все.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	109. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от freebzzZZZzzd (ok), 04-Ноя-24, 21:51
	>Почему бы не взять XFS и просто всем им не пользоваться почему нет простой как валенок FS (навроде XFS) со сжатием - это хороший вопросик, потому что диды жили без скраба и снэпщотов и мы проживём.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	134. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (133), 05-Ноя-24, 02:58
	> почему нет простой как валенок FS (навроде XFS) со сжатием - это > хороший вопросик, потому что диды жили без скраба и снэпщотов и мы проживём. Диды тряслись над каждым локалхостом как осиновый лист убивая дни на окучивание 1 тазика. Мы ворочаем целыми фермами и флотилиями, которые большую часть их жизни мы вообще не видим и видеть не хотим - они должны просто работать, где-то в фоне, и не делать мозг. И конечно у нас нет ресурсов убивать столько времени на меенеджмент каждого локалхоста. Все должно просто работать. А присядки с этими вашими fsck и ответы на непонятные вопросы - для админов локалхоста. Которых из продов - вот - поуходили.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (158), 05-Ноя-24, 18:21
	Вот потому унаследованная инфраструктура у всех и расползается прямо в руках: новое делать кто-то ещё может, а вот искусство поддерживать работающим уже потихоньку уходит.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 22:26
	> Вот потому унаследованная инфраструктура у всех и расползается прямо в руках: новое > делать кто-то ещё может, а вот искусство поддерживать работающим уже потихоньку уходит. А расползается оно в том числе и потому что любители черной магии там такой дрищ разводят что нет слов. А потом еще нуб какой насмотревшись на это решает что ему тоже так можно было. И потом едитсвенное реальное что с этой помойкой можно сделать - ну вот реально редеплой. Ибо в цать раз меньше сил, времени и денег чем убабахается на попытки все же разгрести кал за вон теми красавами. Иногда метод геракла VS авгиевы конюшни все же рулит. А вы можете, конечно, лопатой там фигачить.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от maximnik0 (?), 04-Ноя-24, 22:31
	>Почему бы не взять XFS и просто всем им не пользоваться? Я первый был бы за ,но у этой фс- есть недостатки, проделанный на скотч и костыли COW,кэш свободного места,поправили конечно но проблемы то остались.Нет контрольной суммы для данных - вот этот дефект дизайна уже критичный.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	152. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (152), 05-Ноя-24, 11:39
	Развитие специалистов. Если просто пользоваться, то довольно быстро оказываешься отставашкой. А вот если самому пытаться создавать, то - в лидерах. Примеров - история цивилизации планеты Земля.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

7. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
Сообщение от Karl Richter (ok), 04-Ноя-24, 12:35
А чем эта ФС лучше BTRFS?
Ответить | Правка | Наверх | Cообщить модератору

	9. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–2 +/–
	Сообщение от DEF (?), 04-Ноя-24, 12:38
	Ничем. Btrfs уже давно в продакшене, быстрее, стабильнее и надёжнее. Также Btrfs дефолтная ФС в Fedora и OpenSUSE.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от dd (??), 04-Ноя-24, 17:28
	Странно, что заминусовали. BTRFS реально давно в проде, подтверждаю.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от _ (??), 04-Ноя-24, 17:52
	Ну да, все в курсе что мордокнига фотки ваших котегов в ней держит ... новых нарожают(С) :) А вот хоть один, хоть самый вонюченький но банк на ней назовете?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	71. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:24
	А ты про все банки знаешь какую файловую систему они используют?
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 23:30
	NTFS и ext4 соответственно. А ты чего думал?
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 06:10
	> NTFS и ext4 соответственно. А ты чего думал? У СУБД свои системы журналирования и им вообще удобнее всего было бы - на RAW разделах. Но тогда неудобно - админам. А если это не субд - вот тут упс, для general purpose файлухи такая педальность - сплошные грабли. А подложку под СУБД btrfs как раз умеет - режим nocow специально для этого, так что желающие косплеить кусок логики ФС сами могут получить что хотели.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от dd (??), 05-Ноя-24, 13:54
	> режим nocow специально для этого Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 22:37
	>> режим nocow специально для этого > Зачем? СУБД обычно сами хотят журналировать все - а некоторые и CoW при этом делать или какое-то подобие данной логики, типа версионирования. Они на самом деле сами по сути - как специализированные ФС. Поэтому некоторые умеют - на raw разделах работать. Но это неудобно админам и вопрос становится в том чтобы это все же был файл. В этом случае важно чтобы оно... 1) Умело in-place патчинг файла, на что как правило уповает механика СУБД 2) Было максимально тонким и прозрачным shim над "raw разделом" по сути. Ну вот nocow и позволяет - дать этим штукам то что они на самом деле хотели. Т.е. нечто примитивное, типа EXT4 какого. А журналить журналы, cow'ать cow и проч - в высшей степени дурная идея из-за увеличения объема повторяющихся по смыслу работ, при том это только мешается, тормозит и усиливает фрагментацию.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 03:59
	> А ты про все банки знаешь какую файловую систему они используют? Этот чудак на голубом глазу советовал мне CRC32 -> Blake2b в btrfs'е заменить. С аргументом "какой же лох CRC32 как чексумы ФС юзает сейчас?!". Разница в скорости вычислений в 30+ раз этого сэра не смутила. Все что надо знать о его экспертизе в файлухах, в общем то. А, самый эпик - он нашел ссыль на btrfs'ную вику, и меня же в нее и ткнул со всем апломбом, во. Я подивился такой прыти и ему даже перевел, раз он сам не умеет. Шикарный маневр получился. Ну вот такая вот эпичная экспертиза по фс и чексуммам в них у этого гражданина :). Это он в топике про оптимизацию CRC32C на интеле так отличился, в соседней новости.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	84. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:58
	> Также Btrfs дефолтная ФС в Fedora и OpenSUSE И в Альте кстати тоже. Да и Дебиан хоть и не использует btrfs по умолчанию, но в инсталлятор её добавили.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	12. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (13), 04-Ноя-24, 12:42
	>А чем эта ФС лучше BTRFS? Тем что не пожирает место на диске?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	85. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (79), 04-Ноя-24, 18:59
	Давно уже не пожирает.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–3 +/–
	Сообщение от Аноним (20), 04-Ноя-24, 12:52
	bcache хотя бы не впаривает пользователю свои снапшоты и коммюнити пока что менее упоротое чем у btrfs. Если не в курсе попробуйте спросить что-то типо "как отключит XYZ в btrfs" на реддите.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	28. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от НяшМяш (ok), 04-Ноя-24, 13:18
	> коммюнити пока что менее упоротое чем у btrfs юзать глючную файлуху написанную челом, который даже код не может по правилам в апстрим заслать, могут только самые здравомыслящие
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (31), 04-Ноя-24, 13:30
	Умение правильно послать изменения в апстрим и качество кода это логически несвязанные понятия, плюс сравнивать одного человека с корпорацией (в случае btrfs) это тоже интересно, для одного человека он добился действительно хороших результатов.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от нах. (?), 04-Ноя-24, 13:37
	там ТРИ копро-рации было. namely suse, oracle и даже, не поверишь, redhat. Поэтому теперь распутать эту вермишель уже и невозможно. У одного человека куда больше шансов доделать до работающего состояния, а не здесь играем, там рыбу заворачивали.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от нах. (?), 04-Ноя-24, 13:32
	Неумение автора правильно кланяться и переподавать с прогибом - не является недостатком fs. Скорее как раз наоборот. Вон в бырбыре и кланялись, и переподавали. А она как была глючным неисправимым месивом, так им и остается.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	65. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 17:57
	> юзать глючную файлуху написанную челом, который даже код не может по правилам в апстрим заслать, могут только самые здравомыслящие Ну эта ... дома то - почему бы и не да? А у чела есть _очень_ важное качество - нехилый "крутящий момент"(С)! И что то мне подсказывает, что вот именно вот это и станей FS NG для ведра, а бэтээр где был там и останется, к примеру. Но верить мне в прогнозах ... нельзя :)
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	122. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (122), 04-Ноя-24, 23:23
	> bcache хотя бы не впаривает пользователю свои снапшоты Bcache и Bcachefs - две совершенно разные ипостаси, из общего только некий common code в паре либ ядра. И все. В сабже есть примерно все то же что и в btrfs. Включая и снапшоты, конечно. Современная COW ФС без снапшотов - это издевательство над здравым смыслом. > и коммюнити пока что менее упоротое чем у btrfs. Если не в курсе попробуйте спросить > что-то типо "как отключит XYZ в btrfs" на реддите. Ну, Кент покуда вообще - из дебиана вылетел своими утиласми, за то что им для сборок чуть не ночнушки хруста надо. С весьма колоритными коментами от майнтайнеров на тему годности этого для прода и возможностей иметь дело с таким апстримом.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	161. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (158), 05-Ноя-24, 18:26
	Активно развиваемый экспериментальный продукт не может жить в окаменевшей стабильной системы — ужас-то какой! Да как же так!!! Да, в дебиане не место экспериментальному софту. Это не проблема, так задумано.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 05-Ноя-24, 22:40
	> Активно развиваемый экспериментальный продукт не может жить в окаменевшей стабильной системы > — ужас-то какой! Да как же так!!! Смотрите, дети, маркетинговый булшит - это как-то так. У меня эн виртуалок с ЭТИМ в вот именно дебиане - работает. Но да, ФСовские тулсы пришлось git checkout'ом отмотать на доХРУСТовую версию. Прикиньте, так можно было. И да, сам кентушка кажется тоже хруста и его приколов уже откушал - что у него ФС сама теперь учится себя апгрейдить-даунгрейдить и проч прям в ядре. Видимо там он себя еще завонять не успел и это лучше работает - чем вон тот хайп, стреляющий в пятки. > Да, в дебиане не место экспериментальному софту. Это не проблема, так задумано. Поразвелось тут всяких истин в последней инстанции... интересно, дебианщики уполномачивали вас за них вещать? Вот прям ВСЕ?
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (152), 05-Ноя-24, 12:04
	> ... на реддите ... Не то место, где спрашивать. Разве что типа: поболтать на лавке у подъезда.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	32. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от нах. (?), 04-Ноя-24, 13:31
	В первую очередь - тем что в той ни один из живущих уже не может разобраться. Десять лет с неисправимыми ошибками в raid6 - и никто не может понять, в чем причина. Сделай сам выводы о том, каково там качество остального спагетти-кода и куда его надо засунуть такой. Ну и layered storage в бырбыре не предполагался. Даже в zfs (с определенными поправками на старость решения, когда компьютеры были большие) есть.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	43. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (22), 04-Ноя-24, 14:17
	в zfs можно прикрутить быстрые ssd как кэш для пула на медленных дисках (L2ARC). что в принципе закрывает самый популярный сценарий использования слоеных накопителей.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от нах. (?), 04-Ноя-24, 16:06
	там, к сожалению, не все так солнечно. l2arc работает очень странно, и к тому же этот код вообще похоже уже лет пять никто не тестирует (прецеденты полностью неработающего in-memory arc, сломанного улучшайкерами и месяцы не замечавшегося - уже были) - он может вообще не работать как задумано (т.е. добавить тебе тормозов и износа ssd) Ну и нет, самый популярный это буферизировать запись как раз. Потому что чтение неплохо оптимизируется в памяти. А запись надо донести до диска не уронив, а не хранить в памяти вечно. Причем у CoW системы лишних записей на каждый чих неприлично много, эффективно оптимизировать ее, раз уж в системе есть быстрый носитель - стоит того. (нет, ZiL не кэш, дорогие читатели викивракии) Но fs нулевых годов эти мелкие недостатки простительны.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от dd (??), 04-Ноя-24, 17:32
	И чо? У них для таких Васянов как раз написано, что не надо юзать нашу реализацию raid5/6 в проде. Не, не читал? И думать там что-то про не готовый код и жаловаться на него это глупо.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	66. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от _ (??), 04-Ноя-24, 18:01
	> У них для таких Васянов как раз написано, что   Ну так и надо исправить: "не надо юзать нашу FS в проде." И это будет голимой правдой.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:12
	>> У них для таких Васянов как раз написано, что > Ну так и надо исправить: "не надо юзать нашу FS в проде." > И это будет голимой правдой. Когда у тебя будет прод размером с фэйсбук - твои лекции будут чего-нибудь стоить. А покуда научись отличать CRC32 от Blake2b - в том числе по уровню вычислителной сложности функций, без этого с тобой вообще не о чем говорить на тему фс, прода и алгоритмов.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 23:34
	Купи нормальный современный Ынтерпрайс сторидж и почитай доку :) Много найдёшь интересного. PS: Блин даже в слове "купи" получилось слишком много желчи :(
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (1), 05-Ноя-24, 05:59
	> Купи нормальный современный Ынтерпрайс сторидж и почитай доку :) Много найдёшь интересного. Я почитал более интересные доки - на внутреннюю структуру btrfs и сабжа. Зачем мне камлать на подачки богов с "секретами", если можно самому хаживать на пантеон, да поотвисать там с местными? :). Вон я там кадру попробовал объяснить в чем прикол с RAID1 из _трех_ девайсов, и как так получается что емкость /2 от суммарной даже если с выравниванием не парились. Прелесть опенсорса - в этом и состоит. Лучшие инновации не где-то там. А "at my fingertips". Так они мне намного больше нравятся.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:21
	> В первую очередь - тем что в той ни один из живущих > уже не может разобраться. Десять лет с неисправимыми ошибками в raid6 > - и никто не может понять, в чем причина. А вот еще одна экспертиза уровня бох^W пох. Если ты напрашиваешься, расставлю точки над i. За твой счет. Ибо - нарвался. 1) Причины как раз таки всем давно понятны. Это обычный write hole. 2) Что-то с ним не сделано только потому что эффективные и радикальные фиксы требуют - поменять немного дисковый формат. Несовместимо с старыми кернелами, конечно. Это делать мало кто хочет. 3) Для RAID5 воркэраунд более менее придумали и если метаданные в RAID1 то данные в RAID5 - можно, если осторожно. Это все равно не идеально, но все же. Тем кому это надо ессно - читают вику и readthedocs куда доки переехали, и понимают проблематиук, и окей ли они с теми соотношениями до того как в это влезать. > Сделай сам выводы о том, каково там качество остального спагетти-кода и куда > его надо засунуть такой. ZFS с его управлением памятью, какой-то античной пародией на экстенты, отшибленым управлением местом и снапшотами, странным кешированием и проч - ничего не поможет. > Ну и layered storage в бырбыре не предполагался. Даже в zfs (с > определенными поправками на старость решения, когда компьютеры были большие) есть. Да, брейнфак с управлением - в сабже и btrfs никто не собирается запиливать. Половина пойнта сабжа и btrfs - сделать управление простым и прозрачным. Хреново, медленно, стремно, не переконфигуряемо и с кучей запрыгов по граблям, хранением девайсов про запас и проч - всем, извините, надоело. Уже показано что можно лучше чем это. И если ZFS так не умеет, тем хуже для него. А носителей сакрального знания имени сана что-то уходят на мороз.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	95. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:04
	> А чем эта ФС лучше BTRFS? 1) Пытается быть шустрее. Пока, правда, не сказать что супер-успешно, но оно пока в фазе выноса багов, немного не до крутых оптимизаций при этом. 2) Может учитывать свойства девайса и юзать как фронтэнд (кэш) - но при этом учитывая еще и схему хранения. Т.е. это такой гибрид где можно кэширование скрестить с уровнями RAID, довольно забавно придумано. Когда это по отдельности - как в bcache - через именно блочный уровень - и кэш протирается - degradation зачастую получается вообще совсем не graceful при этом. А попросту ФС под кешом огребает крупноблочные факапы в рандомные места, и это запроектные аварии для любой ФС. А когда ФС явно в курсе что 1 копия в кеше, а вторая в более медленном но живучем девайсе - ну, скончается та копия в кешее, ее из более медленной починят. Менее дурацкое комбо в целом.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	102. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от kernel (??), 04-Ноя-24, 20:37
	1. Возможность создания многослойных пулов, собственно это главная фишка Bcachefs. 2. Поддержка шифрования. 3. Во многих тестах быстрее, чем btrfs (https://www.phoronix.com/review/linux-611-filesystems)
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

11. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
Сообщение от Аноним (20), 04-Ноя-24, 12:41
Не ожидал что разрабов ядра можно словить на "упс, вы забыли проверить это".
Ответить | Правка | Наверх | Cообщить модератору

	15. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Аноним (15), 04-Ноя-24, 12:48
	Посмотри код DRM/AMD и ужаснись
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
	Сообщение от Вася Пупкин (?), 04-Ноя-24, 13:06
	Ну так язык с конпелятором не помогают
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	41. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (41), 04-Ноя-24, 14:09
	Язык с конем-пилятором не мешают.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (1), 05-Ноя-24, 06:00
	> Не ожидал что разрабов ядра можно словить на "упс, вы забыли проверить это". А они что, не люди? Вы так говорите как будто они боги и в принципе не ошибаются. Они конечно выше среднего, но не настолько же?! :)
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

24. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
Сообщение от Аноним (24), 04-Ноя-24, 13:02
На 40% А сколько это в штуках?
Ответить | Правка | Наверх | Cообщить модератору

36. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+4 +/–
Сообщение от EDWIN (?), 04-Ноя-24, 13:39
Сразу вспоминается шутка про "мы неправильно считаем" Снижение числа выявляемых ошибок на 40% может также свидетельствовать о том, что на 40% увеличилось число невыявленных ошибок
Ответить | Правка | Наверх | Cообщить модератору

	96. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:05
	> Снижение числа выявляемых ошибок на 40% может также свидетельствовать о том, что > на 40% увеличилось число невыявленных ошибок Пессимист, грустно: хуже уже не будет... Оптимист, радостно: да будет, будет!
	Ответить | Правка | Наверх | Cообщить модератору

39. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+3 +/–
Сообщение от Аноним (39), 04-Ноя-24, 14:05
меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что они уже написаны на С) что создает конкретные проблемы для LTS дистрибутивов. Чисто религия головного мозга, лучше бы он скраб добавил вместо переписывания того что уже работает на язык который не понимает большинство разработчиков ядра.
Ответить | Правка | Наверх | Cообщить модератору

	40. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (41), 04-Ноя-24, 14:08
	Проржавление это то что всего происходит с не очень необходимым.
	Ответить | Правка | Наверх | Cообщить модератору

	44. Скрыто модератором	+/–
	Сообщение от Аноним (44), 04-Ноя-24, 14:17
	Ой, у вас всё, что вам не нравится - это пропихивание. Что нравится - святое развитие.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	45. Скрыто модератором	–2 +/–
	Сообщение от Аноним (-), 04-Ноя-24, 14:31
	> меня больше напрягает ситуация с пропихиванием раста но ты не Линус Торвальдс, и твое мнение не настолько ценное > меня больше напрягает ситуация с пропихиванием раста там же кажется диды-неолиляторы одного разраба выпихнули? так что может раст в ядро не попадет еще долго > на язык который не понимает большинство разработчиков ядра. и? т.е теперь на дыряшке нужно писать вечность? или достаточно подождать пока разрабы впадут в деменцию или помрут?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	51. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от нах. (?), 04-Ноя-24, 16:08
	> что создает конкретные проблемы для LTS дистрибутивов никакой проблемы - в них bcachefs и не попадет ближайшие лет десять. Чиста автору захотелось потренироваться на кошках, да. Никакого смысла в переписывании (уже работающих, как обычно) утилит для работы с фс на безопастный йезычок, разумеется, нет.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	193. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от Karl Richter (ok), 06-Ноя-24, 17:35
	Толькл если не окажется, что там полно ошибок работы с памятью.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (-), 04-Ноя-24, 20:07
	> меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что > они уже написаны на С) что создает конкретные проблемы для LTS Ну вот тут Кентушка уже с своими распоследними ночнушками хруста уже получил несколько жирных отлупов от тяжеловесов дистростроения что они думают про это. А вынос из дебиана означает что этого в простом безграбельном виде также не будет и в деривативах, как то убунтах, минтах и проч. И тут желающим похайповать есть над чем подумать.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	141. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (1), 05-Ноя-24, 06:02
	> меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что > они уже написаны на С) что создает конкретные проблемы для LTS > дистрибутивов. Чисто религия головного мозга, лучше бы он скраб добавил вместо > переписывания того что уже работает на язык который не понимает большинство > разработчиков ядра. Ты б определился чтоли, ты про btrfs или сабжа? Может это про bcachefs-progs было? Да, там хруста напихали и ночнушками обмазались. За что вылетели из дебиана и деривативов.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

49. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
Сообщение от Ося Бендер (?), 04-Ноя-24, 16:00
Нет, зря Линус Кента носом об стол елозил! Не в коня корм. 60% процентов ошибок он и до пенсии не исправит.
Ответить | Правка | Наверх | Cообщить модератору

	54. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+2 +/–
	Сообщение от Аноним (54), 04-Ноя-24, 16:39
	главное показать бурную деятельность. а там и должность в микрософт не за горами
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 18:05
	А кстати - да. Если парень покажет на что способен - выкупят с потрохами! Будет фишечкой в их Azur'e ... не бесплатной конечно :)
	Ответить | Правка | Наверх | Cообщить модератору

73. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
Сообщение от Аноним (79), 04-Ноя-24, 18:33
Оверстрит - перфекционист, да ещё с гипертрофированным самомнением, а перфекционизм ещё никого до добра не доводил. Он просто не может остановиться, поэтому bcachefs никогда не будет закончена.
Ответить | Правка | Наверх | Cообщить модератору

	137. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
	Сообщение от Аноним (137), 05-Ноя-24, 05:18
	Перфекционизм очень даже доводил до добра и не раз. Проблема - хоть до чего-то доводит очень долго и редко. Но если вдруг будет результат, то ух какой будет!
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Аноним (1), 05-Ноя-24, 06:03
	> Оверстрит - перфекционист, да ещё с гипертрофированным самомнением, а перфекционизм ещё > никого до добра не доводил. Он просто не может остановиться, поэтому > bcachefs никогда не будет закончена. Есть надежжа что пинки толпой - несколько откорректируют это дело и он таки станет несколько адекватнее.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

74. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
Сообщение от 12yoexpert (ok), 04-Ноя-24, 18:33
это оно постоянно ломается или btrfs? постоянно путаю два этих ненужна
Ответить | Правка | Наверх | Cообщить модератору

	78. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от Вася (??), 04-Ноя-24, 18:45
	ломается то, что используется, вот бтрфс используется хотя б чуть чуть, а бкаш нет
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+/–
	Сообщение от _ (??), 04-Ноя-24, 23:37
	Я хоть и не фанат бЭтЭра - на справедливо. Ещё очччень рано в-серьёз об
	Ответить | Правка | Наверх | Cообщить модератору

218. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	+1 +/–
Сообщение от Соль земли (?), 07-Ноя-24, 11:08
То есть уменьшил не количество ошибок, а фактов их выявления, лол!
Ответить | Правка | Наверх | Cообщить модератору

	227. "Автор Bcachefs констатировал снижение числа выявляемых ошибо..."	–1 +/–
	Сообщение от yurikoles (ok), 09-Ноя-24, 14:24
	Потому что последние 1.5 пользователи-энтузиасты этой альфы устали от N потери всех свои данные.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема