После года разработки опубликован выпуск проекта Stratis 2.0, развиваемого компанией Red Hat и сообществом Fedora для унификации и упрощения средств настройки и управления пулом из одного или нескольких локальных накопителей. Stratis предоставляет такие возможности как динамическое выделение места в хранилище, снапшоты, обеспечение целостности и создание слоёв для кэширования. Код проекта написан на языке Rust и распространяется под лицензией MPL 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51828
Удивительно, но из-за лицензионных злодеяний оракла мы не можем нормально использовать элегантную ZFS. Вместо этого редхат как всегда накостылял монстра из D-Bus и прочих костылей с клеем, который теперь единственный будет работать без боданий с DKMS (btrfs же так и не стала стабильной).Более того, дистрибутивы фрагментируются в очередной раз на три технологии (ладно, обычно на две, но все же):
Редхатовые - Stratis
SUSE - BtrFS
Ubuntu - ZFSТребую немедленно сделать ZFS истинно-GPL'овой, встроить в ядро и принять во все дистрибутивы по дефолту.
ZFS жрет память как не в себя, а VDO работает только в редхате, значит для использования не целесообразно.
без deduplication и небольшим тюнингом настроек в /etc/default/zfs (оно вроде по умолчанию хочет 2/3 ram) живёт смирно
а кому вообще нужно он без дедупликейшн?
ваш линух жрет память как не в себя:
Mem: 8160616 8030568 130048 0 152280 7144344
-/+ buffers/cache: 733944 7426672
видали - восемь гиг сожрал! Без всякой zfs.Возмутительнейшее безобразие.
Только в отличие от зфс, он эту память отдаст при необходимости (и ничего не потеряет особо при этом). В этом и проблема, не скалируется так просто. Кстати хинт: у free есть ключик -h, чтобы сделать читабельно.
> Только в отличие от зфс, он эту память отдаст при необходимостив отличие от ваших прохладных былин - zfs спроектирована так, чтобы память, при необходимости - отдавать. Что ей вполне удается делать - в oracle solaris, ага. Но с интересной особенностью, что память отдается не абы какая и не абы как - поэтому и работает эффективнее чем безмозглый buffer cache. Называется этот механизм, внезапно, ARC. Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали.
То есть смысл ровно тот же самый - если у вас не вся свободная память отдана под ARC - вы тупо пилите диск, вместо того чтобы эту свободную память использовать под кэш. Если свободной станет не хватать - arc ужмется, выбросив наименее ценные блоки.
Минус, увы, в том, что обезьянки регулярно это (и не только) место ломают - причем это делают не какие-то лохи из iXsystems, а осененные благодатью седобородые разработчики еще тех, сановских времен (с первыми наперегонки).
После чего перестают отвечать на почту и игнорируют багрепорты.А дать им по горбу - увы, некому. Сплошной just for fun.
> zfs спроектирована так, чтобы память, при необходимости - отдавать. Что ей вполне удается делать - в oracle solaris, агаКолись: устроился недавно сторожем в Газпром? Кто ж ещё нынче будет покупать оракловый солярис, в котором вот-теперь-точно-отдаётся-клянусь-слющай: https://blogs.oracle.com/solaris/changes-to-zfs-arc-memory-a...
А если мы говорим про былые, дооракловые времена, то высвобождение это было порой не без приколов: http://web.archive.org/web/20101126163729/http://bugs.openso... Отдельно интересны расписанные там детали про kernel cage: получается, реализовано всё равно через гланды, прям как в этих ZoL/ZoF, разве что пользователю чаще кажется, что ему память возвращают.
> Колись: устроился недавно сторожем в Газпром? Кто ж ещё нынче будет покупать
> оракловый солярис, в котором вот-теперь-точно-отдаётся-клянусь-слющай:July 7, 2015 - это такое вот "теперь".
Причем оно стало актуально, когда понадобилось для реально больших систем, на том что попроще добиться появления этих проблем вряд ли кому вообще удавалось.
> А если мы говорим про былые, дооракловые времена, то высвобождение это было
> порой не без приколов:ты часто системные платы на ходу выдергиваешь, чтоб тебя реально афектила сия проблема?
> Отдельно интересны расписанные там детали про kernel cage: получается, реализовано всё
> равно через гланды, прям как в этих ZoL/ZoF, разве что пользователюнаоборот - там реализовано было в лоб, через штатный механизм. Благо он как раз имелся. А у него есть некоторые особенности, не всегда он может вовремя предупредить, что память сейчас потребуется в большом количестве. Для большинства применений они не были критичны, опять же эта проблема - "больших". Ну вот через десять лет оракл озаботился сделать отдельный, чтобы не маяться с ручным указанием лимитов.
У freebsd все существенно сложнее, потому что там такого механизма нет вообще (и буферного кэша тоже нет) и с возвратом памяти зохаванной системными процессами тоже есть специфические проблемы (они не только в zfs мешают, но и в других случаях - причем чинить это никто, увы, не планирует). А косорукие умельцы вместо того чтобы попытаться как-то обойти проблемное место - просто его выкинули из кода, совсем. В результате когда память таки кончается - она кончается так, что освободить ее уже не всегда получится в принципе (потому что не хватает памяти для процесса, который этим должен заниматься, здравствуй дидлок). Проблему пытались решить (то есть, собственно, существовало работающее решение, частично реализующее тот самый соляркин механизм мягкого memory pressure) - но оно уперлось в трех хохлов с их "нэ трэба!".
До кучи добавились принесенные из линуха проблемы с abd, мало того что ухудшившие производительность в разы, так еще и сломавшие работу лимитов.Что происходит в линуксной версии - не скажу, но отказ проксмоксы от свопа на zfs как бы намекает нам, что там тоже дидлоки и проблемы на пустом месте, чинить которые просто некому.
На всякий случай, для белок истеричек: все эти проблемы проявляются только на серьезной нагрузке на больших инстансах. Увидеть их у себя - надо сделать что-то совершенно не по гайдлайнам, двадцать раз проигнорировать предупреждения "так не надо, надо вот так", и при этом еще откуда-то взять ненулевую нагрузку, нетипичную для васян-хоста.
Иначе все, к сожалению, будет работать - чуть менее эффективно и чуть менее надежно чем могло бы. "К сожалению" - потому что пока у горе-разработчиков не навернется так, что похоронит их собственные данные - они не почешутся.
> Иначе все, к сожалению, будет работать - чуть менее эффективно и чуть
> менее надежно чем могло бы. "К сожалению" - потому что пока
> у горе-разработчиков не навернется так, что похоронит их собственные данные -
> они не почешутся.Ну вот блджад да, в неудачно прибарахлённой сеточке ребята строили храниль для виртуазализации как раз на ZFS. Причём блджад на достаточно нестандартном решении - габаритном NAS. Саппорт на это счастье там заканчивается, оставшиеся инженегры поддерживать это дело толком не того, а я теперь имею овердохера геморроя и всех остальных с тем, чтобы это всё перетащить на нормальную храниль... даже если ZFS внезапно оденет золотую корону и достанет палочку-всёзащищалочку, я её буду хейтить по её же гроб.
В случае хотя бы iSCSI я бы это дело запилил через транзитный "роутер" и далее синхронизировал по write tracking с небольшим остановом. Но тут мать-мать всё распихано по файлам и ещё со снапшотами и ветками снапшотов... этих самых файлов. Короче только импорт-экспорт с полным остановом.
Ну и да, ZFS как таковая тут совершенно не при чём, при чём дятлы, которые повелись на её функционал, не задумываясь о том, что может случиться какая-нибудь миграция с этого счастья.
Перед словом "функционал" пропущены слова "ненужный расфуфыр... распиаренный".
ну так они-то, видимо, не собирались никуда мигрировать - у них все работало, причем, как я понимаю, и работает по сей день.т.е. с функционалом все в порядке, никто ж не виноват что тебе не нравится конструкция.
Степень вероятности ее превращения в тыкву - я бы определял по месту. В том числе по прошлым факапам и эффективности их устранения. Может там и с этим все нормально, и пожарный переезд не сделает конструкцию ни надежнее, ни удобнее.
> В том числе по прошлым факапам и эффективности их устраненияПрошлые факапы закончились тем, что оно оказалось финансово несостоятельным, и продалось.
> Прошлые факапы закончились тем, что оно оказалось финансово несостоятельным, и продалось.А от инженерного состава осталось полтора инженера, и то временно. Подход был "берём всё модное и рулим".
в смысле, это коммерческое решение какого-то 3d-party, ныне накрывшегося? Тогда да, печаль.(небось, во всем виноваты те твари, которые это понапроектировали - жрать, паскуды, хотели, слишком много. А уволить их нельзя, где ж таких умных новых-то взять, чтоб чинить, если сдохнет. Не менеджеры же ж, действительно.)
> Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали.Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и никому не нужно. Это примерно как в ReactOS контрибьютить: оно вроде и есть, но зачем не понятно.
> Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и
> никому не нужно.херассебе неиспользуется? Даже оставляя в стороне оракла с его загадочными клиенты-есть-но-мы-никому-их-не-назовем и непонятной политикой (хотя хранилки все еще производятся и куда-то, видимо, продаются за невменяемые деньги). Погугли командную строку svn (я понимаю, что современные "специалисты" ничего кроме гита не умеют, но гугель знает) - и погрепай там "Sponsored by" где-нибудь в районе svn://svn.freebsd.org/base/releng/12.1/cddl - для начала.
Это не говоря уже о том, что уежища из NetApp (гуглите, почему уежища) походу тихо сп-ли и пошли, называетсо, нашли удобное решение, и лицензия хорошая, и головой думать не надо, можно уволить еще пару десятков разработчиков и нанять адвоката подороже.
И да, трем хохлам iX платит тоже не за красивые глаза. Кто-то еще эти корыта у них вполне себе покупает, а не ставит халявный freenas чтоб потом грустно моргать над сдохшим пулом.
Я бы попросил показать что-то аналогичных масштабов, сделанное на готовых и популярных решениях на базе линуха и его одобренных и с правильной лицензией fs. Желательно не в 2008м году.
Что, кроме кластеров (которые совершенно отдельная тема, кстати, довольно больная) - показать нечего? От тож.
>>> Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали.
>> Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и
>> никому не нужно.
> Это не говоря уже о том, что уежища из NetApp (гуглите, почему
> уежища) походу тихо сп-ли и пошли, называетсо, нашли удобное решение, и
> лицензия хорошая, и головой думать не надо, можно уволить еще пару
> десятков разработчиков и нанять адвоката подороже.Постгрес однажды чуть не перешёл так в 8.0 на ARC, но чуваки потом нашли US20040098541, поняли, что внедрение поломает бизнесы, продающие сборки этой самой постгри (слава BSDL!), и спешно отказались от уже написанного кода. И что-то я не слышал о том, чтобы NetApp пытались засудить за нарушение этого патента.
Вместо перехода на ARC лучше бы вакуум-фри озаботились, а то очередной танцор с костяной ногой.
> Вместо перехода на ARC лучше бы вакуум-фри озаботились, а то очередной танцор
> с костяной ногой.Фанаты MySQL опять забыли о существовании OPTIMIZE TABLE в их любимой СУБД?
И как часто ты им пользуешься?InnoDB прекрасно реюзает освободившиеся страницы без OPTIMIZE TABLE. Т.е. если много удалить - оно файл не сожмёт, но и пухнуть дальше не будет.
Костыль же пухнет безразмерно ровно до момента VACUUM, который к тому же ещё и блокирующий.
> InnoDB прекрасно реюзает освободившиеся страницы без OPTIMIZE TABLE.…путём запуска подчищалок в отдельном треде: https://dev.mysql.com/doc/refman/5.7/en/innodb-purge-configu...
Это, знаете ли, не сильно отличается по принципу работы от сто лет доступного в постгресе autovacuum.
> Костыль же пухнет безразмерно ровно до момента VACUUM, который к тому же
> ещё и блокирующий.Предъявляйте претензии человеку, приучившего вас писать FULL после VACUUM (да и вообще приучившего писать VACUUM).
Нет, совершенно не тот же процесс.Purge thread подчищает undo логи завершённых транзакций, и уже вслед за ними вычищает собственно строки и страницы. То есть это maintenance транзакционного лога, а не "упаковка" записей таблицы (которая VACUUM).
Далее. Purge thread в отличие от вакуума для своей работы таблицу намертво не блокирует, ага. Автовакуум от блокировки тоже не спасает.
То есть в отличие от вакуума purge thread - это часть механизма ACID.
А вакуум - костяная нога, которую пришлось делать из-за изначально уродского дизайна ACID.
> Нет, совершенно не тот же процесс.
> Purge thread подчищает undo логи завершённых транзакций, и уже вслед за ними
> вычищает собственно строки и страницы. То есть это maintenance транзакционного лога,
> а не "упаковка" записей таблицы (которая VACUUM).Вы опять смешали в одну кучу VACUUM и VACUUM FULL. Последний, да, упаковывает, а первый ровно так же вычищает страницы для последующего использования.
> Далее. Purge thread в отличие от вакуума для своей работы таблицу намертво
> не блокирует, ага. Автовакуум от блокировки тоже не спасает.И ещё раз: «standard form of VACUUM can run in parallel with production database operations». Это же касается и автовакуума. Хватит пихать full vacuum в крон по заветам старых форумов.
И даже SHARE UPDATE EXCLUSIVE блокировку оно не берёт? Да ладно? Неужели?
Так надо было сразу уточнять, что вы работаете с наркоманами, ежесекундно испускающими ALTER TABLE пачками! Где, кстати, они водятся?
у NetApp есть свой патент. И она вполне успешно им воспользовалась - против sun. Отчасти по этой причине, отчасти из-за очень "вовремя" случившегося отглота ораклом, zfs не стала файловой системой для maxosx, хотя такие попытки делались.После чего, судя по некоторым данным - сп...ла технологию, и именно ее, а не свою теоретическую поделку и применяет по сей день.
Ничего обидного. PhD есть, а то, что оно в реальности летает только с прицепленным к жопе пропеллером и на пинковом приводе - уже дело десятое.
Это у вас ваш Линух жрёт, очевидно же.
> ZFS жрет память как не в себяВраньё.
>> ZFS жрет память как не в себя
> Враньё.да нет, все правильно - не будет жрать - у нас будет пустая память, которая могла бы служить дисковым кэшэм. Вон, видал как линух-то жрьооот? Из 8 гиг сожрал восемь! То что там не все гладко и если хочется выжать последние килобайты нужно запастись кучей ненужных знаний - на фоне ужаса с lvm поверх dm поверх luks поверх непойми что без системды не работает - как-то особо уже и не пугает.
(кстати, прикинь, какая у тех чудес эффективность кэширования, если там правая рука не знает, кому др..ит левая)
Я тут недавно шарился по зфсным реддитам (это там где ребятки увлекаются пулами на зфс) и сделал вывод, что не всё с ней так гладко. Чуть ли не лучший вариант это купить солярис под неё (но тогда придётся отказаться от форка зол и его фишечек).>IBM CANONICAL
Лучше бы бтрфс допиливали, право, эта фрагментация бич опенсорса. Всё зло от жадных корпораций, как мы в очередной раз наблюдаем.
что именно не гладко? если по уму, когда память ecc, когда стоит ИБП, когда /boot на отдельном пуле zfs (достаточно большом для вмещения снапшотов, ≈1Гб хотя бы), когда на объеме RAM не сэкономили $150, когда scrubbing проводят хотя бы пару раз в месяц, когда не юзают raidz1 вообще, и не юзают raidz2 для всего 4 дисков, когда не пытаются в одном пуле держать больше 12 дисков (не для того zfs, чтобы СХД заменить), когда send/receive бэкапы делают, какие проблемы? жалуются только, вот мол что делать, если всё таки рассыпался массив, где инструменты для восстановления, так ребята, нету их, для чего бэкапы то? :)
Слишком много "если", не? Типичный юзкейс - это "схд" на антресолях или в чулане, я думаю сегодня каждый не против его иметь. Люди берут готовые сборочки под эти задачи, и очень удивляются, когда всё сыпется.
Можно и проще: если не заниматься дичью. И часто сыпется FreeNAS, есть репрезентативная выборка или очередное мнение эксперта?
когда (не если, а когда) он лично у тебя посыплется - тебе от "репрезентативной выборки" жарко станет, или холодно?
Всё это разговоры в пользу бедных. Если человек взялся говорить про то, что btrfs после допила будет лучше и надежнее zfs, то хотелось бы увидеть основания.
> Всё это разговоры в пользу бедных. Если человек взялся говорить про то,
> что btrfs после допила будет лучше и надежнее zfs, то хотелось
> бы увидеть основания.откройте рот! Так, закройте. Не вижу оснований, мешающих вам говорить ровно обратное.
"будет" "после допила" - угу. Может btrfs, а может ядерная пустыня по причине массовых самоподрывов реакторов, обслуживаемых чудо-автоматикой, не требующей квалификации эксперта по системам с ядерным топливом.
А пока, в среднесрочной перспективе - лучше поизучать устройство метаслабов. Поверьте, пригодится :-(
В любом случае моя личная статистика - на стороне zfs, а не "well tested xfs".
(отсюда: https://opensource.com/article/18/4/stratis-lessons-learned если что. Обратите внимание на год ;-)
сказал ведь, "если по уму", 80% перечисленного относится ко всем видам массивов, даже железных
Какой-то набор из мифов и пограничных случаев кривой реализации, по большей части, на Linux.
Ну да, некоторые баги и проблемы там наблюдаются. Однако, судя по FreeBSD в последний год, источник всех этих проблем это кривой код идущий из ZoL. Если не явно кривой, так уж наверняка ломающий обратную совместимость. И что делать с этим "херак-херак и в продакнш" подходом, столь традиционным для линуксоидов, в нормальных системах не вполне понятно.
Mdadm + lvm на 48 винтов, полет нормальный, памяти жрет мало, не разу не рассыпалось, чяНдр
Не очень понятно, чем вообще ZFS спасёт от повреждения данных _вне_ дисков - они будут повреждены ещё до расчёта сумм и записи. А на самих дисках и прочих носителях - внезапно - имеются свои ECC. Т.е. весь этот сомнительной надобности вторичный чексумминг и прочие бла-бла-радости спасут разве что от повреждения данных в цепочке шина-контроллер связи с накопителями-шина-контроллер накопителя.
"на самих дисках и прочих носителях - внезапно - имеются свои ECC" - а с этого момента можно поподробнее? особенно при повреждении уже записанных данных. zfs спасет тем, что воспользуется избыточностью, как бы все raid массивы с ней для этого существуют :) отличие же от mdraid в том, что целостность за счет хэшей обеспечивается сквозная и сканирование с последующим исправлением происходит во много раз быстрее. Ну и пресловутой writehole проблемы нет
> особенно при повреждении уже записанных данныхОбъясни мне, как они случатся, если на каждый блок данных на диске пишется ещё ECC?
> zfs спасет тем, что воспользуется избыточностью, как бы все
Это уже raidz, а не просто zfs.
> целостность за счет хэшей обеспечивается сквозная
Вот этот вот баззворд уже набил оскомину. Какая целостность? Чего целостность? Сквозная, навылет?
Данные когда с диска или флеша читаются - сверяются с ECC самим носителем. Если проверка не прошла - возвращается ошибка чтения, и никакие хеши тут уже не спасут, блок потерян.
>> особенно при повреждении уже записанных данных
> Объясни мне, как они случатся, если на каждый блок данных на диске
> пишется ещё ECC?ECC не покрывает всех возможных ошибок (сколько их там на сектор максимум?..), ошибок в firmware диска, ошибок в ядрах (привет, md raid 6, blkmq и прочие случаи записи не того или не по тому смещению — а сколько ещё не успели найти?), битфлипов в разных частях железа (необязательно памяти без ECC), операторов, бездумно делающих dd не на тот диск и т. д. В большинстве случаев ECC будет верным, данные с точки зрения диска — тоже, а с точки зрения ФС и пользователя — каша.
Кроме того, можно бесконечно теоретизировать, но моя практика показывает, что zpool scrub нет-нет, да находит и исправляет какие-то битые данные, которые диск с радостью отдаёт без роста reallocated, uncorrectable и вот этого всего. Да, немного (от сотни килобайт до мегабайта), да, редко (диск-другой в год, наверное, но специально я не следил), но они есть.
Не, ну, если вам не жалко данных, то так сразу и скажите, вместо того, чтобы пытаться доказать, что «этого не может быть, потому что этого не может быть никогда».
>> zfs спасет тем, что воспользуется избыточностью, как бы все
> Это уже raidz, а не просто zfs.И?
>> целостность за счет хэшей обеспечивается сквозная
> Вот этот вот баззворд уже набил оскомину. Какая целостность? Чего целостность?Даааааааанныыыыых! Ну не железо же мы сберечь тут пытаемся этими трюками, логично?
> Сквозная, навылет?
Знакомьтесь, https://en.wikipedia.org/wiki/Merkle_tree
Merkle tree - сначала бы хоть разобрались, для чего он там, потом писали.ECC на HDD и SSD покрывает достаточное число ошибок, чтобы не париться по поводу возможного единичного битфлипа.
Ошибки в firmware диска - да (выше писал). Ошибки в ядрах - нет, точнее, почти нет - с наибольшей вероятностью данные будут повреждены ещё до расчёта сумм и записи.
Битфлипы в памяти - также почти нет, с максимальной вероятностью данные будут повреждены до расчёта сумм.
Против dd и прочего никакие доп. суммы не помогут - данные уже потеряны. Только дублирование и т.п.Ещё раз: весь этот checksum bloat нацелен на контроль повреждений данных на участке _между_ контроллером диска и системной памятью. Таковые возможны, конечно. Для решения этой проблемы существуют диски и хост-контроллеры, поддерживающие работу с Protection Information (PI). То, что ZFS тоже пытается решать эту проблему, похвально, но вот цена вопроса...
> Для решения этой проблемы существуют диски и хост-контроллеры, поддерживающие работу с Protection Information (PI). То, что ZFS тоже пытается решать эту проблему, похвально, но вот цена вопроса...А так ли велика цена вопроса на фоне стоимости тех же дисков и контроллеров с поддержкой T10 TI? Особенно с таким умилительным уровнем поддержки:
> users of Red Hat Enterprise Linux 6 should note the following: The DIF/DIX hardware checksum feature must only be used with applications that exclusively issue O_DIRECT I/O
Ну надо понимать, что это для весьма специфичных мест, где стандартной защиты канала недостаточно.
>Не очень понятно, чем вообще ZFS спасёт от повреждения данных _вне_ дисков - они будут повреждены ещё до расчёта сумм и записиZFS должна еще конролировать что там и как для записи в файл подготавливают сторонние левые программы, не испортили ли они свои данные, неумёхи? А так, для уже отправленного на запись куска данных ZFS таки посчитает контрольную сумму ("_вне_ дисков"! до отправки на винты), но не для "спасения поврежденных данных", а для диагностики возможной ошибки, когда эти данные понадобятся. Причем разнесет данные и "ихние" ECC макисмально далеко друг от друга, вплоть до разных дисков, если таковые имеются. Так же, как по разным местам/дискам реплицируются (копируются) блоки метаданных вне зависимости от избыточности зависимого пула, чтобы потом подняться можно было.
> Т.е. весь этот сомнительной надобности вторичный чексумминг и прочие бла-бла-радости спасут разве что от повреждения данных в цепочке шина-контроллер связи с накопителями-шина-контроллер накопителя.
Это для тебя сомнительный. А то, получается, ОЗУ у тебя с ECC будет, момент записи из контроллера накопителя на пластины - тоже c ECC, а вот сама передача данных до винта - не защишена.
Если в твоем сомнительном (для тебя) случае в процессе передачи до контроллера накопителя один битик таки изменится, то твой контроллер с поблочным ECC сожрет это как хорошие данные и потом отдаст их тоже как хорошие. Вот только с ZFS такое не пройдет, он ECC еще "в ОЗУ посчитал" ("_вне_ дисков"), так сказать, "в первоисточнике". Сами пользовательские данные спасены и восстановлены не будут. Это уже забота raidzX и бэкапов с админами.
> ZFS должна еще конролировать что там и как для записи в файл
> подготавливают сторонние левые программы, не испортили ли они свои данные, неумёхи?Ты слышал звон, но не понял где он. Объясняю: лежит кусок данных на запись в памяти. Приложение может быть ещё пошлёт их на запись, может быть уже сформировало запрос, и он начал обрабатываться по дисковому стеку. И тут происходит битфлип. В этом самом куске. ZFS благополучно посчитает суммы от этого битфлипа, разнесёт их "максимально далеко друг от друга", и запишет на диск. Уже повреждёнными :D И ещё отреплицирует.
Передача данных "до винта" защищена минимум CRC32 - в случае SATA. Это старый алгоритм, увы, но от единичных битфлипов он защищает, т.е. твоё "один битик изменится" - случай невозможный.
> Чуть ли не лучший вариант это купить солярис под неётолько его тебе никто не продаст. вот в чем беда. Даже если бы и продали - где ты возьмешь сервер из HCL ? И куда эту дуру будешь ставить?
> (но тогда придётся отказаться от форка зол и его фишечек).
весь этот мусор никому и не нужен. Но отказаться придется еще от последних версий самбы и понятного тюнинга под нее (потому что в солярке он непонятный, а версия будет та, которую тебе осилит собрать орацл), от дешевых и доступных китайских 10G сетевух, и в общем-то не очень понятно, ради чего - потому что когда все развалится, у тебя нет даже комьюнити, которое хоть чем-то могло бы помочь. (потому что никто не знает, как устроена оракловая zfs и как и чем ее чинить если вдруг, и ядро на коленке не попатчишь)
btrfs не допиливают по очень простой и очевидной причине - код - безумное г-но, с которым ничего поделать нельзя, только выкрасить и выбросить. А не потому что враги убивают по ночам разработчиков.
> Всё зло от жадных корпораций, как мы в очередной раз наблюдаем.
угу, мерзкие жадные твари - не дают денег мертворожденным прожектам. А just for fun ты не хочешь, тебе жрать давай четыре раза в день.
С оракловой проблемы у людей возникали только при миграции на опенсорсную версию -- в ней совместимость только с очень древней зфс.>будет та, которую тебе осилит собрать орацл
Так вроде с этим там проблем нет? В принципе, линуксовая самба вообще никуда не годится, если уж на то пошло.
>зфс
>комьюнити
> С оракловой проблемы у людей возникали только при миграции на опенсорсную версиюво времена, когда оракловая еще была сановской - проблемы возникали.
Лечились, бывалоча, прямо патченьем ядра по живому. Для этого тогда были и умельцы, и способы получить толику их внимания.
Сейчас, боюсь, проблемы по прежнему вполне вероятны, система, с-ка, сложная, а железо - ненадежное, но вот людей, способных их решать - либо нет, либо до них не добраться.> Так вроде с этим там проблем нет? В принципе, линуксовая самба вообще никуда не годится, если уж
> на то пошло.так другой нету - разработчики самбы работают и тестируются угадай на какой системе. А что там и как оракл соберет и какой древней версии - загадка. Учитывая, что они свою систему давным-давно не позиционируют как универсальную хранилку для всех - вряд ли они особо заинтересованы делать хорошо.
>зфс
>комьюнитиhttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683
я бы не сказал что в том случае community сильно помогло, хотя пыталось. Но от разработчиков, как видишь, пользы было даже не около нуля, а отрицательное количество.
Кто тебе расскажет о проблемах если этим никто не пользовался и теперь уже точно не будет? В лохматые года полтора компа и сисадмина были, интернета напротив не было, а теперь каждый себе сисадмин и зфс дома держит и воняет на форумах.
Если тихо - это не значит что все хорошо.
А ты значит провёл аудит кода Btrfs?
btrfs в принципе не допиливаема, поскольку изначально криво спроектирована. Балансировка сверху-вниз неповоротлива на больших деревьях, хоть сколько там процессов балансировки пускай. Она хранит блоки переменного размера прямо в деревьях, из-за чего на куче мелких файлов пожирает огромное количество места под метаданные - на разделе с исходниками может свободно пожирать половину объема. Сбой по питанию во время балансировки может окончиться смертью ФС.По сути, её пропихнули в обход всех правил, лишь из-за того, что настоял Oracle. Никаких других причин пихать это поделие в основную ветку нет и не было.
Оналитег нариловался.
Нубяра с протухшими методичками детектед
У всех перечисленных есть свои + и -, хотя про стратис этот я ничего не понял, но подобные велосипеды поверх обычных фс и без него есть. Это линуксвей кстати =)
> хотя про стратис этот я ничего не понялчего тебе непонятного - хрустоподелка, собирается исключительно хрустокомпилятором позавчерашней сборки. Ничего не умеет, включая то, что давно умеют нижележащие слои (уж что-что, а хотя бы 2x redundancy lvm умел еще полтора десятка лет назад - а эти даже и того ниасилили), просто очередное средство для мышевозюкалок, прячущее редхатовское нагромождение адских уродов - до первой поломки, разумеется.
Кто уже пытался загрузить в single user редхатосистему с thin lvm - тот меня поймет. А чинить там уже и нечего будет, в случае чего. Получишь хорошо перемешанную кашу байтиков, размазанную ровным слоем по всем дискам. При желании - еще и зашифрованную.write only storage system. (c) redhatbm
Вангую что это такой storage spaces из мира линукса от RH ( сам эти storage spaces руками не трогал впрочем)
> Вангую что это такой storage spaces из мира линукса от RHstorage spaces у нас называются lvm, и существовали за много-много лет до их переизобретения MS
Работали странно, надежность была стремной. В результате (в основном руками rh) всю хрень изрядно переписали, насколько сейчас ей можно пользоваться (учитывая что переписали очень многое, при этом параллельно было много чего поломано и переделано в ведре - включая прекрасную историю с blk-mq, тихо портившим данные на fs - что характерно, это нововведение уже и не выключается) - дело темное.
Особенно когда поверх в качестве основной рекомендации лежит "проверенная временем" xfs, которую тоже пару раз переписали чуть ли не с нуля, потому что "проверенно" было в основном ее умение необратимо ломаться.
А уровень местных "экспертов", не отличающих где шоколад, где дерьмо, потому что слаще морковки вообще не едали - к сожалению, не позволяет никому из них верить на слово.
А этот stratis - всего лишь user-friendly междумордие поверх, для альтернативно-одаренных, которым их данные точно не нужны.
За полтора года разработки не научился даже избыточности - хотя lvm умеет от рождения (впрочем, они, кажется, любят thin-lvm, а что этот умеет - для меня самого загадка)
конечно, это ж орацл вам сломал использование модулями aes-инструкций процессора, это орацл, проклятущий, вам назло написал невменяемую систему управления памятью, у которой единственный объект - это страница, причем если она, вдруг, не 4k, то ничего толком не работает, это орацл пихал под локоть (сановских, что характерно - ту еще, оригинальную начинавших писать) разработчиков чтоб они сажали совершенно изумительно глупые баги, и никогда-никогда не проверяли результаты своих правок.Орацл, проклятый, во всем виноват, конечно же ж.
А совсем не отсутствие сановского менеджера с палкой над горбом разработчиков, из-за которого вся разработка выродилась в последовательное ухудшение и доламывание хорошей системы, оставленной без присмотра.
Он, кстати, вам еще и в шта..в btrfs нас...л, потому что это разработка, долгое время чуть ли не в одно жало делавшаяся сотрудником оракла в рабочее время.
При этом те кто хотели - вполне себе zfs пользуются. Той, увы, которую мы все заслуживаем, а не той, которую по прежнему пилит себе оракл, но при закрытых дверях.
>[оверквотинг удален]
> Орацл, проклятый, во всем виноват, конечно же ж.
> А совсем не отсутствие сановского менеджера с палкой над горбом разработчиков, из-за
> которого вся разработка выродилась в последовательное ухудшение и доламывание хорошей
> системы, оставленной без присмотра.
> Он, кстати, вам еще и в шта..в btrfs нас...л, потому что это
> разработка, долгое время чуть ли не в одно жало делавшаяся сотрудником
> оракла в рабочее время.
> При этом те кто хотели - вполне себе zfs пользуются. Той, увы,
> которую мы все заслуживаем, а не той, которую по прежнему пилит
> себе оракл, но при закрытых дверях.Так и знал, что не пройдешь мимо и рассыпешься в большой поток сознания ❤️
> это ж орацл вам сломал использование модулями aes-инструкций процессораОго, а Грег КХ в курсе, что он работает теперь на Эллисона?
Btrfs не стала стабильной только в одной конфигурации. И то даже в этой конфигурации она или уже стабильна или в самое ближайшее время её пометят стабильной в следующем релизе.
В raid-6 оно не стабильно, но обещают в следующем релизе исправить.
«не стабльно» недостаточно точно описывает ситуацию «гарантировано разрушает пул при отключении или аварийном завершении процесса на протяжении некоего фрагмента цикла записи».
И не только raid6, но и raid5.
D-BUS одна из прекраснейших технологий 21 века. Очень годная вещь сосредоточившись на управлении через неё можно забыть о фрагментации дистрибутивов и подходов. Единый API ну разве это не шикарно!
> D-BUS одна из прекраснейших технологий 21 века. Очень годная вещь сосредоточившись на
> управлении через неё можно забыть о фрагментации дистрибутивов и подходов. Единый
> API ну разве это не шикарно!Одна и прекраснейших технологий, которая... тормозит как не в себя. Нет, не шикарно, API не должно требовать демона. Они сделали го*но и только додумались, что никакой демон не нужен, а достаточно лишь либы, которая реализует API (Varlink).
>Требую немедленно сделать ZFS истинно-GPL'овой, встроить в ядро и принять во все дистрибутивы по дефолту.А смысл?
Разные задачи - разные инструменты.
Поиски единственной FS на все случаи жизни - занятие столь же безсмысленное, как поиски "универсальной операционной системы".
ну вообще-то весь смысл этого cpaтиса, прости Г-ди - это как раз заменить возможности современных fs "проверенными внутриядерными механизмами линуха". Что они проверенно умеют превращать ваши данные в кашу, причем каждый отдельно - lvm умеет, xfs умеет, про чудо-шифровалки и новые модные веяния с block cache я уж молчу - как-то случайно выносят за скобки.> Поиски единственной FS на все случаи жизни
у нас пока не то что единственной нет, а хотя бы одной - приемлемо удобной и допустимо надежной.
А требования к функционалу и надежности - растут, потому что прошли времена, когда ты мог сбэкапать свой замечательный сервер на пачку дискет, да еще и регулярно повторять процесс с проверкой восстановления. Сейчас его часто не на что и незачем бэкапать, и при отказе хранилки можно просто поставить на этом месте красивый крест.
> элегантную ZFSВ голосину
ZFS элегантна примерно настолько же, насколько эленгантен ожиревший танцор балета весом 200кг с протезом вместо одной ноги, который к тому же вдвое длиннее оставшейся целой.
Есть истории успеха в восстановление рейда на уровне LVM?
mdraid при флапе нескольких линков восстанавливается с полпинка.
Аппаратный чуть сложнее.
lvcreate --type raid5 при тестах восстановить не удалось.
А что такое флап линков?
например вот такое:
Aug 18 06:32:19 server kernel: ata6.00: exception Emask 0x50 SAct 0xe00 SErr 0x4090800 action 0xe frozen
Aug 18 06:32:19 server kernel: ata6.00: irq_stat 0x00400040, connection status changed
Aug 18 06:32:19 server kernel: ata6: SError: { HostInt PHYRdyChg 10B8B DevExch }
Aug 18 06:32:19 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Aug 18 06:32:19 server kernel: ata6.00: cmd 60/10:48:70:51:a2/00:00:02:00:00/40 tag 9 ncq dma 8192 in\x0a res 40/00:00:c8:cc:f2/00:00:02:00:00/40 Emask 0x50 (ATA bus error)
Aug 18 06:32:19 server kernel: ata6.00: status: { DRDY }
Aug 18 06:32:19 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Aug 18 06:32:19 server kernel: ata6.00: cmd 60/10:50:f0:b7:f2/00:00:02:00:00/40 tag 10 ncq dma 8192 in\x0a res 40/00:00:c8:cc:f2/00:00:02:00:00/40 Emask 0x50 (ATA bus error)
Aug 18 06:32:19 server kernel: ata6.00: status: { DRDY }
Aug 18 06:32:19 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Aug 18 06:32:19 server kernel: ata6.00: cmd 60/38:58:c8:cc:f2/00:00:02:00:00/40 tag 11 ncq dma 28672 in\x0a res 40/00:00:c8:cc:f2/00:00:02:00:00/40 Emask 0x50 (ATA bus error)
Aug 18 06:32:19 server kernel: ata6.00: status: { DRDY }
Aug 18 06:32:19 server kernel: ata6: hard resetting link
Aug 18 06:32:25 server kernel: ata6: link is slow to respond, please be patient (ready=0)
Aug 18 06:32:29 server kernel: ata6: COMRESET failed (errno=-16)
Aug 18 06:32:29 server kernel: ata6: hard resetting link
Aug 18 06:32:35 server kernel: ata6: link is slow to respond, please be patient (ready=0)
Aug 18 06:32:36 server kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)диск отваливается, мат.плата пытается к нему достучаться, через некоторое время ей это удается, диск продолжает работу. тоже использую mdadm (там был raid5), массив не разваливался - продолжал работу, но fs при этом билась (fsck.ext4 находил ошибки, с монтированием проблем не было).
в моем случае проблема была с кабелем (после его замены диск начал нормально работать), хотя внешний осмотр повреждений не выясвил.
Простите, но рейд и должен разваливаться при таком поведении. Флап линка - повод выбросить носитель из рейда до ручного вмешательства.
Интересно то, что md похоже по умолчанию этого не делает... и тем более - не запоминает состояния на момент отвала. Битмап-то включен, надеюсь? Если нет, ССЗБ.
> Интересно то, что md похоже по умолчанию этого не делает...делает.
/dev/md0:
Version : 1.2
Creation Time : Tue Sep 3 14:22:26 2019
Raid Level : multipath
Array Size : 83824870 (79.94 GiB 85.84 GB)
Raid Devices : 8
Total Devices : 5
Persistence : Superblock is persistentUpdate Time : Mon Sep 9 21:05:07 2019
State : clean, degraded
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0Consistency Policy : none
Name : (none):0
Events : 7Number Major Minor RaidDevice State
- 0 0 0 removed
- 0 0 1 removed
- 0 0 2 removed
3 8 80 3 active sync /dev/sdf
4 8 16 4 active sync /dev/sdb
5 8 64 5 active sync /dev/sde
6 8 32 6 active sync /dev/sdc
7 8 48 7 active sync /dev/sdd
Ну вот у писателя выше, судя по написанному, этого не произошло. Что он там выкрутил и где - мне неведомо.
> Ну вот у писателя выше, судя по написанному, этого не произошло.видимо, не успело - традиционная беда линукса с несвязанными как следует между собой деталями - md не успел заметить, что что-то пошло не так (потому что не видно вообще его реакции), ошибки записи не вернулись на уровень файловой системы (которая должна была отреагировать паникой или r/o remount) - все как обычно у нас.
В моем случае там физически вырубился один из san-свитчей, не на пару минут, multipath отреагировал ровно так, как ему и полагалось, сервис, вроде, не пострадал (там прекрасный btrfs, который проблему не видит, что не гарантирует, разумеется, что ее и на самом деле нет).
[Wed Oct 23 18:45:15 2019] rport-2:0-0: blocked FC remote port time out: removing target and saving binding
[Wed Oct 23 18:45:19 2019] multipath: IO failure on sdi, disabling IO path.
multipath: Operation continuing on 7 IO paths.
[Wed Oct 23 18:45:19 2019] md: super_written gets error=10
[Wed Oct 23 18:45:19 2019] multipath: IO failure on sdh, disabling IO path.
(как видим, тут есть явные сообщения от самого md, что что-то пошло не так)С попытками использовать вместо этого dm-multipath - так легко и просто не прокатывает, во всяком случае, на не-rh системах.
multipathd настроен на пропагацию ошибок вверх по стеку вместо повторов? :)
Или md при сборке массива нашёл суперблок не на multipath-устройстве, а на как раз том самом, которое отвалилось, и заюзал? Кстати последнее случается, реальные устройства надо из доступного md списка выкидывать первым делом.
> multipathd настроен на пропагацию ошибок вверх по стеку вместо повторов? :)у меня нет multipathd и прочих дискмаперных наворотов - поэтому и работает.
То есть там голый in-kernel md поверх физического multipath, который он сам собирает из отдельных дисков, и сам - разбирает, если вдруг путь отваливается.
При этом схема проста как палка, и ломаться в ней особо нечему (пока альтернативно-одаренные не запустят свои корявки в "неэффективный и устаревший" код md-multipath, и оно не приедет с пылу, с жару в "LTS" версию системы, но, я очень надеюсь, что это уже после моего увольнения или смерти произойдет)
systemd иногда не может загрузиться, но это не фатальная проблема.
bitmap включен, возможно поэтому диск и не вылетел из массива (но проверять с отключеным не хочу).
на данный момент (а это уже лет 10) lvm - это всего-лишь комбинация тех или иных преднастроенных вызовов к dm.
фактически как сабж, но без дбаса и с рэйдом.
однако инструментов для аварийного ковыряния в пуле не имеет. А инструменты от dm-* не подходят, потому что это хоть и dm* глубоко в душе — но снаружи всё же не dm*.
эм... а какие инструменты вам нужны? и какие есть у zfs?
lvm/mdadm/cryptsetup - это обертки над dmsetup, но вам никто не мешает в существующий lvm лезть руками при помощи dm-утилит (на свой страх и риск разумеется).
из моей практики, у меня были проблемы с lvm, но мне его родных утилит хватило для восстановления.
поделитесь своим опытом, когда lvm-утилиты не справились?
> нескольких линковесли вы несколько дисков отключили от raid 5 то восстановить его будет нельзя.
флап != отключение.
> флап != отключение.При нормальной работе нормальной системы флап должен == отключению, за исключением единственного случая - когда от отключения до подключения не было записи, да и то нежелательно назад подключать. В противном случае последствия непредсказуемы.
это в идеале.
а еще raid1 на чтение должен читать с обоих дисков и в случае несовпадения данных или ошибок чтения выдавать предупреждение, а по факту mdadm raid1 (возможно и другие, но за этот ручаюсь точно) при чтении из raid1 массива использует методику raid0 - данные читаются попеременно с обоих дисков (для увеличения скорости), и если на одном диске есть badblock на который никогда не попадает чтение, то такой диск не будет выброшен из массива, а когда накроется его сосед будет уже поздно.
увидеть это можно на практике при помощи fio, но не помню деталей (вроде чтение из массива raid1 из двух дисков равняется удвоенной скорости чтения с одного диска при половинной очереди, которая использовалась для теста массива, т.е. ядро разбивает запросы на два потока и направляет их на два диска, если бы это было не так - чтение с массива не отличалось бы от чтения с одного диска, если диски одинаковые).
По факту аппаратные рейд делают так же, а для сверки данных и обнаружения дохлых блоков есть скраббинг. В mdadm он тоже настраивается, кстати.
// рейды
// в md
(по ночам надо спать...)
нет, почему же? могу говорить только за mdadm, но отключение двух и более дисков из raid5 (на горячую) не убивают массив безвозвратно: доступ к данным массива теряется (io error на read/write), по /proc/mdstat видно что несколько дисков отсутствуют, перезапуск массива (mdadm --stop/mdadm --assemble --scan) результата не дает - массив все так же игнорирует отключеные диски (даже если они уже в системе), но mdadm --assemble --force - проблему решает, mdadm забивает на разные timestamp'ы у дисков одного массива и собирает их - массив можно дальше использовать. естественно данные, которые записывались в момент сбоя могут быть неполные, но все данные при этом не теряются.
> mdraid при флапе нескольких линков восстанавливается с полпинкаRAID5? При флапе нескольких линков? Я очень сомневаюсь, что на том, что там восстановилось, данные будут корректны - при условии, что в момент отвала шла какая-то запись, естественно. Вылет двух дисков в RAID5 - это фатал.
ну так ты продожай тут постить fud про zfs, не владея темой от слова нихрена.У которой флап (а не тотальный отказ) любого количества дисков в raidz1 - ведет всего лишь к потере последней не синхронной операции записи и необходимости ручного переподключения.
Вот такие вот чудеса, с 2004го года.А у тебя сразу п-ц и фатал, и непонятно, какие данные испортились, и как их отличить, но ты продолжай рассказывать какая плохая zfs, как не нужны чексуммы, и как все хорошо и замечательно у л@п4@тых в их поделках.
P.S. поздравляю Максима с новой победой г0вноробота над людьми. А на новость про lizard времени так и не нашлось.
P.P.S. mdadm таки переживет флап и с raid5, но гарантии что потом хваленый xfs восстановится родными утилитами нет никакой, разумеется.
raidz1
raid5
FUD
... слов нет ... речь не про дублирующий рейд, да и там флап двух дисков (если дублей 1 штуко) - фаталА вообще в любом нормальном отказоустойчивом хранилище флап диска - это повод выкинуть диск до ручного вмешательства.
> raidz1
> raid5
> FUD
> ... слов нет ... речь не про дублирующий рейд, да и тамНаш всезнайка еще и не в курсе что такое raidz. Это не "дублирующий рейд", так, на минуточку. mirror у zfs называется, внезапно, mirror.
Но мнение при этом про zfs - он имеет, ага.> флап двух дисков (если дублей 1 штуко) - фатал
нет. Флап в нормально спроектированных системах - просто флап. Моргнуло, терабайты данных от этого не должны мгновенно аннигилироваться.
> А вообще в любом нормальном отказоустойчивом хранилище флап диска - это повод
> выкинуть диск до ручного вмешательства.именно так и происходит. Но одно дело, когда ручное вмешательство - просто вручную выдать команду attach или перезагрузиться в надежде на автоматику, а потом проверить консистентность дисков, совсем другое - когда ты сидишь перед рухнувшим dm, и не знаешь, как его теперь собрать обратно, а stackoverflow недоступен из-за аварии у оператора.
> Флап в нормально спроектированных системах - просто флап. Моргнуло, терабайты данныхНу давай, расскажи мне про нормально спроектированные системы, где так происходит. Желательно с названиями.
Терабайты данных от этого никуда не деваются, диск вылетает, остальные работают. Если есть резерв - начинается копирование на резерв.> рухнувшим dm
Так не надо его заставлять работать с выпавшим диском после флапа, и он никуда не денется. Да и md назад собрать - не бог весть какая затея, достаточно man с машины не удалять. Стэковерфловы - удел девляпсов.
> он никуда не денется. Да и md назад собрать - не бог весть какая затеяmd - да. А как насчет dm-raid?
(по понятным причинам, первый использовать, к сожалению, не стоит)
> md - да. А как насчет dm-raid?
> (по понятным причинам, первый использовать, к сожалению, не стоит)В смысле первый не стоит?
Как раз таки второй aka fakeraid использовать не стоит. Если используется - все вопросы к биосу.
Ну и грань между ними так себе, в общем случае dmraid банально надстройка над md, объясняющая как унылые биосовые массивы собирать.
Чтобы иметь мнение насчёт несъедобности говна, пробовать его на вкус вовсе не обязательно.
> Чтобы иметь мнение насчёт несъедобности говна, пробовать его на вкус вовсе не обязательно.чтобы это мнение имело ценность - надо иметь либо обоняние, либо хотя бы зрение.
А ты, увы, судя по невладению даже базовой терминологией - слышал в перепеве Рабиновича непонятно что и о чем.
И чем эта смузирастахрень лучше lvm?
ничем.
это фронтэнд.
который не умеет даже mirror
Так написано же:
Проект изначально преподносится как не требующий для администрирования квалификации эксперта по системам хранения.Пора редхету начать выпускать домашние аэс, не требующие квалификации эксперта.
Чес слово для mdadm и lvm не надо быть гением
при создании нет, но при нештатных ситуациях, нужно уметь их исправлять.
> при создании нет, но при нештатных ситуациях, нужно уметь их исправлять.ты правда думаешь что dbus-поделка что-то умеет - исправлять?
Ну и про создание - пожалуйста, список команд для ручного создания xfs over thin-lvm (потому что мы, наверное, все же хотим lightweight-снапшоты) в студию, не подглядывая в стековерфлоу.
шит-криптографию и redundancy, чорт с ними, пока пропустим.
> при создании нет, но при нештатных ситуациях, нужно уметь их исправлять.При нештатных ситуациях подобные управлялоподелки разваливаются первыми.
Я читал их документацию. Они собирают из кучи подсистем ядра (dmcrypt llvm xfs and friends) 5 слоев абстракции и управляют этим всем через ОДНУ утилиту в юзерспейсе. На выходе должна получится та же ZFS, только построенная на старом надежном функционале встроенном в ядро линукс.
Вот только ZFS-фичи начнутся с версии 3.0.
А еще, мне очень интересно, что случится с пулом если этот демон "внезапно" умрет (скажем от ommkiller-a), а система продолжит работать... а потом, как произойдет перемещение пары тройки терабайт пропадет питание.
Хорошо что у меня есть бекапы.
> 5 слоев абстракцииЕщё интересно как это всё будет работать при обновлении ядра или утилит, с учётом "stable api nonsense". Если конечно у них вообще есть планы развивать это, а не делать эксклюзивно для redhatibm.
>> 5 слоев абстракции
> Ещё интересно как это всё будет работать при обновлении ядра или утилит,
> с учётом "stable api nonsense". Если конечно у них вообще естьну типа, чем дальше ты от "nonsense", тем безопаснее. То есть обновления ядра не затронут это чудо совсем, а при обновлении dbus скорее всего отвалится управление, но не развалится fs.
А если ты так обновился, что в /sbin/lvm код несовместим с dm-*.ko - это, вероятно, либо очень кривой дистрибутив, либо нефиг лезть руками в сложные системы без понимания что и от чего тут зависит.
Это тебе не "мы тут в новой версии запретили aes", и модуль не грузится и не компилируется.
т.е. refs таки всех победил?
лежа в гробу? Вряд ли... что-то перспективы ms'овских стораджей сегодня выглядят еще более сомнительными чем перспективы йежа.
> лежа в гробу? Вряд ли... что-то перспективы ms'овских стораджей сегодня выглядят еще
> более сомнительными чем перспективы йежа.Вы не поверите, но и МСовских гипервизоров и МСовской гиперконвергенции несколько больше, чем всяких проксмоксов и пр. вместе взятых...
не поверю. Где они, блжат? У MS в ажурном облачке?Проксмоксу видел, от наколенных поделок в конторе на пятнадцать страдальцев (с затолканым туда же фринасом, ховнклаудом и фрипое6иксой, как тут кто-то гордился) до довольно больших (где реально ссыкотно как оно все еще вообще не навернулось)
Впопенштифт, с ceph и вот этой всей херней, настроенный методом next-next-next без малейшего понимания чем чревато - каждый день вижу, с..ные аутсорсеры.
Про кластеры из г-на и палок (в смысле гластеров/прочих хреньфс) - ну живьем не видел, кроме собственных экспериментов, но слышал и читал - дохрена. У кого-то даже и работает, пока еще.
Даже вмварьскую vsan видел (да, п-ц, непонятно ни зачем, ни как они вообще еще живут - но есть).
Винду - не, не видел. При том что винда - везде, а вот эти линуксоподелки из дерьма и палок - очень местами и временами, и я еще и сознательно держусь от них как можно дальше, чтоб чинить не припахали.
У всех в этом "везде" почему-то обычные san-стораджи, иногда в обертке какой-нибудь виртуализации, иногда просто так.То есть вот если для линукса еще десять лет назад было _общим_ решением - "ставимся на машину с двумя дисками - включаем lvm с --mirrors 2, если железным рейдом обделили", то увидеть винду с включенным storage space (что можно было до недавнего времени в любой десяточке любому васяну) - ни разу. Васяны не в курсе, а остальным, видимо, не надо.
Практически все крупные ВУЗы, некоторые "типы" крупных госконтор и пр. оченно аквтивно используют гиперв. Просто гиперконвергенция от МС получается куда дешевле и понятнее гиперконвергенции от DELL-EMC даже на том же самом железе. И если дедупликацию от EMC мало кто на поде юзал, то тут есть шанс...Сам удивился как много в мире этого добра. Как много аутлук веб аппа и соответственно известного почтовика, как много ИИСа на проде наружу. Работает как-то. А азура нет... там другое.
Как там насчёт интеграции с systemd?
systemd-stratisd
> Как там насчёт интеграции с systemd?без него ты даже не подключишь thin-раздел. Такие вот пирожки с крысятами :-(
P.S. буду рад увидеть инструкцию, опровергающую это утверждение. Чур - лично проверенную.
> Значительное изменение номера версии связано с переименованием некоторых интерфейсов D-Bus и переработкой организации работы с D-BusВот это кстати, очень показательно: разрабы D-Bus занимаются "перестановкой кроватей" а все, чей софт от этого дибаса зависит, вынуждены эту имитацию деятельности отслеживать и переделывать свои проги.
PS: Поигрался с этим стратисом: простой, удобный, ненужный. Как-то так)
>разрабы D-Bus занимаются "перестановкой кроватей"Или удовлетворением требований не использовать оскорбляющие чьи-то чувства имена.
> Значительное изменение номера версии связано с переименованием некоторых интерфейсов D-Bus и переработкой организации работы с D-BusОбновил дебас - развалился кластерный рейд. Энтерпрайзненько так.
ну, пользователям mdadm/lvm этого не понять.
> ну, пользователям mdadm/lvm этого не понять.ну да, невостановимый отвал стораджа при смене hostname (внезапно, фича начиная с rhel7) - это ж мелочи жизни.
> невостановимый отвал стораджа при смене hostnameЩито, простите?
Или вы смогли так кластерный сторейдж завалить? Если да - я вас поздравляю, к кластерам вас лучше не подпускать.
>> невостановимый отвал стораджа при смене hostname
> Щито, проститенаучись пользоваться гуглем, неумешка.
А то можешь оказаться в один непрекрасный день в очень неприятной позе, вместо любимой позы всезнайки.
Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет, и прекрасно знаю, где соломку подстелить, чтобы оно не рассыпАлось.
Если ребята на кластерах додумались хостнеймы менять бездумно и всё завалить - это вообще непонимание базы, неумение читать доки, ССЗБ и ЛПП, а не проблема RHEL.
Hostname не должен влиять на что-то отличное от сетевых настроек/служб и т.п.. Если при его изменении волится сторадж, то на лицо явная ошибка проектирования конечных софтин.
> Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет,next-next-next нажимаешь?
Ну, ок.> прекрасно знаю, где соломку подстелить, чтобы оно не рассыпАлось.
непохоже.
Больше похоже что пока - проносило.P.S. что характерно - пользоваться поисковиком пациент не умеет.
>> Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет,
> next-next-next нажимаешь?Да, в голой консоли пишу next, и после пальцем на несенсорный экран там, где написал, нажимаю.