Кент Оверстрит (Kent Overstreet), разработчик ФС Bcachefs, сообщил о снижении числа всплывающих при использовании тестового инструментария ошибок на 40% по сравнению с прошлым месяцем, а также о кардинальном уменьшении числа сообщений о критических проблемах. В результате проделанной работы, общее качество кода повысилось и поток ошибок пошёл на убыль. Тестовый робот Syzbot выловил большую часть тривиальных ошибок вида "упс, мы забыли проверить это" и теперь находит в основном реально редкие и интересные ситуации...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62169
Красава, Кент! Сразу пошел торвальдсу хвастаться
> Красава, Кент! Сразу пошел торвальдсу хвастатьсяНу а что, сам себя не похвалишь - никто не похвалит. А поработав почти 10 лет над ФС, и выкатив нечто более-менее работающее (у меня N виртуалок с этим вполне себе пашет) - почему бы и не похвастаться немного. Если в этом мире мямлить невнятную хрень - вас замнут хайпожоры. Главное чтобы баланс был между баззвордами и реальными делами. В сабже технологии достаточно продвинутые, попытка взять лучшее из других, i++'th edition. А поскольку оно появилось позже других то получило некий шанс изучить их проблемы и попробовать обойти.
>bcachefs: Fix NULL ptr dereference in btree_node_iter_and_journal_peek (2024-10-29 06:34:11 -0400)выглядит безопастно (ц) и целых 4 дня назад, теперь уже точно стэйбл
> выглядит безопастно (ц) и целых 4 дня назад, теперь уже точно стэйблДа вообще, на практике оно все же в целом просто работает. А на это вот нарваться - наверное можно. Но придется сделать что-то этакое. А так не ошибается тот, кто ничего не делает.
В этом вашем фрибсд например - ZFS содраный с линя да - вот - своим ходом жуткий уродец ufs, с морально устаревшими технологиями ФСостроения. И из всех BSD вообще - разве что HammerFS внимания стоит. Остальное, простите, г-но. Даже по сравнению с, вот, линухом. А другой вселенной с другими реалиями у меня для вас, увы, нет.
>В этом вашем фрибсд например - ZFS содраный с линя да - вот - своим ходом жуткий уродец ufs, с морально устаревшими технологиямиРжём голос. В этой фразе вся суть линь-сообщества: сначала принижать то, чего нет у себя, зато как только переступили, так сразу оказывается что это они создатели всего, что есть в пингвиняшке.
судить по одной особи о всем сообществе это норм?, ну чем вы лучше?
> Ржём голос. В этой фразе вся суть линь-сообщества: сначала принижать то, чего
> нет у себя, зато как только переступили, так сразу оказывается что
> это они создатели всего, что есть в пингвиняшке.Как говорится, у кого что болит, тот про то и говорит...
1) Я вообще не юзаю ZFS ни в каком виде.
2) Это не отменяет существование ZoL.
3) И именно оттуда BSD сейчас и тягают ZFS, независимо от того нравится вам это или нет.Вы все еще хотите поговорить про комплексы неполноценности после этого? :)
И вот это - квинтэссенция вашего сообщества. Надеюсь это объясняет почему я его всерьез не воспринимаю. Ибо когда мне например потребуется помощь зала - от таких как вы я не сильно много помощи дождусь. Почему-то. А вот от тех - в линухе - вполне. Если это делать правильно.
ZFS в ядро уже впилили? Или всё так же, стыдливо подгружая модульком? Не задумывался почему и откуда растут ноги у ZoL?
> ZFS в ядро уже впилили? Или всё так же, стыдливо подгружая модульком?Ну я им и не пользуюсь ни в каком виде. Мне btrfs'а хватает и управление у него куда прикольнее. А вон те не гордые, утаскивают ошметки даже и так. Что особенно забавно. А куда они денутся с подводной лодки? У них своих програмеров вообще ни на что нет уже. Ни на дрова, ни на ФС.
> Не задумывался почему и откуда растут ноги у ZoL?
- Почему ноги так пахнут?
- Потому что они из ж@пы растут!
Непонятно зачем так много файловых систем в линуксе. Почему бы не взять XFS и просто всем им не пользоваться? Его хватит для большинства а тем кому не хватит будут пользоваться чем нибудь другим.
Наверное большинство, всё-таки, как раз, тех, кому не хватило.
XFS вообще не упёрся, ибо scrub'а в нём нет. Так что никаких преимуществ в ней не наблюдается.
> XFS вообще не упёрся, вместе со скрабомИсправил, не благодари. Ext4 хватает для всего.
>> XFS вообще не упёрся, вместе со скрабом
> Исправил, не благодари. Ext4 хватает для всего.Да правильно, о том что носитель сыпался прикольнее узнать по факту в морду - когда нужное файло не прочлось. Заранее заметить надвигающуюся подставу по ору чексум в логи? Ну что вы, как можно.
Поэтому вон там btrfs'ник с нвидиея спалил что эта гадость память рушит. А некоторое количество кадров с XFS и EXT4 удивленно рассматривали разнесенные фс и вопрошали "как же так? что бы это могло быть?". Такая вот разница - системные подляны как на ладони.
Я бы с тобой согласился если бы скраб находил и исправлял ошибки в реальном времени. Вот только существующие решения нужно запускать либо вручную, либо по таймеру С ОПРЕДЕЛЁННОЙ ПЕРИОДИЧНОСТЬЮ, и может так случиться что в промежутке между проверками твоя фс как раз и навернётся. И плацебо в виде скраба тут никак тебе не поможет.
> Я бы с тобой согласился если бы скраб находил и исправлял ошибки
> в реальном времени.Чтобы рассуждать по теме - надо в ней немного разбираться. Чексумы проверяются и в реальном времени. Скраб - явный запрос пройти по ВСЕМ данным и метаданным и проверить их ВСЕ. И только.
При разрушениях оперативы и нестабильном железе - ор про ошибки чексум начинается довольно быстро и это как раз дает шанс что-то сделать ДО того как оно пробьет за чексуммы, например, подгадав момет и разрушив данные еще ДО обсчета чексумм. Так что если долго в таком режиме камикадзить - может и btrfs и сабж и что там еще помереть. Но реально - те кто читает системные логи обычно успевают засечь проблему ДО того как она эскалирует.
> Вот только существующие решения нужно запускать либо вручную,
> либо по таймеру С ОПРЕДЕЛЁННОЙ ПЕРИОДИЧНОСТЬЮ,Булшит бинго, чексумы чекаются и при обычном IO. И даже - если избыточность есть, с исправной копии еще и чинится. Само. В рантайме. Автоматически. Без участия человека вообще.
А вы можете дальше свои левые теории толкать. Только они никак не относятся к работе self heal в современных ФС. А XFS, вот, пока в этом аспекте где-то в ж.... :)
> Чексумы проверяются и в реальном времени.Вот именно что только проверяются, но не исправляются. Иначе не нужен был бы скраб.
При наличии избыточности -- чинятся.
>> Чексумы проверяются и в реальном времени.
> Вот именно что только проверяются, но не исправляются.Поразвелось тут "экспертов", не видевших технологию даже на картинке, зато имеющих ценное мнение!
[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 это вообще то что должно - умереть. Ибо лишний элемент интерьера.
Обычные юзеры логи не читают.
> Обычные юзеры логи не читают.Тогда они идут воооон туда в лабу и отваливают круглую сумму за вытаскивание данных, если они были нужны. Судьба у них такая. И тут уж каждый сам решает как он предпочитает. Можно заметить проблему на подлете. Можно заметить ее когда она даст по морде в виде когда игнорить это уже не получается. Выбор за пользаком :)
> Выбор за пользаком :)Так давно выбрали уже -- виндоуз.
>> Выбор за пользаком :)
> Так давно выбрали уже -- виндоуз.Ну так хомячкам и ось^W участь - хомячья. Кому и NTFS - фс. Хотя выбрали они на самом деле уже - андроидов и эплов. И это для майкрософта все большая и большая проблема.
Для IT-профи винда - неэффективная какаха с кучей подлян и мерзким вендором. Если вам такое надо - вы это и юзайте. Я это делать не буду. Мне вообще хочется увидеть в деле продвинутые системные технологии, и сабж в эту идею хорошо вписывается.
p.s. и да, нескольким вон тем пользакам я таки доставал файло с их нтфс. В том числе и после того как маздайки начали в BSOD летать на попытке монтирования тома. ЧСХ - прийти на другой комп с виндой не помогает: его тоже в бсод уносит. Стабильность признак мастерства - баги в ntfs.sys местами тянутся от винтукея до десятки как минимум.
Если бы эта речь была искренней, ты бы и 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
> Если бы эта речь была искренней, ты бы и ReFS поковырял,Я уже не имею дел с проприетарными технологиями. Чтобы не тратить время на ненужный мне мусор. Мои юзкейсы звязаны на опенсорсность и кроссовость софта, я этим пользуюсь. Технологии майкрософт отсеиваются уже на этом. К тому же после нехилого опыта партнерства с оными у меня нет причин доверять такому апстриму. Я видел как эти господа кидают транснациональные корпорации из верха фортуны-500. Как они относятся к пользакам - я догадываюсь.
> и VSS оценил, и мгновенный поиск за счёт MFT тоже, трезвее надо
> быть, и не преуменьшать любовь именно к линуксу.Я видел как VSS работает. И оценил. И именно поэтому люблю btrfs'овские снапшоты. Они не ставят колом систему, в отличие от, и скорости операций сильно более приличные.
Что до мгновенности, просто зайти в диру с 100К файлами на холодную на офигенном NTFS - вообще совсем не мгновенно, я проверял! Не, этот клин системы на 5 минут - точно не совпадает с моим понятием мгновенности. И когда 1 и тот же проект в лине билдуется в 2-3 раза быстрее, это тоже - аргумент. Linux сильно делает это недоразумение в файловых операциях. Позволяя ненапряжно ворочать иерархии с линухкернел размером. Я даже представить себе не возьмусь чтобы я ребилд такого размерв в винде затеял.
> Аналог VSS в линуксе в мейнлайн сначала автор dattobd предлагал[1], потом Veeam
> со свом blkshap[2], не берут-с. Ответ на предсказуемый вопрос: чтобы на
> незвездолётных ФС (как ext4) не иметь недостатков LVM-снапшотов (да, diff можно
> класть как файл прямо на свободное место в ФС).Это все прекрасно - но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная.
> но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная.Но надо! Надо считаться с тем, что половина пользователей ест ежей[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...
>> но сколько нсчастного ежа к ракете не привязывай, птица из него - довольно условная.
> Но надо! Надо считаться с тем, что половина пользователей ест ежей[1].Вам надо? Прекрасно, считайтесь. А я буду - за вон те технологии. Потому что мне намного больше нравится как это все организовано. И я полагаю что хочу видеть будущее технологий этого самого как-то так. А брейнфак с RAID и прочие сратисы - ну, я не буду обо всем этом скучать.
> [1] рандомные опросы, в которых ext4+xfs занимают около 50%
Я про всех этих васянов и опросы - слышу впервые, от вас. Предполагается что я посчитаю это все, вместе с какой-то их i++'й васян-ос на фиг знает каком форуме за нечто авторитетное?
А так про это Форд сказал что если бы он спросил что хотят его покупатели - они бы сказали что более быстрых лошадей. А я не хочу быть коннозаводчиком, я уже понял что можно - автомобили, конвейером. Такая фигня. Поэтому мне совершенно все равно что там какие-то васяны на каком-то форуме какой-то оси вещали.
> А я буду - за вон те технологии.Мы все знаем, под каждой новостью о ФС)
> слышу впервые, от вас
> Предполагается что я
> Поэтому мне совершенно все равно
> васяны
> васяновНу и самомнение. Я говорю, что не надо отрицать - ext4 и xfs пользуются. Аналог VSS бы всем пригодился изначально (лет 20 назад), когда btrfs не было. Но и сейчас многим тоже бы пригодился. Но не положено.
>> А я буду - за вон те технологии.
> Мы все знаем, под каждой новостью о ФС)Но вы кажется плохо представляете себе...
1) Откуда берутся новости.
2) Как разрабатывается софт и что за силы крутят шестеренки за сценой.> Ну и самомнение. Я говорю, что не надо отрицать - ext4 и xfs пользуются.
И фиг бы с ними. Даже FAT пользуются. И на лошадях иногда - ездят. Не обязывает меня быть активным фанатом FAT или уметь ездить верхом.
> Аналог VSS бы всем пригодился изначально (лет 20 назад),
> когда btrfs не было. Но и сейчас многим тоже бы пригодился. Но не положено.Лично мне этот плач несмеяны просто похрен. Сейчас можно и сильно получше чем это.
Годами живу с ext4, и не припомню, чтобы ФС посыпалась. А тут, оказывается, никак без некстген-фс с регулярным чтением лога.
> Годами живу с ext4, и не припомню, чтобы ФС посыпалась. А тут,
> оказывается, никак без некстген-фс с регулярным чтением лога.А вон там юзеры нвидии очень удивлялись когда fsck ext4 почему-то окончательно доломал им файлуху. Хотя до этого вроде все зашибись же было?! В принципе народ не понимал в чем прикол - пока какие-то btrfs'ники не заметили что ор появляется при вгрузке дров нвидии и пропалает если их снести.
Можно конечно и так. Да и как вы определяли что посыпалось без чексум? На глазок чтоли? Это надежный способ для терабайтов данных то :)
Не зря законы Мерфи говорят что если вам кажется что дела идут хорошо - вы просто чего-то не заметили.
> XFS вообще не упёрся, ибо scrub'а в нём нет. Так что никаких
> преимуществ в ней не наблюдается.Более того - его там героически пытаются сделать уже лет наверное 5. Или больше. Оно уже почти вот совсем готово, вот-вот, ых, ых, ых, years++.
> зачем так много файловых систем в линуксеЧтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал. Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄
> Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал.И слава богу) Тут местами такие "ыксперты" попадаются, что просто ужас.
> Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄
Пока ты размышляешь, он уже делает.
Если у тебя получится хотя бы минимально рабочая штука то выкладывай на всеобщее о̶б̶с̶ы̶р̶а̶н̶и̶е̶ обозрение.
Вдруг оно выйдет хорошим.
>> зачем так много файловых систем в линуксеBecause we can!(C)
Это то что сделало линакс грэёт энеён(С) Ж-)> Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас никто не слышал.
Ну в принипе - да, вполне может быть. Вот зачем взрослые мужики в хоккей играют? ;)
> Я тоже размышляю о создании файловой системы, используя все лучшие идеи из уже существующих. 🙄
Не-не-не - ты ни пуркуа не понял!
Because we can!(C) - это про них, а не про тебя :)
> Чтобы стать знаменитым, автора упоминают на всех крупных сайтах, а о нас
> никто не слышал. Я тоже размышляю о создании файловой системы, используя
> все лучшие идеи из уже существующих. 🙄Когда размышления трансформируются в архитектуру, структуры данных, а потом и код - тогда и приходи рассказывать нам об этом.
А если твой код еще и в майнлайн Linux возьмут, и он будет сравним по фичам с сабжем, я лично запилю новость про это, пожалуй. Так же как сделал это для Кента. Но придется убить несколько лет своего времени на это, путь от теории до практики в ФС нифига не близкий. Дашборд с "на 40% меньше багов" не даст соврать! Кент мог бы сказать "мой персональный ад на 40% прохладнее, фух" :)
Так это же древний анекдот!
- Знаешь, почему в Линуксе так много файловых систем?
- Нет.
- Потому, что не смогли сделать одну нормальную!
>Потому, что не смогли сделать одну нормальнуюКак не смогли? ZFS и ext4!
жаль, но zfs не в линуксе сделали
Ну нынешнюю - можно считать, в линуксе.В смысле - в окружении именно линуксном, а не в смысле в прожекте линукс под руководством одного пережившего свое время менеджера.
К той, сановской, она сейчас имеет очень опосредованное отношение. (и, разумеется, несовместима)
>>> ... не смогли сделать одну нормальную!
>> жаль, но zfs не в линуксе сделали
> Ну нынешнюю - можно считать, в линуксе.Да но и нормальной еЯ считать немножко перестали :)
Проклятье и благословения линукс, оно так и работает (обычно) :)
> Да но и нормальной еЯ считать немножко перестали :)
> Проклятье и благословения линукс, оно так и работает (обычно) :)Дедули, валите уже на завалинку истории вместе с вашей солярой. Ваше место - там. Особенно когда воооон тот гражданин советует заменить CRC32 -> Blake2b. То что он в 34 раза медленнее считается его вообще не смущает при продвижении инноваций.
> Дедули, валите уже на завалинку истории вместе с вашей солярой. Ваше место
> - там. Особенно когда воооон тот гражданин советует заменить CRC32 ->
> Blake2b. То что он в 34 раза медленнее считается его вообще
> не смущает при продвижении инноваций.Это в какой ФС советуют заменить?
>> Blake2b. То что он в 34 раза медленнее считается его вообще
>> не смущает при продвижении инноваций.
> Это в какой ФС советуют заменить?Это дедуля с ником _ настолько не умеет в инглиш и настолько самоуверен в своей правоте что попытался дать мне мастеркласс, да еще (лол!) закинув ссыль прямо на вику btrfs'а где по его мнению Blake2b якобы-шустрее немодного CRC32, насколько я понял его идею.
Идею запулить в меня прямо ссылью с опровержением сам себя я оценил. И даже перевел дедуле что там на самом деле написано, раз инглиш он знает не лучше чем ФС и алго. После этого эксперт с тезисом про немодность CRC32 куда-то тихо слился. А я не злопамятный, но злой, и на склероз не жалуюсь. И столь забавный пируэт экспертизы опеннета я забуду не скоро :)
Если хочется посмотреть на позорчик - он пытался :) умничать в https://www.opennet.me/openforum/vsluhforumID3/135159.html
Только на его горе я немного кодил и CRC32 и Blake2 и представляю соотношения вычислительной сложности оных. В этом месте у "эксперта" вышел небольшой фэйл :).
Мое персональное мнение: это то комьюнити которые мечущиеся между виндой и BSD заслужили. Вы теперь - ну вот это вот. Как хорошо что есть комьюнити и спецы получше ЭТОГО.
Тебе книшки писать прокурор!(С) :-)
Ну блин ... ну посмотри же ты в доке - что у современных ынтырпрайз стораджей там! :)
Хотя ... :)
> Ну блин ... ну посмотри же ты в доке - что у современных ынтырпрайз стораджей там! :)Дедуля, что ты ко мне с своими ынтырпрайзами и банками примотался? Похрен они мне! А к тебе вообще претензия что ты в 34 раза более тормозное алго посоветовал - всем вообще, с офигенным аргументом "CRC32 не модно, и вообще blake2 быстрее". А он нифига не быстрее, и я на твое горе шарю в алгоритмике достаточно, чтобы это знать.
А на энтерпрайзных файлопомойках - мир не заканчивается. И CPU и RAM в других юзкейсах - под ДРУГИЕ задачи нужны бывают. ZFSники никак не могут взять в толк столь простой момент! Кент мне интересен как раз тем что тоже - general purpose. Был бы он целиком про энтерпрайз файлопомойки, со свойствами как ZFS, мне было бы похрен что там с ним вообще.
> Хотя ... :)
Хотя... маневр с цитированием мне вики btrfs я оценил по достоинству :)
Не, ты тёплое с мягким не путай.
Та что в линуксе это OpenZFS.
А сановская ZFS продолжает жить и здравствовать в Solaris.
> Не, ты тёплое с мягким не путай.
> Та что в линуксе это OpenZFS.
> А сановская ZFS продолжает жить и здравствовать в Solaris.У вас довольно интересные понятия о жизни и здравствовании :)
> У вас довольно интересные понятия о жизни и здравствовании :)Ты суслика видишь? -- а он есть!
>> У вас довольно интересные понятия о жизни и здравствовании :)
> Ты суслика видишь? -- а он есть!Да сами и ешьте ваших сусликов. А себе я хочу - нормальный современный менеджмент оси. Без иррациональных брейнфаков на ровном месте.
Управдение сторажем в стиле btrfs/bcachefs - явно укладывается в эти пожелания. Когда можно просто добавить отфонарный девайс в RAID и не париться особо - это управление сторажем как оно должно было быть с самого начала. А вон то... я не буду скучать по этому брейнфаку. Совсем.
>>> У вас довольно интересные понятия о жизни и здравствовании :)
>> Ты суслика видишь? -- а он есть!
> Да сами и ешьте ваших сусликов. А себе я хочу - нормальный
> современный менеджмент оси. Без иррациональных брейнфаков на ровном месте.Так нормального ты не видел.
> Управдение сторажем в стиле btrfs/bcachefs - явно укладывается в эти пожелания. Когда
> можно просто добавить отфонарный девайс в RAID и не париться особо
> - это управление сторажем как оно должно было быть с самого
> начала. А вон то... я не буду скучать по этому брейнфаку.
> Совсем.У btrfs RAID 5/6 с рождения сломаны.
Чем ты там управлять собрался...
>> современный менеджмент оси. Без иррациональных брейнфаков на ровном месте.
> Так нормального ты не видел.Сейчас бы ZFSники/BSDшники с вечными тантрами, ритуалами и более 9000 сакрального знания и иррациональных ритуалов будут учить нормальному системному менеджменту. Щазззз! Вам самим мастеркласс обломился - при том от жизни. Когда все ваши BSD повылетели нахрен из прода, systemd дополнительно объяснил господам как хотели рулить сервисами. И брейнфакообразное управление сторажами - туда же отправится. По тем же причинам.
Компьютерные системы должны работать и обслуживать нужды человечества. А не делать, извиняюсь, мозги ненужным знанием, туповэйтингом и чем там еще.
> У btrfs RAID 5/6 с рождения сломаны.
> Чем ты там управлять собрался...Ну вот RAID1 например. Хотя RAID5 уже можно - если осторожно и понимать в чем catch. Да и в целом RAID5/6 - довольно специфичные штуки.
При том в btrfs можно реально подоткнуть любой девайс который был. Без этой вашей камасутры с парными девайсами, подбором размера или потерями места, и что там у вас еще за брейнфак. А рулить вон тем вон так - ну не, это уже - прошлый век.
>>> современный менеджмент оси. Без иррациональных брейнфаков на ровном месте.
>> Так нормального ты не видел.
> Сейчас бы ZFSники/BSDшники с вечными тантрами, ритуалами и более 9000 сакрального знания
> и иррациональных ритуалов будут учить нормальному системному менеджменту. Щазззз! Вам
> самим мастеркласс обломился - при том от жизни. Когда все ваши
> BSD повылетели нахрен из прода, systemd дополнительно объяснил господам как хотели
> рулить сервисами. И брейнфакообразное управление сторажами - туда же отправится. По
> тем же причинам.Сейчас бы локалхостеры не рассказывали нам за системный менеджмент.
> Компьютерные системы должны работать и обслуживать нужды человечества. А не делать, извиняюсь,
> мозги ненужным знанием, туповэйтингом и чем там еще.Ненужного знания не бывает.
>> У btrfs RAID 5/6 с рождения сломаны.
>> Чем ты там управлять собрался...
> Ну вот RAID1 например. Хотя RAID5 уже можно - если осторожно и
> понимать в чем catch. Да и в целом RAID5/6 - довольно
> специфичные штуки.
> При том в btrfs можно реально подоткнуть любой девайс который был. Без
> этой вашей камасутры с парными девайсами, подбором размера или потерями места,
> и что там у вас еще за брейнфак. А рулить вон
> тем вон так - ну не, это уже - прошлый век.В RAID1 и в ZFS можно любой девайс вокнуть.
> Сейчас бы локалхостеры не рассказывали нам за системный менеджмент.Сейчас бы сбитым летчикам aka "классическим" *BSD/*nix админам да за локалхосты. Локалхосты теперь - они и их практики.
А я как раз умею в продвинутые современные технологии, системда, виртуализация, генерация системных образов под задачи. И "локалхостов" у меня уже изрядно.
И это как раз мотивирует чтобы..
1) Менеджмент был простым, логичным и ненапряжным. И райдов, и сервисов, и вообще - всего.
2) Системы умели в self repair единичных upsets без участия человека.
3) Была нормальная диагностируемость, а не как в окаменелом д@рьме без чексум.
4) Времена деплоя и рекавери должны быть минимальные.Это все не про тех с иррациональными ритуалами марки "мы так привыкли".
> Ненужного знания не бывает.
Этот мир большой и сложный, все знания невозможно вместить в 1 голову. Поэтому приходится агрессивно оптимизировать что и почему изучать.
Будем честны, мне не пригодятся знания о разведении лошадей или починке тележных колес кувалдой. Поэтому лучше вгрузить какие-то более актуальные и полезные знания вместо этого.
> В RAID1 и в ZFS можно любой девайс вокнуть.
Только результат насколько я понимаю - другой. И вообще менеджмент в целом - ну, вон там архитект думал как сделать менеджмент простым и логичным. А вон те развели стандартную энтерпрайз канитель с неудобными допущениями и ритуалами. Этим prev и next gen технологий и отличаются, в next стараются устранить факапы prev. gen. Сабж целиком про это. Поэтому имеет некий пойнт. Чисто технически, как дизайн.
>> Сейчас бы локалхостеры не рассказывали нам за системный менеджмент.
> Сейчас бы сбитым летчикам aka "классическим" *BSD/*nix админам да за локалхосты. Локалхосты
> теперь - они и их практики.
> А я как раз умею в продвинутые современные технологии, системда, виртуализация, генерация
> системных образов под задачи. И "локалхостов" у меня уже изрядно.Ты изрядно отстал от современных технологий.
> И это как раз мотивирует чтобы..
> 1) Менеджмент был простым, логичным и ненапряжным. И райдов, и сервисов, и
> вообще - всего.
> 2) Системы умели в self repair единичных upsets без участия человека.
> 3) Была нормальная диагностируемость, а не как в окаменелом д@рьме без чексум.В ZFS есть и self repair и чексумы
И менеджмент куда проще возни с btrfs.
> 4) Времена деплоя и рекавери должны быть минимальные.
> Это все не про тех с иррациональными ритуалами марки "мы так привыкли".
>> Ненужного знания не бывает.
> Этот мир большой и сложный, все знания невозможно вместить в 1 голову.
> Поэтому приходится агрессивно оптимизировать что и почему изучать.
> Будем честны, мне не пригодятся знания о разведении лошадей или починке тележных
> колес кувалдой. Поэтому лучше вгрузить какие-то более актуальные и полезные знания
> вместо этого.А вот не факт что тебе это не пригодится.
>> В RAID1 и в ZFS можно любой девайс вокнуть.
> Только результат насколько я понимаю - другой. И вообще менеджмент в целом
> - ну, вон там архитект думал как сделать менеджмент простым и
> логичным. А вон те развели стандартную энтерпрайз канитель с неудобными допущениями
> и ритуалами. Этим prev и next gen технологий и отличаются, в
> next стараются устранить факапы prev. gen. Сабж целиком про это. Поэтому
> имеет некий пойнт. Чисто технически, как дизайн.Так ты не пользовался ZFS, откуда тебе знать результат.
И в дизайне ФС ты профан.
> Ты изрядно отстал от современных технологий.Вы с вашими парадигмами вообще - сбитые летчики. Слушать таких "профи" на тему как надо было - себя не уважать. Сорян но я попробую другие вещи, посмотреть не получится ли лучше.
Мои технологии как раз эффективны. Их хайповость и пафосность - второй вопрос. Чисто технически я не спасую зарубиться с кем угодно по времен операций и результату. А то что я не энтерпрайз и повернут на кастоме - и что? Это не делает все это "отсталым". Особенно учитывая что многое из этого - мелочевка, а не ваши энтерпрайз-помойки с завалами корпоративного булшита, который мне - отвратителен.
> В ZFS есть и self repair и чексумы
В ней ни безгеморной эксплуатации (внемайнлайновый выкидыш), ни эффективных структур, без сотен рамы тормоз, ни нормального управления. Первый блин - комом. А судя по истории с рефлинками в ZoL, управление релизами - не лучше.
> И менеджмент куда проще возни с btrfs.
Вон там сэр уже рассказал как оно с RAID. Ну вас таких простых нахрен, я буду за "device add <whatever>" -> +N места, как в btrfs и сабже. Правильное руление фс и райдом - это так, имхо.
> А вот не факт что тебе это не пригодится.
В пиковом случае допустим "своп" ака подгрузка знания "as needed". Это такая оптимизация, в моей голове сидит довольно много довольно сложных технологических стеков в интересных мне направлениях. Это то что и позволяет мне обставлять господ типа вас в определенных номинациях. Я сомневаюсь что вы сможете конкурировать со мной на моих полях. В этом и пойнт, не хочу быть легкозаменимым корп винтиком, которого толи AI вынесет, толи дешевый индус.
> Так ты не пользовался ZFS, откуда тебе знать результат.
Я так, смотрел краем глаза, ну и вон там аноним - с RAID подтвердил мои идеи, какое там управление. И именно от такого я и хочу уйти в "device add" -> +N места. Даже в RAID. Это круто, хорошо и правильно.
> И в дизайне ФС ты профан.
А таки я посмотрел на то как разные ФС устроены - и почему так. И составил свое мнение о работе архитектов. В ZFS вообще половина мест "почему так" - "мы так привыкли". Будем считать что я не фанат такого rationale в архитектурах. Предпочитаю более понятные мне решения, которые облегчают мою жизню.
> И именно от такого я и хочу уйти в "device add" -> +N местаВсё продолжаешь сказки рассказывать, сказочник? :) Ну давай, собери raid1 из 2-х дисков по 10 ГБ, потом добавь к ним ещё один на 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо?
>Ну давай, собери raid1 из 2-х дисков по 10 ГБ, потом добавь к ним ещё один на 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ ))Можно, именно увеличить так объем.Но данные на 20 Гб понятно дело будет не отказоустойчивы.Это даже на офтопике можно сделать на некоторых хитрых Raid контроллерах (//в основном Intel ).Там даже одно время запатентовали 2-е гибридные диски _ часть диска в raid1 а другая часть в raid0 .
Другое дело как правильно организовать данные,что и к чему присоединять ,вот вопрос, все таки очень не простая проблемная конфигурация.
Ага, а можно просто примонтировать новый диск в какую-нибудь папку и получить +полную ёмкость диска, только речь не об этом и не о преобразовании в 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 ГБ" тем более речи не может идти.
> Можно, именно увеличить так объем.Но данные на 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.
Всё, сдаюсь! Ты меня добил, на этот раз окончательно. Прямо-таки обескуражил. И должен признаться, виноват в этом я сам, т.к. я стал жертвой собственного воображения. Поддавшись твоим восторженным эпитетам в адрес БТРФС и рассказам об "ассиметричной аллокации", я убедил себя что приводимое тобою значение "+N" означает увеличение расширяемого массива на величину, равную полной ёмкости добавляемого диска ))) Теперь я понимаю, что это твоё "+N" означает всего-навсего "энную", или говоря по-русски -- некоторую величину. В свете этого мои пассажи про смешанные "зеркально-линейные" массивы выглядят не более чем забавным анекдотом )) Но в таком случае не очень понятно чем ты вообще гордишься. Тем что в БТРФС в принципе можно добавить диск или расширить массив? Так с mdadm и LVM при добавлении диска доступный объём тоже вроде увеличивается, а не уменьшается... Или тем что эту операцию можно проделать одной командой? Ну да, можно, только я сомневаюсь что это для кого-то может иметь значение. Или ты гордишься тем, что БТРФС умеет в raid 1Е? Но и mdadm умеет создавать массивы по такой схеме... К тому же я ведь тебе уже объяснял, что эта схема не только теряет всякий смысл при колличестве дисков более 3-х, но и с 3-мя дисками большинство предпочтёт собрать raid5 и выиграть лишнее пространство. Ты сам-то никогда не задумывался на тем, почему raid 1E сегодня практически нигде не используется? Да просто потому что он никому не нужен! )) И что остаётся? Остаётся только то, что БТРФС умеет это всё вместе: и расширять массив (чего пока не умеет ZFS, но умеет mdadm и lvm), и создавать массивы типа raid 1E (которые никому не нужны), и при этом делать это с помощью одной команды (сомнительное преимущество, которое может быть нивелировано в каких-то других моментах). И тут бы порадоваться за БТРФС, если бы она только на втором десятке лет жизни не была такой сырой и глючной ))) Подумать только: за почти 20 лет так и не двести до ума raid5/6 -- одну из важнейших функций данной файловой системы! И какой тогда толк от всех этих чудес, если часть из них никому не нужна, часть можно реализовать и с помощью других инструментов, а оставшиеся работают только на бумаге?
> диска ))) Теперь я понимаю, что это твоё "+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. У него чуть круче ибо скрещено с кешом/фронтэндом/бэкэндом. Прикольная идея, при создании реплик свойства стоража еще учесть.
> но как вы понимаете, при "динамической" аллокации места и сильном дисбалансе возможны варианты.Не, там без вариантов. Я в ходе своих экспериментов даже формулу открыл, по которой максимальный полезный объём диска в массиве "raid1" (в понятиях btrfs) равен суммарной ёмкости всех остальных дисков ))
> Это иначе сделано. И не совсем RAID1 - в блочном его понимании
Так это очевидно что это не raid1, я если помнишь сразу так и сказал что это raid1 1E (или его разновидность), а не raid1. Будь это raid1, у тебя ёмкость массива была бы равна ёмкости одного диска при любом количестве дисков.
> Удобным простым и логичным управлением этой штукой, в виде как это и должно быть. Что с RAID, что без. Просто увеличить. Просто убавить. Можно девайс добавить. И вынуть.
Удобно, спору нет.
> Значение для меня имеет общее сочетание - что тупых потерь "из за размера девайсов" нет или минимум возможных, и все просто и логично рулится.
Так и с LVM нет никаких потерь (подозреваю что и на ZFS тоже), и тоже всё просто и логично рулится.
> Можно в рантайм переиграть все параметры, жестко и мягко, вплоть до смены схемы хранения.
А вот это уже сомнительное достоинство, ибо такие фокусы чреваты потерей данных, особенно в случае с btrfs.
> RAID5 довольно специфичная штука
Не более специфичная чем RAID 1E
> а с учетом роста емкости девайсов и ненулвеого BER это еще и довольно сыкотное комбо
С учётом того, что значения BER производители дисков берут с потолка, а у ZFS к тому же есть такая штука как draid (правда на 3-х дисках его не собрать), страхи относительно ненадёжности RAID5 сильно преувеличены.
> Ибо что делать если "копии не сошлись"?
А что btrfs делает в таких случаях?
> Всё продолжаешь сказки рассказывать, сказочник? :) Ну давай, собери raid1 из 2-х
> дисков по 10 ГБ, потом добавь к ним ещё один на
> 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо?У вас с математикой хреново. Из (10+10+20) при 2 копиях никак не получится 30 гигз. Но демо незнания математики продемонстрировано отлично.
А на 20 таки получится. RAID1 в общем случае ополовинивает место из-за того что копий 2. Только у классической версии еще дурацкости с потерями места на разных девайсах, нуждой непременно четного количества девайсов и прочего характерного булшита в уровне менеджмента. Это и дает место дизайнам типа btrfs и сабжа, которые дадут мастеркласс фекальям мамонта как надо было.
>[оверквотинг удален]
>> дисков по 10 ГБ, потом добавь к ним ещё один на
>> 20 ГБ, и продемонстрируй нам получившиеся 30 ГБ )) Слабо?
> У вас с математикой хреново. Из (10+10+20) при 2 копиях никак не
> получится 30 гигз. Но демо незнания математики продемонстрировано отлично.
> А на 20 таки получится. RAID1 в общем случае ополовинивает место из-за
> того что копий 2. Только у классической версии еще дурацкости с
> потерями места на разных девайсах, нуждой непременно четного количества девайсов и
> прочего характерного булшита в уровне менеджмента. Это и дает место дизайнам
> типа btrfs и сабжа, которые дадут мастеркласс фекальям мамонта как надо
> было.У тебя с математикой тоже туго.
Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных.ЗЫ:
И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов?
> У тебя с математикой тоже туго.
> Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных.Btrfs таки - запишет. "В среднем" будут копии на 20 + 50/50 на 10-х в пару им. Реально это ессно гибкая динамическая аллокация места RAID на дисках, оно работает и для других соотношений. В отличие от вашего брейнфака с мапингом 1:1! Я вон там показал, прям с командами - на такое комбо реально втолкалось около 20 гиг, ибо я предпочитаю не тестировать безглючность показометров а фактически затестить полученное.
> ЗЫ:
> И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов?Смотря что понимать под "непременно" и "требуется". В degraded то режиме он и с 1 диском зацепится, только это уже не RAID1 как таковой будет.
>> У тебя с математикой тоже туго.
>> Куда в схеме RAID1(10+10+20) ты будешь писать копии 11+ гигабайта данных.
> Btrfs таки - запишет. "В среднем" будут копии на 20 + 50/50
> на 10-х в пару им. Реально это ессно гибкая динамическая аллокация
> места RAID на дисках, оно работает и для других соотношений. В
> отличие от вашего брейнфака с мапингом 1:1! Я вон там показал,
> прям с командами - на такое комбо реально втолкалось около 20
> гиг, ибо я предпочитаю не тестировать безглючность показометров а фактически затестить
> полученное.Аха, запишет.
А после записи твой диск на 20 вдруг сдох -- все данные на нем выше 10 гиг идут в нирвану, копий то нету на других членах это недореид1.>> ЗЫ:
>> И расскажи нам в какой реализации RAID1 непременно требуется чётное количество девайсов?
> Смотря что понимать под "непременно" и "требуется". В degraded то режиме он
> и с 1 диском зацепится, только это уже не RAID1 как
> таковой будет.Ну т.е. ты снова нагазовал.
>[оверквотинг удален]
> Я так, смотрел краем глаза, ну и вон там аноним - с
> RAID подтвердил мои идеи, какое там управление. И именно от такого
> я и хочу уйти в "device add" -> +N места. Даже
> в RAID. Это круто, хорошо и правильно.
>> И в дизайне ФС ты профан.
> А таки я посмотрел на то как разные ФС устроены - и
> почему так. И составил свое мнение о работе архитектов. В ZFS
> вообще половина мест "почему так" - "мы так привыкли". Будем считать
> что я не фанат такого rationale в архитектурах. Предпочитаю более понятные
> мне решения, которые облегчают мою жизню.Сколь на картину не смотри, коль ты профан в искусстве -- ты ничего там не увидишь.
>> что я не фанат такого rationale в архитектурах. Предпочитаю более понятные
>> мне решения, которые облегчают мою жизню.
> Сколь на картину не смотри, коль ты профан в искусстве -- ты
> ничего там не увидишь.Самокритика - это хорошо. Ибо от вас я вообще никогда не видел ни малейшего понимания как работает всякая системщина и алгоритмика, чисто потребительский апломб с попытками примазаться к тому к чему вы никакого отношения не имеете.
Да и вообще, таланты и что ваше сообщество может - было отлично показано на примерах релиза с профачеными рефлинками. Это то что хайпожоры типа вас из себя реально представляют. Пафоса много, дела чуть. Не люблю когда наобещали больше чем по факту могли, для ФС это хреново.
>>> что я не фанат такого rationale в архитектурах. Предпочитаю более понятные
>>> мне решения, которые облегчают мою жизню.
>> Сколь на картину не смотри, коль ты профан в искусстве -- ты
>> ничего там не увидишь.
> Самокритика - это хорошо. Ибо от вас я вообще никогда не видел
> ни малейшего понимания как работает всякая системщина и алгоритмика, чисто потребительский
> апломб с попытками примазаться к тому к чему вы никакого отношения
> не имеете.Это у тебя нету понимания даже того что такое RAID1.
А об устройстве ZFS и подавно.> Да и вообще, таланты и что ваше сообщество может - было отлично
> показано на примерах релиза с профачеными рефлинками. Это то что хайпожоры
> типа вас из себя реально представляют. Пафоса много, дела чуть. Не
> люблю когда наобещали больше чем по факту могли, для ФС это
> хреново.Что-то я не видел тут ссылок на твой гитхаб с патчами btrfs о которых ты тут вещал.
Специалист ты наш...
нам нормально.
> жаль, но zfs не в линуксе сделалиДа и нормальной эту архаичную груду костылей можно назвать лишь с большой натяжкой.
>> жаль, но zfs не в линуксе сделали
> Да и нормальной эту архаичную груду костылей можно назвать лишь с большой натяжкой.По управлению схемами хранения и месту - дико сливает и сабжу и btrfs. И снапшоты какие-то дурацкие. И управление памятью дурное. А заодно еще и внемайнлайновый выкидыш - у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа!
Да там при ближайшем рассмотрении вообще всё оказывается через одно место сделанным. Например чтобы заставить ZFS монтировать датасеты в правильном поядке нужно задействовать специальную, прикрученную изолентой службу zfs-mount, иначе фс будет монтировать их в соответствии с их именами, а не точками монтирования (!). Или вот ещё какой прикол обнаружил: https://i.postimg.cc/26frGVd5/Screenshot-2024-10-17-17-53-42... Т.е. автоматическая подмена вышедших из строя дисков работает только применительно к тому vdev, на котором расположены данные, но не работает в отношении к vdev, на котором расположены, скажем, метаданные, при том что для таких устройств в руководстве даже отдельно оговорено что они должны иметь избыточность равную избыточности основного массива. Т.е. избыточность их беспокоит, а выход из строя дисков не беспокоит )) Там значит система сама подкинет spare диск, а тут сиди и глазами следи. Шизики! Или уже набившая оскомину невозможность расширения raidz массивов... Как объединять диски в масиивы они придумали, а как потом эти массивы расширять они не придумали... И у кого-то ещё поворачивается язык нахваливать эту ФС, приписывая ей какаие-то невообразимые свойства, а их создателей гордо именуя Инженерами с большой буквы :)
> Да там при ближайшем рассмотрении вообще всё оказывается через одно место сделанным.
> Например чтобы заставить ZFS монтировать датасеты в правильном поядке нужно задействовать
> специальную, прикрученную изолентой службу zfs-mount,У ZFS вообще очень странные понятия о менеджменте. Вон там в советах какие-то дикие тантры с экспортом, импортом, еще черти чем. Был бы btrfs какой - просто зацепили бы пул к другой машине и дело с концом. Без вот этого всего. ИМХО Кент был прав сдирая принципы менеджмента - вот оттуда. Vdev оно конечно не умеет - да и зачем? Там фича в простом менеджменте а не в том чтобы фигурно и концептуально по@#$ться неизвестно зачем. Ну саням то понятно зачем оно - у них вообще без этого RAIDов в оси не было, тут уж нравится, не нравится а что-то придумать придется.
Вот не нужно гнать на солярис: был там софтверный райд (через metainit), был и аппаратный.
> Вот не нужно гнать на солярис: был там софтверный райд (через metainit), был и аппаратный.Оно все же ни в какое сравнение с тем что можно md+dm+lvm изобразить. Но вот менеджмент таких конструкций - это боль.
И именно это дало новое дыхание "интеграшкам". Когда архитект Крис Мэйсон осознал что управление сторажем с несколькими девайсами - вовсе не обязано быть тем жестким брейнфаком, если парадигмы аллокации немного пересмотреть. Это и есть - прогресс. Это навсегда войдет в историю технологий хранения, и новые дизайны будут пытаться усовершенствовать идею - потому что делом показано что так можно было. И Кент тоже - вот - проникся.
> у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа!Шо, прям убил? Он его в окно от расстройства выбросил что ли?
>> у меня знакомый комп убил так, кернел апгрейднул - рутфс не взлетел - опа, опа!
> Шо, прям убил? Он его в окно от расстройства выбросил что ли?Нет, он просто занятый человек - и у него не было времени отношаться с столь дурацкой проблемой, которая не очень просто чинится если система не бутабельна вообще.
Я то прошареный, у меня grub и он даже и кернел в случае чего-то этакого может из снапшота читануть, так то оно ессно взлетит - хоть и с мануальным пилотированием слегка (указать правильнй рутфс, etc). Так и бутлоадер - средство отката снапшотов.
> Нет, он просто занятый человек - и у него не было времени отношаться с столь дурацкой проблемой, которая не очень просто чинится если система не бутабельна вообще.Странно, что настолько занятой человек добрался до zfs.
Я вот тоже занятой — я просто гружу предыдущее ядро и не страдаю.
> Странно, что настолько занятой человек добрался до zfs.Было время - добрался. Но ФС с снапшотами по задумке должна была облегчать восстановление системы - а не привносить новые, блин факапы с ней. И за это тот чел отругавшись свалил на btrfs, угумс.
> Я вот тоже занятой — я просто гружу предыдущее ядро и не страдаю.
Ну мало ли, может он сэкономил, вот, на инсталле бутлоадера где можно выбрать. Какойнить EFI на минималках линухкернел может вообще сам пнуть. В любом случае - внемайнлайновость это всегда заявка на неприятные сюрпризы такого рода. Кому как а мне нафиг надо рутфс который может не подцепиться. А вот снапшоты на нем - весьма полезны для парирования системных факапов как раз.
> Ну мало ли, может он сэкономил, вот, на инсталле бутлоадера где можно выбрать.т.е. какой-то ССЗБ из вашего рассказа получается. Сначала навертел чего-то странного, потом не справился с последствиями. А ругался на zfs
> т.е. какой-то ССЗБ из вашего рассказа получается.Этот ССЗБ так то живет - сильно получше вашего. И должность у него - сильно покруче того что вам даже чисто теоретически светит.
И я думаю что умение признавать ошибки - и переигрывать решения, если туго идет - очень помогло ему стать именно таким.
> Сначала навертел чего-то странного, потом не справился с последствиями. А ругался на zfs
Ну он и справился - реинстальнув btrfs. Который так не отваливается. Дешево и сердито. А вы там преодолевайте искусственные трудности во имя луны, если оно вам зачем-то надо.
> Этот ССЗБ так то живет - сильно получше вашего. И должность у него - сильно покруче того что вам даже чисто теоретически светит.ну, если бы у меня все было настолько сильно в шоколаде, то пожалуй я бы нанял себе админа — дешевле будет
> И я думаю что умение признавать ошибки - и переигрывать решения, если туго идет - очень помогло ему стать именно таким.
было время — поставил zfs, не стало времени — узнал, что не знает, чего ожидать. Это какие-то метания, а не переигрывание. Человек с должностью "сильно покруче" должен уметь оценить свои силы (и не только свои) и принимать взвешенные решения.
> А вы там преодолевайте искусственные трудности во имя луны, если оно вам зачем-то надо.
так я не про трудности, просто история интересная. Она вообще выглядит так, будто кто-то налил человеку в голову "маркетинга", расписав светлое будущее и забыв упомянуть проблемы. А потом еще про btrfs налили.
Больше не могу придумать, что было бы в голове занятого человека на высокой должности, что он решил пойти походить по граблям, при том, что эти грабли везде обсуждают
> ну, если бы у меня все было настолько сильно в шоколаде, то
> пожалуй я бы нанял себе админа — дешевле будетПускать стороннего админа на свой ПЕРСОНАЛЬНЫЙ комп/ноут?! Я такой фигни даже у сверхжирных топов от айти с персональными джетами не встречал. Это очень спорная идея, ибо Evil Maiden attack, и вообще ну нахрен, имхо.
> было время — поставил zfs, не стало времени — узнал, что не
> знает, чего ожидать. Это какие-то метания, а не переигрывание.Переигрывание - перейти на btrfs ;). Дабы более на такие приколы не нарываться в принципе.
> Человек с должностью "сильно покруче" должен уметь оценить свои силы (и не только
> свои) и принимать взвешенные решения.Не бывает людей которые вообще не ошибаются. Зато бывают те которые легко и быстро исправляют свои факапы, минимизируя урон. И если вопрос встал ребром то могут отманеврировать. За что их экспертизу и ценят.
Но я лично вообще не думаю что вы всерьез видели менеджмент нормальных западных мегакорп чтобы с вами про их менеджмент имело смысл разговаривать.
> так я не про трудности, просто история интересная. Она вообще выглядит так,
> будто кто-то налил человеку в голову "маркетинга", расписав светлое будущее и
> забыв упомянуть проблемы.Это примерно так и происходит - в том числе и на опеннете. ZFSники явно занимаются over-advertise, и даунплеем проблем и особенностей. Это выходит боком их репутации, когда случается вот что-то такое.
> А потом еще про btrfs налили. Больше не могу придумать, что было бы в голове
> занятого человека на высокой должности, что он решил пойти походить по граблям, при том,
> что эти грабли везде обсуждаютBtrfs никаких особых грабель лично мне не подкладывал. Более того - именно этому типу я в случае чего подскажу и что делать, и где с адекватными btrfs'никами обсудить. Это вообще мой друг, и познакомились мы на почве линуха. Я ж сказал - при интересе к линуху можно отхватить множество интересных знакомств с мощными людьми по всему глобусу. И это круто.
> Как не смогли? ZFS и ext4!
> ZFSЕё уже научили отключать CoW и расширять массивы?
>> Как не смогли? ZFS и ext4!
>> ZFS
> Её уже научили отключать CoW и расширять массивы?Ее научили в рефлинки. Првда, натягивали сову на глобус i++ лет, а потом - тестировать фичу решили - прямо на юзерях! Активировав по дефолту. Казалось бы, что может пойти не так?! И тут гентушники такие, перекомпилявшие игого - хлобысь! Затестили минное поле ударным забегом по нему. Так тоже можно, конечно...
только минное поле оказалось не связано не с рефлинками
> только минное поле оказалось не связано не с рефлинкамиДа, его разложили еще супер-правильные господа из саней ажно. А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло. А кроме везения - надо было бошкой думать до того как активировать по дефолту, всем, совсем не тестированую фичу. Хотя думать надо было на тему - зачем вообще релизить нетестированый шит, для начала. Может, сперва ФС надо тестировать а потом - релизить? Наоборот - фигня получается.
> А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло.оно сработало, когда вышли новые coreutils, так что да, рефлинкам просто не повезло
> А кроме везения - надо было бошкой думать до того как активировать по дефолту, всем, совсем не тестированую фичу.
или тестированную на недостаточно новом наборе софта — не всем дано быть гентушниками.
Кстати, а когда в coreutils дефолт для рефлинков меняли они чем думали и как тестировали?> Хотя думать надо было на тему - зачем вообще релизить нетестированый шит, для начала
Перестаньте платить им деньги, это лучшее стимулировние…
Если бы Линус и компания не релизили нетестированный шит, то я бы до сих пор сидел без видеодрайвера — оно все еще периодически падает и вешает систему.Кстати, насколько помню, чтобы новые "фичи" заработали надо выполнять zfs upgrade, что само по себе не происходит. Так что совсем "по дефолту" оно было выключено
>> А то что оно сработало только когда эти, с рефлинками пришли - ну, им не повезло.
> оно сработало, когда вышли новые coreutils, так что да, рефлинкам просто не повезлоЭти кореутилсы "виноваты" - только тем что удумали по дефолту юзать фичи ФС, если уж они вывешены. И только.
Как именно user-mode программа может быть "виновата" в том что кернел вообще и ФС в частности творит фигню при использовании фич ФС - оставим на совести "экспертов" от ZFS. Заодно спасибо за эпический хайлайт уровня. Вы не понимаете как работает ОС, ФС, и софт, но пытаетесь продвигать ценное мнение. За это я и не жалую такие комьюнити.
> или тестированную на недостаточно новом наборе софта — не всем дано быть гентушниками.
Это не извиняет релиз кривой ФС, сыпящейся при легитимных операциях, доступных в дефолтной конфиге. Специальный перк - если до этого активно напирали на integrity данных.
> Кстати, а когда в coreutils дефолт для рефлинков меняли они чем думали и как тестировали?
В майнлайновых ФС рефлинки нормально работают. А якорить whole shebang нагибая эффективность системных операций ради внеядерных выкидышей - зачем? Пусть сами и...тся как хотят. Если у них релизеры ламо, это их проблемы.
> Перестаньте платить им деньги, это лучшее стимулировние…
Ну я и не плачу ZFSникам нихрена. И все мои технологии сейчас - в основном вокруг btrfs. Но, может быть, со временем что-то и с сабжем будет. Это зависит от Кента.
> Если бы Линус и компания не релизили нетестированный шит, то я бы
> до сих пор сидел без видеодрайвера — оно все еще периодически
> падает и вешает систему.А у меня вот - стабильно как скала. Но, может, секрет в том что я таки - пришел и помог зарубить пару багов? Да, так в опенсорсе можно было :). И теперь баги - у вас. А у меня - все прекрасно. Меня такой расклад - вполне устраивает.
> Кстати, насколько помню, чтобы новые "фичи" заработали надо выполнять zfs upgrade, что
> само по себе не происходит. Так что совсем "по дефолту" оно было выключеноЭто видимо на pre-existing конфигах. А на новых - как я понимаю оно сразу "мордой о порог". И вот тут к господам релизерам ТАКОГО, разводившим маркетинговый булшит на тему стабильности и интегрити данных сразу довольно много интересных вопросов появляется.
Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниями. По моему - никак не стыкуются, и это толпа рас314-ев, а не релизеры, уж простите за мой французский.
> Эти кореутилсы "виноваты" - только тем что удумали по дефолту юзать фичи ФС, если уж они вывешены. И только.это не корутилсы виноваты. Мне просто не нравится, что обвиняют рефлинки, хотя это не они.
В остальном, кроме "виноватых", есть еще и осознанный выбор пользователей, используют ли они окаменевший дебиан или острие прогресса в виде арчей и прочего> Это не извиняет релиз кривой ФС, сыпящейся при легитимных операциях, доступных в дефолтной конфиге.
А веселые релизы btrfs и, теперь, bcachefs мы так уж и быть простим? Вообще странная позиция про извиняет/не извиняет, если в каждой софтине прописан отказ от гарантий, претензий и прочего
> В майнлайновых ФС рефлинки нормально работают.
ну, как и в zfs
> Ну я и не плачу ZFSникам нихрена
но хочу обширного тестирования на бесконечном количестве произвольных конфигураций
> И все мои технологии сейчас - в основном вокруг btrfs
им хоть платите? Чтобы не тестировали на живых людях
> А у меня вот - стабильно как скала. Но, может, секрет в том что я таки - пришел и помог зарубить пару багов? Да, так в опенсорсе можно было :). И теперь баги - у вас. А у меня - все прекрасно. Меня такой расклад - вполне устраивает.
А как же ваша позиция, что трудности тестирования не извиняет релизы кривых проектов? Почему одиним проектам вы помогаете, а другие упрекаете в недостаточном тестировании?
В принципе тут не озвучивалось, но в zfs вы баги открывали? Если да, то мои вопросы не в тему.
А проблема с драйвером касалась не только меня и грамотные багрепорты уже были (потому что когда багрепорты заводили я был еще со старым ядром и рабочим драйвером).
> Это видимо на pre-existing конфигах. А на новых - как я понимаю оно сразу "мордой о порог"тут соглашусь, с новыми гентушниками получилось не очень. Но благодаря их страданиям в дебиане будет более-менее отлаженный
> Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниям
вы еще верите обещаниям разработчиков?
> это не корутилсы виноваты. Мне просто не нравится, что обвиняют рефлинки, хотя это не они.А мне не нравятся - рас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ским релизом - да чур меня, или как слить репутацию в моих глазах ниже Кента. Этот в отличие от - таки накодил ребилд снесенных метаданных, держит марку!
>> Например на тему как их практики релизов стыкуются с щедро выдаваемыми обещаниям
> вы еще верите обещаниям разработчиков?Даже Кент свои обещяния - выполняет. А те и вовсе - будучи опытными не дают нереалистичных обещаний. И да, я хочу получать объективные данные о свойствах дизайна, а не булшит от фанатов. Зачем мне залеты от неверного планирования?!
Ну если btrfs'ники не стесняются выпускать некондицию и тестировать свою поделку на юзерах, то почему разрабы zfs не могут делать так же? Чем они хуже?
- Потому, что файлов много!
Когда в XFS завезут коровы, чексуммы, сжатие, дедупликацию, скраб, собвольюмы - тогда может быть.
дык сделали уже, и первую буковку с X на Z заменили.
Сколько буковки не меняй, но в ядро этот раздутый комбайн не попадет никогда. Лицензию надо менять, а не буковки.
> Лицензию надо менятьИ дизайн.
>> Лицензию надо менять
> И дизайн.Начиная с управлением памятью, местом, заменой ископаемых околоблочных структур, ... и - что останется то? А, ну вот если нормально сделать - что-то типа сабжа и подучится. Только нахрен вам тогда старое название? Сами по себе три буковки никакого волшебства сами по себе не гарантируют :)
> Начиная с управлением памятью, местом
> местомОй, кому кому, но только не фанатикам btrfs заикаться об управлении местом ))) До таких курьёзов как невозможность удаления файлов по причине отсутствия свободного места zfs бесконечно далеко. Что касается сабжа, то его вообще обсуждать бессмысленно, ибо он вообще ещё никем и нигде не используется. И неизвестно когда начнёт.
> Ой, кому кому, но только не фанатикам btrfs заикаться об управлении местом
> ))) До таких курьёзов как невозможность удаления файлов по причине отсутствия
> свободного места zfs бесконечно далеко.В ZFS просто какой-то кривой и странный менеджмент. Никакие докапывания до частностей не поставят этот брейфак в 1 ряд - с вон тем. В btrfs можно просто добавить или вынуть девайс, даже в RAID'е. И место поюзается - адекватно, без бреда с выравниваниями и проч, аллокация места динамическая, чанками (bucket'ами в сабже, примерно 1 фиг в итоге) а RAID переопределен в духе "раскинь этот экстент на 2 разные девайса" (не важно какую именно пару, лишь бы место под нужный тип записи было).
Так что Кент и взял за основу те идеи. Next gen файлух - это вот так, и ни...т!
> Что касается сабжа, то его вообще обсуждать бессмысленно, ибо он вообще ещё никем
> и нигде не используется. И неизвестно когда начнёт.Моя пачка виртуалок, пусть и не сильно критичных, с этим не согласны. Там уже есть этого слегка. В целом оно относительно юзабельное. В тяжелый серьезный прод, ессно, не стоит пока.
Впервые слышу про проблемы с выравниванием и аллокацией на zfs. Как это выглядит хоть?
> Впервые слышу про проблемы с выравниванием и аллокацией на 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) та же самая и оно на уровне дизайна может все то же самое, так же. По тем же причинам. Отличия в основном сводятся к названию и деталям типа размера чушки аллокации места на девайсе.
> у нас 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 тоже умеет. И да, я так и не понял, какое отношение это всё имеет к выравниванию?
> На 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. Не парясь выравниванием и проч. В самом плохом случае ребаланс потребуется, но зачастую и это - опциоонально.
Так что по менеджменту это ... сильно более крутая штука. Это управление сторажами как оно должно было быть. И сабж предсказуемо слизал эти идеи.
Лично для меня основной минус 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 сделается автоматически. Я всё сказал.
Добавлю, что в сценарии с заменой меньшего диска на больший в RAID10 из (3Tb+4Tb)+(5Tb+6Tb)=8Tb, ничто не мешает переместить диск 5Tb из второго субкомпонента в первый, таким образом увеличив доступное место следующим образом: (5Tb_old+4Tb)+(6Tb_new+6Tb)=10Tb
> Лично для меня основной минус 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) Поменьше слушать советчиков с опеннета и побольше юзать критическое мышление и свою голову.
> А в btrfs я подцеплю i++'й девайс, скажу btrfs device add, на чем действо завершено, +N места в ФС, даже если это RAIDЛол, до меня кажется дошло... Ты добавляешь диск к массиву, но до ребаланса данные расположенные на этом диске никакой избыточностью не обладают. Я правильно понимаю? Другими словами, ты просто добавляешь одиночный диск в систему. Но ведь и на ZFS я точно так же могу подоткнуть диск, создать на нём пул и назначить ему точку монтирования! И на LVM! )) И получу те самые 40 ГБ из моего примера! Ты это называешь "ассиметричной алокацией"? Прикалывашься?
Точнее не 40, а 30 ГБ (в случае с raid1).
> Лол, до меня кажется дошло... Ты добавляешь диск к массиву, но до
> ребаланса данные расположенные на этом диске никакой избыточностью не обладают.НЕ дошло. До добавки девайса - избыточность обеспечивали уже имевшиеся в ФС девайсы. А это +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 - ОК.
То-есть видите, емкости совпадать не обязаны. И девайсы именно парами быть не обязаны.
> НЕ дошло. До добавки девайса - избыточность обеспечивали уже имевшиеся в ФС девайсы.Таки дошло. Добавляя диск к массиву без перебалансировки ты просто создаёшь смешанный зеркально-линейный массив, на котором избыточность имеют только те данные, что расположены на зеркале. Что ты собственно и подтвердил. Только зачем ты называешь это "расширением массива" если по факту до ребаланса добавленный диск частью зеркала не является?
> В 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! Учи матчасть.
> Таки дошло. Добавляя диск к массиву без перебалансировки ты просто создаёшь смешанный
> зеркально-линейный массив,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 девайса" осталась. Просто реализация... очень креативная. Это не очень хорошо описывается в классических блочных терминах ибо это не совсем оно. Но наиболее близкое описание этого творения инопланетян в земных терминах - такое.
Ты описываешь RAID 1Е, которому сто лет в обед. Я даже готов признать что данные на новый диск начинают писаться сразу в режиме рейда, но тогда если не делать ребаланс мы получаем явные проблемы с управлением свободным пространством, а после ребаланса теряем все преимущества "ассиметричной аллокации". И зачем оно надо? Также есть большие сомнения относительно надёжности схемы, в которой "Если девайс больше - на нем будет больше chunks/buckets". Что случится если девайс, на котором "chunks/buckets" больше чем на других девайсах, выйдет из строя? Откуда брать данные для восстановления?> Это очень креативное переосмысление что такое RAID1
Нет. Просто это не RAID1. Совсем. Безотносительно аллокации и прочих деталей.
> У ZFS этого нет в силу архаичности технологий аллокации.
У ZFS этого нет по причине ненужности. При 3-х дисках выгоднее raid5, а при большем количестве дисков -- raid10, raid5/6 и их производные. Видимо у btrfs действительно всё очень плохо с raid5/6 раз они решили изобрести подобный велосипед.
> Ты описываешь 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 и новая - в новых записях. Это совершенно валидное комбо для такого дизайна. Он также штатно живет с разными схемами избыточности данных и метаданных. По тем же причинам.
> Попробуй собрать 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 persistentUpdate Time : Wed Nov 6 20:09:02 2024
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0Layout : near=2
Chunk Size : 512KConsistency Policy : resync
Name : linux:0 (local to host linux)
UUID : 85411b14:0050b7dd:8bfa0d68:dc04959d
Events : 17Number 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.
> Array Size : 9429504
> (8.99 GiB 9.66 GB)А btrfs и сабж таки сделают что-то близкое к 12 из этого. И без брейнфака с размерами девайсов, рестрайпом по всей площади, и даже - возможностью относительно просто и быстро вынуть девайс, например.
А вон там - больше долботни И хреновее результат. Одновременно. Бонусом btrfs и сабж за счет чексум - при расхождении копий видят которая из 2 кривая и чинят ее из исправной (self heal).
А на обычном RAID вы видя что копии не сошлись - какие выводы сделаете? Что вы f...d up? :))
> А 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 с этим естественно вообще никаких проблем.
>> А 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" который просто и прозрачно ведет к тому же самому без всех этих извратов и ограничений. Поэтому я буду - за вот такое управление сторажами. Не без причин считая что будущее - это так. И Кент крут тем что тоже это понял.
Теперь понятно, что ты используешь термин "выравнивание" не по назначению - индустрия под этим термином понимает выравнивание логических блоков до физических либо 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!
> Теперь понятно, что ты используешь термин "выравнивание" не по назначению - индустрия
> под этим термином понимает выравнивание логических блоков до физических либо 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!Но не спасает от брейнфака в менеджменте всей этой вундервафли...
Только что ради интереса создал на 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).
> Только что ради интереса создал на 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.
> Вы пробовали записывать данные и посмотреть сколько влезет?Нет, не пробовал. Признаю свою ошибку (доверился показаниям файлового менеджера). Сейчас перепроверил -- всё так и есть. Ну, почти. Поначалу я подумал что после перебалансировки действительно доступна половина от общего объёма дисков, но перепроверив на схеме 10+10+50 я получил те же 20 ГБ доступного объёма, что и со схемой 10+10+20, словно это не raid 1E, при котором должно быть доступно 15 ГБ, а raid5 )) И естественно никакой ассиметричной аллокации я снова не увидел. Либо у меня что-то не работает, либо btrfs вместо raid 1E (или "raid1" твоей терминологии) создаёт raid5 и выводит фальшивую информацию о массиве. Как бы то ни было, это в любом случае возвращает нас на исходные позиции. Конечно же это никакой не raid1, а скорее нечто подобное raid 1E, да и то если предположить что оно работает, ибо лично я даже этого не увидел. А если не делать балансировку, то это твоё "расширение" массива равносильно простому добавлению диска и монтированию его в любой удобный каталог, только хуже, т.к. неизвестно какие (и сколько) данные пишутся на зеркало, а какие в линейный массив (а до ребаланса новый диск, как мы уже выяснили, частью зеркала не является, т.к. не содержит копий старых данных). Короче, не ФС, а один головняк.
P.S. Попробовал создать на этих же дисках (10+10+50) raid 1E с помощью mdadm -- ожидаемо получил 15 ГБ доступного пространства. Всё заработало с первого раза, в отличие ОТ ;)
> 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 свободных).
Если не лениво можете проверить. Интересно же протестить мои знания механики "гипердрайва" в деле.
Нет, именно 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. Я удивлюсь если у тебя получатся другие цифры.
> создания массивов на дисках разного размера в голову никогда не приходила,
> поэтому я поначалу что и raid 1E и raid5 подстраиваются под
> меньший из дисков (как в raid1),А вот Крису Мэйсону пришло в голову что менеджмент ФС может быть и куда дружественнее. Без этого делания мозга поиском одинаковых девайсов, запасов железа на складах и прочего брейнфака. Когда просто сделал device add тому что было, получил +N места, вот и вся возня с менеджментом ФС.
Да, для этого он, конечно, развернул механику аллокации не имеющую ничего обшего с RAID1 на блочном уровне. Но т.к. constraints такие же (2 копии, на пару девайсов) это обозвали так. Учитывая что Кент содрал идею в этом смысле почти 1 в 1 - можно говорить уже о некоем новом классе этсамого. Но я не знаю более подходящих названий этого.
> Нет, не пробовал. Признаю свою ошибку (доверился показаниям файлового менеджера).Мне 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 девайса ОК" - остается.
> Короче, не ФС, а один головняк.
Напротив. Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было - и все управление "гипердрайвом" по сути. Но для совсем безграбельной навигации лучше понимать тот трюк "изнутри", тогда все просто, логично и единственный вопрос - почему так раньше не делали?! Как-то так мы и узнаем кто крутой архитект и кто двигает технологии вперед.
> А таки - не нарушает никаких законов природы. И работает так как я и предсказал. Забавно, да?Нет. Забавно то, что btrfs работает даже хуже чем предсказал я. Я-то был уверен что её "raid1" при любых размерах дисков даст половину от общего объёма (как минимум), но выяснилось что ничего подобного нет. На каких-то комбинациях даёт половину, на каких-то нет. И никогда больше половины. И во всех случаях raid5 как минимум не хуже.
> Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было
Ага. Правда непонятно для чего это может понадобиться. Для того, чтобы можно было расширить доступное пространство и удалить файлы, которые в btrfs при недостатке свободного места удалить невозможно? )))
> Нет. Забавно то, что btrfs работает даже хуже чем предсказал я. Я-то
> был уверен что её "raid1" при любых размерах дисков даст половину
> от общего объёма (как минимум), но выяснилось что ничего подобного нет.
> На каких-то комбинациях даёт половину, на каких-то нет. И никогда больше половины.Что логично если 2 копии. Но вообще я люблю делать "невозможное". Так что... дедуп, рефлинки, sparse файлы, сжатие и проч - все же могут внести коррективы на тему того сколько и чего.
У меня спокойно лежит 5 образов по якобы 5 терабайтов на 10 Тб девайсе. Конечно это рефлинки одного и того же. Но формально как бы 25 гигз суммарно и cow поддерживает иллюзию что они независимые. Конечно это имеет свои лимиты. Но для тех целей - сработает.
> И во всех случаях raid5 как минимум не хуже.
Удачи тебе с обычным RAID5 на всяких md и проч. Особенно когда на 1 девайсе вылезет труха или бэд. ZFS имеет какие-то шансы, но в лине это внемайнлайновый выкидыш с 1 стороны, и нормальный менеджмент ТОГО уровня - ему не грозит. В силу архаичности внутреннено устройства. А уж можно было - эвон как.
>> Все становится сильно проще по линии управления. Добавил/вынул что хотелось/было
> Ага. Правда непонятно для чего это может понадобиться. Для того, чтобы можно
> было расширить доступное пространство и удалить файлы, которые в btrfs при
> недостатке свободного места удалить невозможно? )))
> У btrfs нет классических RAID'ов... ;)Конечно есть. raid5 или зеркало из двух дисков вполне себе классические.
>> У btrfs нет классических RAID'ов... ;)
> Конечно есть. raid5 или зеркало из двух дисков вполне себе классические.Как максимум это иллюзия. Под капотом совсем другая механика трансляции и аллокации, не имеющая ничего обшего с той блочно-девайсной логикой. То что оно в сильно некоторых частных случаях похоже - может быть, но и только.
Представляете, btrfs даже с смесью разных схем может жить. Видели "soft" рестрайп? Это делается так: существующие block groups остаются с старой схемой, а в новых записях аллокатор удовлетворяет требования новой схемы. На уровне стуктур фс это совершенно валидно - и по этой причине конверсию схем можно относительно безопасно вырубать, возобновлять и проч - и это реально работает. Я пару раз случайно проверял.
Все же советую забыть про то что вы знали - и посмотреть на эти структуры. Вы будете удивлены "как можно было". Мне кажется вы имеете некие шансы осознать, просто паттерны "мытакпривыкли" застилает глаза и мешает что возможны менее идиотские варианты аллокации. А так можно было. И профессионализм архитекта познается - вот так.
Пофиг абсолютно какая там механика если они дают тот же результат, что и обычные схемы.
> Пофиг абсолютно какая там механика если они дают тот же результат, что
> и обычные схемы.Они дают тот же результат только в некоторых случаях. В обшем случае - имея дело с btrfs или сабжем - лучше понять механику chunks/buckets, для понимания что на самом деле ожидается.
Нет, пытаться примотать привычные вожжи к бортовому компьютеру - хреновая идея. Даже если это и можно при очень сильном желании, это очень субоптимальная идея. Вам придется жить с тем фактом что есть другое семейство технологий аллокации, отличное от того к чему вы привыкли.
> С 4-мя дисками ни о каком raid1 не может быть и речи.
> Естественно я соберу raid10 если нужна повышенная надёжность и draid1, если
> в приоритете полезный объём. Подоткнуть естественно не получится, поэтому просто пересоберу
> массив. Тут к сожалению ZFS похвастаться нечем.в смысле? (я не уверен за _d_ raid) Фича добавлена пол-года назад. Она немного странненькая, потому что нет понятия ребалансировки (размазанное по четырем дискам - так и будет 4way, т.е. будет в общем случае читаться медленней чем файлы записанные уже после подключения пятого). Но в общем-то если файлы тебе дороги - ты и сам вряд ли захочешь их "балансировать".
Какой командой это делается? Потому что я некоторое время назад проводил опыты и у меня ничего не работало.
> Какой командой это делается?configure && make
Поскольку надо собирать либо master (не надо) либо 2.3(RC хзкакой он сейчас, бери последний)
В 2.2 из твоего девуана фича бэкпортирована не будет.А дальше просто zpool attach, как обычно.
(самое смешное что код написан - в 2021м. Но не был принят beсause of lack of resources, разумеется. Ну, лучших фс для линуксов у меня для вас - нет.)
> коровы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. Правда, пока экспериментально
> собвольюмы
А вот это вряд ли будет.
> xfsprogs 3.2.0 introduced a new on-disk format (v5) that includes a metadata checksum scheme
> called Self-Describing Metadataтолько метаданные и с теми непонятно что делать (не вижу рядом "и мы их научились дублировать, и раскладывать по разным носителям).
Вряд ли у них есть интеграция с dm-raid чтобы при проблемах с первой копией просто попробовать вторую (у свинологии есть но она не поделится, возьмите ваш гнутый гепеле и засуньте себе - вооонтуда, а потом дальше кукарекайте как он защищает ваши права)
> только метаданные и с теми непонятно что делать (не вижу рядом "и
> мы их научились дублировать, и раскладывать по разным носителям).Ну как, констатировать - "ааа, факап!" и - загуглить картинку-демотиватор "хочется подарить некоторым", попроси такой у коллег :)
> Вряд ли у них есть интеграция с dm-raid чтобы при проблемах с
> первой копией просто попробовать вторую (у свинологии есть но она не
> поделится, возьмите ваш гнутый гепеле и засуньте себе - вооонтуда, а
> потом дальше кукарекайте как он защищает ваши права)Хыхыхы, ну вот поэтому мы и юзаем btrfs какой, где это все прекрасно работает. Без костылей. Прямо под GPL. Да даже у кента - ЭТО - уже работает худо-бедно. Так что если кто думал трясти жабой на фичу которая стремительно стала commodity - пусть попробует.
>> коровы
> 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% факапом при крахе какого-нибудь рестрайпа.
Вот из-за отсутствия всего перечисленного "ненужно" я и выбрал эту ФС и ни разу не пожалел.
>Когда в XFS завезут коровы, чексуммы, сжатие, дедупликацию, скраб, собвольюмы - тогда может быть.Ресайз в минус, упаковку хвостов файлов.
В самой распоследней - есть, анонс прямо тут был, ЕМНИП...
Была новость, что толи работают над этим, толи только хотят. Но вот, что сделали, не было пока.
>Почему бы не взять XFSОно уже перестало ломаться и бить файлы при скачке напряжения или отключении света?
Лет эдак десять не могу воспроизвести эту ошибку. Пришлите пожалуйста дамп и скриншоты этой ошибки.
это вы с ext3 путаете ...
Ну да - XFS умно зануляет, а не тупо бъёт :)
Но если питалово нормальное (а у вас на лаптопах именно так) - то и не вспомню даже чтоб (С)
У вас полное непонимание работы фс
Они разные, под разные задачи и нельзя одну допилить до вида идеальной
> Они разные, под разные задачиДа неужели? и чем же интересно отличаются задачи btrfs и bcachefs?
> Непонятно зачем так много файловых систем в линуксе. Почему бы не взять XFS и
> просто всем им не пользоваться? Его хватит для большинства а тем кому не хватит
> будут пользоваться чем нибудь другим.Вот и пользуйся своим убогим XFS, делаемым какими-то нонеймами, в стиле "а давайте попробуем натянуть сову^W COW на глобус^W не-cow дизайн?!".
Это настолько "успешно" было - что за@#$шийся в край майнтайнер - чуть не единственное имя немного отличное от нуля в редхатопомойке среди блочнофайлушников - послал все это к черту и сбежал. И теперь отвисает с btrfs'никами почему-то.
А по менеджменту ФС, схем райдов и места вида "добавил девайс, сменил схему хранения на лету, да еще scrub прогнал что все збс" - XFS рядом с btrfs/bcachefs не стоял, не стоит, и не будет в обозримом будущем чем-то сравнимым. Потому что ЭТО должно быть на уровне базовых структур ФС вколочено. А потом прикрутить на сопли - не получится нормально! Так что имхо сам свой XFS недоделаный юзай. Еще и форматы несовместимо ломанули - без миграции - ну я и смигрировал мои XFS на btrfs, раз такое дело пошло. Менеджить это все - намного удобнее стало, чексумы сразу и у данных и метаданных, расширить место легко, в RAID1 можно подтыкать все что под руку попало, без делания мозгов выраваниванием, офлайн дедупалки есть, вот это все.
>Почему бы не взять XFS и просто всем им не пользоватьсяпочему нет простой как валенок FS (навроде XFS) со сжатием - это хороший вопросик, потому что диды жили без скраба и снэпщотов и мы проживём.
> почему нет простой как валенок FS (навроде XFS) со сжатием - это
> хороший вопросик, потому что диды жили без скраба и снэпщотов и мы проживём.Диды тряслись над каждым локалхостом как осиновый лист убивая дни на окучивание 1 тазика. Мы ворочаем целыми фермами и флотилиями, которые большую часть их жизни мы вообще не видим и видеть не хотим - они должны просто работать, где-то в фоне, и не делать мозг.
И конечно у нас нет ресурсов убивать столько времени на меенеджмент каждого локалхоста. Все должно просто работать. А присядки с этими вашими fsck и ответы на непонятные вопросы - для админов локалхоста. Которых из продов - вот - поуходили.
Вот потому унаследованная инфраструктура у всех и расползается прямо в руках: новое делать кто-то ещё может, а вот искусство поддерживать работающим уже потихоньку уходит.
> Вот потому унаследованная инфраструктура у всех и расползается прямо в руках: новое
> делать кто-то ещё может, а вот искусство поддерживать работающим уже потихоньку уходит.А расползается оно в том числе и потому что любители черной магии там такой дрищ разводят что нет слов. А потом еще нуб какой насмотревшись на это решает что ему тоже так можно было.
И потом едитсвенное реальное что с этой помойкой можно сделать - ну вот реально редеплой. Ибо в цать раз меньше сил, времени и денег чем убабахается на попытки все же разгрести кал за вон теми красавами. Иногда метод геракла VS авгиевы конюшни все же рулит. А вы можете, конечно, лопатой там фигачить.
>Почему бы не взять XFS и просто всем им не пользоваться?Я первый был бы за ,но у этой фс- есть недостатки, проделанный на скотч и костыли COW,кэш свободного места,поправили конечно но проблемы то остались.Нет контрольной суммы для данных - вот этот дефект дизайна уже критичный.
Развитие специалистов. Если просто пользоваться, то довольно быстро оказываешься отставашкой. А вот если самому пытаться создавать, то - в лидерах.Примеров - история цивилизации планеты Земля.
А чем эта ФС лучше BTRFS?
Ничем. Btrfs уже давно в продакшене, быстрее, стабильнее и надёжнее. Также Btrfs дефолтная ФС в Fedora и OpenSUSE.
Странно, что заминусовали. BTRFS реально давно в проде, подтверждаю.
Ну да, все в курсе что мордокнига фотки ваших котегов в ней держит ... новых нарожают(С) :)
А вот хоть один, хоть самый вонюченький но банк на ней назовете?
А ты про все банки знаешь какую файловую систему они используют?
NTFS и ext4 соответственно. А ты чего думал?
> NTFS и ext4 соответственно. А ты чего думал?У СУБД свои системы журналирования и им вообще удобнее всего было бы - на RAW разделах. Но тогда неудобно - админам. А если это не субд - вот тут упс, для general purpose файлухи такая педальность - сплошные грабли.
А подложку под СУБД btrfs как раз умеет - режим nocow специально для этого, так что желающие косплеить кусок логики ФС сами могут получить что хотели.
> режим nocow специально для этогоЗачем?
>> режим nocow специально для этого
> Зачем?СУБД обычно сами хотят журналировать все - а некоторые и CoW при этом делать или какое-то подобие данной логики, типа версионирования. Они на самом деле сами по сути - как специализированные ФС. Поэтому некоторые умеют - на raw разделах работать. Но это неудобно админам и вопрос становится в том чтобы это все же был файл.
В этом случае важно чтобы оно...
1) Умело in-place патчинг файла, на что как правило уповает механика СУБД
2) Было максимально тонким и прозрачным shim над "raw разделом" по сути.Ну вот nocow и позволяет - дать этим штукам то что они на самом деле хотели. Т.е. нечто примитивное, типа EXT4 какого. А журналить журналы, cow'ать cow и проч - в высшей степени дурная идея из-за увеличения объема повторяющихся по смыслу работ, при том это только мешается, тормозит и усиливает фрагментацию.
> А ты про все банки знаешь какую файловую систему они используют?Этот чудак на голубом глазу советовал мне CRC32 -> Blake2b в btrfs'е заменить. С аргументом "какой же лох CRC32 как чексумы ФС юзает сейчас?!". Разница в скорости вычислений в 30+ раз этого сэра не смутила. Все что надо знать о его экспертизе в файлухах, в общем то.
А, самый эпик - он нашел ссыль на btrfs'ную вику, и меня же в нее и ткнул со всем апломбом, во. Я подивился такой прыти и ему даже перевел, раз он сам не умеет. Шикарный маневр получился. Ну вот такая вот эпичная экспертиза по фс и чексуммам в них у этого гражданина :). Это он в топике про оптимизацию CRC32C на интеле так отличился, в соседней новости.
> Также Btrfs дефолтная ФС в Fedora и OpenSUSEИ в Альте кстати тоже. Да и Дебиан хоть и не использует btrfs по умолчанию, но в инсталлятор её добавили.
>А чем эта ФС лучше BTRFS?Тем что не пожирает место на диске?
Давно уже не пожирает.
bcache хотя бы не впаривает пользователю свои снапшоты и коммюнити пока что менее упоротое чем у btrfs. Если не в курсе попробуйте спросить что-то типо "как отключит XYZ в btrfs" на реддите.
> коммюнити пока что менее упоротое чем у btrfsюзать глючную файлуху написанную челом, который даже код не может по правилам в апстрим заслать, могут только самые здравомыслящие
Умение правильно послать изменения в апстрим и качество кода это логически несвязанные понятия, плюс сравнивать одного человека с корпорацией (в случае btrfs) это тоже интересно, для одного человека он добился действительно хороших результатов.
там ТРИ копро-рации было. namely suse, oracle и даже, не поверишь, redhat.Поэтому теперь распутать эту вермишель уже и невозможно.
У одного человека куда больше шансов доделать до работающего состояния, а не здесь играем, там рыбу заворачивали.
Неумение автора правильно кланяться и переподавать с прогибом - не является недостатком fs. Скорее как раз наоборот. Вон в бырбыре и кланялись, и переподавали. А она как была глючным неисправимым месивом, так им и остается.
> юзать глючную файлуху написанную челом, который даже код не может по правилам в апстрим заслать, могут только самые здравомыслящиеНу эта ... дома то - почему бы и не да?
А у чела есть _очень_ важное качество - нехилый "крутящий момент"(С)!
И что то мне подсказывает, что вот именно вот это и станей FS NG для ведра, а бэтээр где был там и останется, к примеру.Но верить мне в прогнозах ... нельзя :)
> bcache хотя бы не впаривает пользователю свои снапшотыBcache и Bcachefs - две совершенно разные ипостаси, из общего только некий common code в паре либ ядра. И все.
В сабже есть примерно все то же что и в btrfs. Включая и снапшоты, конечно. Современная COW ФС без снапшотов - это издевательство над здравым смыслом.
> и коммюнити пока что менее упоротое чем у btrfs. Если не в курсе попробуйте спросить
> что-то типо "как отключит XYZ в btrfs" на реддите.Ну, Кент покуда вообще - из дебиана вылетел своими утиласми, за то что им для сборок чуть не ночнушки хруста надо. С весьма колоритными коментами от майнтайнеров на тему годности этого для прода и возможностей иметь дело с таким апстримом.
Активно развиваемый экспериментальный продукт не может жить в окаменевшей стабильной системы — ужас-то какой! Да как же так!!!Да, в дебиане не место экспериментальному софту. Это не проблема, так задумано.
> Активно развиваемый экспериментальный продукт не может жить в окаменевшей стабильной системы
> — ужас-то какой! Да как же так!!!Смотрите, дети, маркетинговый булшит - это как-то так. У меня эн виртуалок с ЭТИМ в вот именно дебиане - работает. Но да, ФСовские тулсы пришлось git checkout'ом отмотать на доХРУСТовую версию. Прикиньте, так можно было.
И да, сам кентушка кажется тоже хруста и его приколов уже откушал - что у него ФС сама теперь учится себя апгрейдить-даунгрейдить и проч прям в ядре. Видимо там он себя еще завонять не успел и это лучше работает - чем вон тот хайп, стреляющий в пятки.
> Да, в дебиане не место экспериментальному софту. Это не проблема, так задумано.
Поразвелось тут всяких истин в последней инстанции... интересно, дебианщики уполномачивали вас за них вещать? Вот прям ВСЕ?
> ... на реддите ...Не то место, где спрашивать. Разве что типа: поболтать на лавке у подъезда.
В первую очередь - тем что в той ни один из живущих уже не может разобраться. Десять лет с неисправимыми ошибками в raid6 - и никто не может понять, в чем причина.
Сделай сам выводы о том, каково там качество остального спагетти-кода и куда его надо засунуть такой.Ну и layered storage в бырбыре не предполагался. Даже в zfs (с определенными поправками на старость решения, когда компьютеры были большие) есть.
в zfs можно прикрутить быстрые ssd как кэш для пула на медленных дисках (L2ARC). что в принципе закрывает самый популярный сценарий использования слоеных накопителей.
там, к сожалению, не все так солнечно. l2arc работает очень странно, и к тому же этот код вообще похоже уже лет пять никто не тестирует (прецеденты полностью неработающего in-memory arc, сломанного улучшайкерами и месяцы не замечавшегося - уже были) - он может вообще не работать как задумано (т.е. добавить тебе тормозов и износа ssd)Ну и нет, самый популярный это буферизировать запись как раз. Потому что чтение неплохо оптимизируется в памяти. А запись надо донести до диска не уронив, а не хранить в памяти вечно. Причем у CoW системы лишних записей на каждый чих неприлично много, эффективно оптимизировать ее, раз уж в системе есть быстрый носитель - стоит того.
(нет, ZiL не кэш, дорогие читатели викивракии)
Но fs нулевых годов эти мелкие недостатки простительны.
И чо? У них для таких Васянов как раз написано, что не надо юзать нашу реализацию raid5/6 в проде. Не, не читал? И думать там что-то про не готовый код и жаловаться на него это глупо.
> У них для таких Васянов как раз написано, чтоНу так и надо исправить: "не надо юзать нашу FS в проде." И это будет голимой правдой.
>> У них для таких Васянов как раз написано, что
> Ну так и надо исправить: "не надо юзать нашу FS в проде."
> И это будет голимой правдой.Когда у тебя будет прод размером с фэйсбук - твои лекции будут чего-нибудь стоить. А покуда научись отличать CRC32 от Blake2b - в том числе по уровню вычислителной сложности функций, без этого с тобой вообще не о чем говорить на тему фс, прода и алгоритмов.
Купи нормальный современный Ынтерпрайс сторидж и почитай доку :) Много найдёшь интересного.PS: Блин даже в слове "купи" получилось слишком много желчи :(
> Купи нормальный современный Ынтерпрайс сторидж и почитай доку :) Много найдёшь интересного.Я почитал более интересные доки - на внутреннюю структуру btrfs и сабжа. Зачем мне камлать на подачки богов с "секретами", если можно самому хаживать на пантеон, да поотвисать там с местными? :). Вон я там кадру попробовал объяснить в чем прикол с RAID1 из _трех_ девайсов, и как так получается что емкость /2 от суммарной даже если с выравниванием не парились.
Прелесть опенсорса - в этом и состоит. Лучшие инновации не где-то там. А "at my fingertips". Так они мне намного больше нравятся.
> В первую очередь - тем что в той ни один из живущих
> уже не может разобраться. Десять лет с неисправимыми ошибками в raid6
> - и никто не может понять, в чем причина.А вот еще одна экспертиза уровня бох^W пох. Если ты напрашиваешься, расставлю точки над i. За твой счет. Ибо - нарвался.
1) Причины как раз таки всем давно понятны. Это обычный write hole.
2) Что-то с ним не сделано только потому что эффективные и радикальные фиксы требуют - поменять немного дисковый формат. Несовместимо с старыми кернелами, конечно. Это делать мало кто хочет.
3) Для RAID5 воркэраунд более менее придумали и если метаданные в RAID1 то данные в RAID5 - можно, если осторожно. Это все равно не идеально, но все же.Тем кому это надо ессно - читают вику и readthedocs куда доки переехали, и понимают проблематиук, и окей ли они с теми соотношениями до того как в это влезать.
> Сделай сам выводы о том, каково там качество остального спагетти-кода и куда
> его надо засунуть такой.ZFS с его управлением памятью, какой-то античной пародией на экстенты, отшибленым управлением местом и снапшотами, странным кешированием и проч - ничего не поможет.
> Ну и layered storage в бырбыре не предполагался. Даже в zfs (с
> определенными поправками на старость решения, когда компьютеры были большие) есть.Да, брейнфак с управлением - в сабже и btrfs никто не собирается запиливать. Половина пойнта сабжа и btrfs - сделать управление простым и прозрачным. Хреново, медленно, стремно, не переконфигуряемо и с кучей запрыгов по граблям, хранением девайсов про запас и проч - всем, извините, надоело. Уже показано что можно лучше чем это. И если ZFS так не умеет, тем хуже для него. А носителей сакрального знания имени сана что-то уходят на мороз.
> А чем эта ФС лучше BTRFS?1) Пытается быть шустрее. Пока, правда, не сказать что супер-успешно, но оно пока в фазе выноса багов, немного не до крутых оптимизаций при этом.
2) Может учитывать свойства девайса и юзать как фронтэнд (кэш) - но при этом учитывая еще и схему хранения. Т.е. это такой гибрид где можно кэширование скрестить с уровнями RAID, довольно забавно придумано.
Когда это по отдельности - как в bcache - через именно блочный уровень - и кэш протирается - degradation зачастую получается вообще совсем не graceful при этом. А попросту ФС под кешом огребает крупноблочные факапы в рандомные места, и это запроектные аварии для любой ФС.
А когда ФС явно в курсе что 1 копия в кеше, а вторая в более медленном но живучем девайсе - ну, скончается та копия в кешее, ее из более медленной починят. Менее дурацкое комбо в целом.
1. Возможность создания многослойных пулов, собственно это главная фишка Bcachefs.
2. Поддержка шифрования.
3. Во многих тестах быстрее, чем btrfs (https://www.phoronix.com/review/linux-611-filesystems)
Не ожидал что разрабов ядра можно словить на "упс, вы забыли проверить это".
Посмотри код DRM/AMD и ужаснись
Ну так язык с конпелятором не помогают
Язык с конем-пилятором не мешают.
> Не ожидал что разрабов ядра можно словить на "упс, вы забыли проверить это".А они что, не люди? Вы так говорите как будто они боги и в принципе не ошибаются. Они конечно выше среднего, но не настолько же?! :)
На 40%
А сколько это в штуках?
Сразу вспоминается шутка про "мы неправильно считаем"
Снижение числа выявляемых ошибок на 40% может также свидетельствовать о том, что на 40% увеличилось число невыявленных ошибок
> Снижение числа выявляемых ошибок на 40% может также свидетельствовать о том, что
> на 40% увеличилось число невыявленных ошибокПессимист, грустно: хуже уже не будет...
Оптимист, радостно: да будет, будет!
меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что они уже написаны на С) что создает конкретные проблемы для LTS дистрибутивов. Чисто религия головного мозга, лучше бы он скраб добавил вместо переписывания того что уже работает на язык который не понимает большинство разработчиков ядра.
Проржавление это то что всего происходит с не очень необходимым.
Ой, у вас всё, что вам не нравится - это пропихивание. Что нравится - святое развитие.
> меня больше напрягает ситуация с пропихиванием растано ты не Линус Торвальдс, и твое мнение не настолько ценное
> меня больше напрягает ситуация с пропихиванием раста
там же кажется диды-неолиляторы одного разраба выпихнули?
так что может раст в ядро не попадет еще долго> на язык который не понимает большинство разработчиков ядра.
и? т.е теперь на дыряшке нужно писать вечность? или достаточно подождать пока разрабы впадут в деменцию или помрут?
> что создает конкретные проблемы для LTS дистрибутивовникакой проблемы - в них bcachefs и не попадет ближайшие лет десять.
Чиста автору захотелось потренироваться на кошках, да. Никакого смысла в переписывании (уже работающих, как обычно) утилит для работы с фс на безопастный йезычок, разумеется, нет.
Толькл если не окажется, что там полно ошибок работы с памятью.
> меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что
> они уже написаны на С) что создает конкретные проблемы для LTSНу вот тут Кентушка уже с своими распоследними ночнушками хруста уже получил несколько жирных отлупов от тяжеловесов дистростроения что они думают про это.
А вынос из дебиана означает что этого в простом безграбельном виде также не будет и в деривативах, как то убунтах, минтах и проч. И тут желающим похайповать есть над чем подумать.
> меня больше напрягает ситуация с пропихиванием раста в btrfs-progs (при том что
> они уже написаны на С) что создает конкретные проблемы для LTS
> дистрибутивов. Чисто религия головного мозга, лучше бы он скраб добавил вместо
> переписывания того что уже работает на язык который не понимает большинство
> разработчиков ядра.Ты б определился чтоли, ты про btrfs или сабжа? Может это про bcachefs-progs было? Да, там хруста напихали и ночнушками обмазались. За что вылетели из дебиана и деривативов.
Нет, зря Линус Кента носом об стол елозил!
Не в коня корм. 60% процентов ошибок он и до пенсии не исправит.
главное показать бурную деятельность. а там и должность в микрософт не за горами
А кстати - да. Если парень покажет на что способен - выкупят с потрохами! Будет фишечкой в их Azur'e ... не бесплатной конечно :)
Оверстрит - перфекционист, да ещё с гипертрофированным самомнением, а перфекционизм ещё никого до добра не доводил. Он просто не может остановиться, поэтому bcachefs никогда не будет закончена.
Перфекционизм очень даже доводил до добра и не раз. Проблема - хоть до чего-то доводит очень долго и редко. Но если вдруг будет результат, то ух какой будет!
> Оверстрит - перфекционист, да ещё с гипертрофированным самомнением, а перфекционизм ещё
> никого до добра не доводил. Он просто не может остановиться, поэтому
> bcachefs никогда не будет закончена.Есть надежжа что пинки толпой - несколько откорректируют это дело и он таки станет несколько адекватнее.
это оно постоянно ломается или btrfs? постоянно путаю два этих ненужна
ломается то, что используется, вот бтрфс используется хотя б чуть чуть, а бкаш нет
Я хоть и не фанат бЭтЭра - на справедливо. Ещё очччень рано в-серьёз об
То есть уменьшил не количество ошибок, а фактов их выявления, лол!
Потому что последние 1.5 пользователи-энтузиасты этой альфы устали от N потери всех свои данные.