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

"Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
Сообщение от opennews (ok), 07-Ноя-19, 20:57
После  года разработки опубликован выпуск проекта Stratis 2.0, развиваемого  компанией Red Hat и сообществом Fedora для унификации и упрощения средств настройки и управления пулом из одного или нескольких локальных накопителей.  Stratis предоставляет такие возможности как динамическое выделение места в хранилище, снапшоты, обеспечение целостности и создание слоёв для кэширования. Код проекта написан на языке Rust и  распространяется под лицензией MPL 2.0... Подробнее: https://www.opennet.me/opennews/art.shtml?num=51828
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–5 +/–
Сообщение от ilyafedin (ok), 07-Ноя-19, 20:57
Удивительно, но из-за лицензионных злодеяний оракла мы не можем нормально использовать элегантную ZFS. Вместо этого редхат как всегда накостылял монстра из D-Bus и прочих костылей с клеем, который теперь единственный будет работать без боданий с DKMS (btrfs же так и не стала стабильной). Более того, дистрибутивы фрагментируются в очередной раз на три технологии (ладно, обычно на две, но все же): Редхатовые - Stratis SUSE - BtrFS Ubuntu - ZFS Требую немедленно сделать ZFS истинно-GPL'овой, встроить в ядро и принять во все дистрибутивы по дефолту.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–3 +/–
	Сообщение от Аноним (3), 07-Ноя-19, 21:03
	ZFS жрет память как не в себя, а VDO работает только в редхате, значит для использования не целесообразно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от rinat85 (?), 07-Ноя-19, 21:28
	без deduplication и небольшим тюнингом настроек в /etc/default/zfs (оно вроде по умолчанию хочет 2/3 ram) живёт смирно
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	115. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Аноним (3), 09-Ноя-19, 23:03
	а кому вообще нужно он без дедупликейшн?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–3 +/–
	Сообщение от пох. (?), 07-Ноя-19, 22:29
	ваш линух жрет память как не в себя: Mem:       8160616    8030568     130048          0     152280    7144344 -/+ buffers/cache:     733944    7426672 видали - восемь гиг сожрал! Без всякой zfs. Возмутительнейшее безобразие.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	22. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (22), 07-Ноя-19, 22:53
	Только в отличие от зфс, он эту память отдаст при необходимости (и ничего не потеряет особо при этом). В этом и проблема, не скалируется так просто. Кстати хинт: у free есть ключик -h, чтобы сделать читабельно.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	27. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 07-Ноя-19, 23:20
	> Только в отличие от зфс, он эту память отдаст при необходимости в отличие от ваших прохладных былин - zfs спроектирована так, чтобы память, при необходимости - отдавать. Что ей вполне удается делать - в oracle solaris, ага. Но с интересной особенностью, что память отдается не абы какая и не абы как - поэтому и работает эффективнее чем безмозглый buffer cache. Называется этот механизм, внезапно, ARC. Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали. То есть смысл ровно тот же самый - если у вас не вся свободная память отдана под ARC - вы тупо пилите диск, вместо того чтобы эту свободную память использовать под кэш. Если свободной станет не хватать - arc ужмется, выбросив наименее ценные блоки. Минус, увы, в том, что обезьянки регулярно это (и не только) место ломают - причем это делают не какие-то лохи из iXsystems, а осененные благодатью седобородые разработчики еще тех, сановских времен (с первыми наперегонки). После чего перестают отвечать на почту и игнорируют багрепорты. А дать им по горбу - увы, некому. Сплошной just for fun.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	44. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+3 +/–
	Сообщение от имя (ok), 08-Ноя-19, 06:31
	> 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, разве что пользователю чаще кажется, что ему память возвращают.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	65. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 12:22
	> Колись: устроился недавно сторожем в Газпром? Кто ж ещё нынче будет покупать > оракловый солярис, в котором вот-теперь-точно-отдаётся-клянусь-слющай: July 7, 2015 - это такое вот "теперь". Причем оно стало актуально, когда понадобилось для реально больших систем, на том что попроще добиться появления этих проблем вряд ли кому вообще удавалось. > А если мы говорим про былые, дооракловые времена, то высвобождение это было > порой не без приколов: ты часто системные платы на ходу выдергиваешь, чтоб тебя реально афектила сия проблема? > Отдельно интересны расписанные там детали про kernel cage: получается, реализовано всё > равно через гланды, прям как в этих ZoL/ZoF, разве что пользователю наоборот - там реализовано было в лоб, через штатный механизм. Благо он как раз имелся. А у него есть некоторые особенности, не всегда он может вовремя предупредить, что память сейчас потребуется в большом количестве. Для большинства применений они не были критичны, опять же эта проблема - "больших". Ну вот через десять лет оракл озаботился сделать отдельный, чтобы не маяться с ручным указанием лимитов. У freebsd все существенно сложнее, потому что там такого механизма нет вообще (и буферного кэша тоже нет) и с возвратом памяти зохаванной системными процессами тоже есть специфические проблемы (они не только в zfs мешают, но и в других случаях - причем чинить это никто, увы, не планирует). А косорукие умельцы вместо того чтобы попытаться как-то обойти проблемное место - просто его выкинули из кода, совсем. В результате когда память таки кончается - она кончается так, что освободить ее уже не всегда получится в принципе (потому что не хватает памяти для процесса, который этим должен заниматься, здравствуй дидлок). Проблему пытались решить (то есть, собственно, существовало работающее решение, частично реализующее тот самый соляркин механизм мягкого memory pressure) - но оно уперлось в трех хохлов с их "нэ трэба!". До кучи добавились принесенные из линуха проблемы с abd, мало того что ухудшившие производительность в разы, так еще и сломавшие работу лимитов. Что происходит в линуксной версии - не скажу, но отказ проксмоксы от свопа на zfs как бы намекает нам, что там тоже дидлоки и проблемы на пустом месте, чинить которые просто некому. На всякий случай, для белок истеричек: все эти проблемы проявляются только на серьезной нагрузке на больших инстансах. Увидеть их у себя - надо сделать что-то совершенно не по гайдлайнам, двадцать раз проигнорировать предупреждения "так не надо, надо вот так", и при этом еще откуда-то взять ненулевую нагрузку, нетипичную для васян-хоста. Иначе все, к сожалению, будет работать - чуть менее эффективно и чуть менее надежно чем могло бы. "К сожалению" - потому что пока у горе-разработчиков не навернется так, что похоронит их собственные данные - они не почешутся.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	125. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:00
	> Иначе все, к сожалению, будет работать - чуть менее эффективно и чуть > менее надежно чем могло бы. "К сожалению" - потому что пока > у горе-разработчиков не навернется так, что похоронит их собственные данные - > они не почешутся. Ну вот блджад да, в неудачно прибарахлённой сеточке ребята строили храниль для виртуазализации как раз на ZFS. Причём блджад на достаточно нестандартном решении - габаритном NAS. Саппорт на это счастье там заканчивается, оставшиеся инженегры поддерживать это дело толком не того, а я теперь имею овердохера геморроя и всех остальных с тем, чтобы это всё перетащить на нормальную храниль... даже если ZFS внезапно оденет золотую корону и достанет палочку-всёзащищалочку, я её буду хейтить по её же гроб.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	126. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:02
	В случае хотя бы iSCSI я бы это дело запилил через транзитный "роутер" и далее синхронизировал по write tracking с небольшим остановом. Но тут мать-мать всё распихано по файлам и ещё со снапшотами и ветками снапшотов... этих самых файлов. Короче только импорт-экспорт с полным остановом.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	127. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:03
	Ну и да, ZFS как таковая тут совершенно не при чём, при чём дятлы, которые повелись на её функционал, не задумываясь о том, что может случиться какая-нибудь миграция с этого счастья.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	128. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:06
	Перед словом "функционал" пропущены слова "ненужный расфуфыр... распиаренный".
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	138. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 14-Ноя-19, 18:18
	ну так они-то, видимо, не собирались никуда мигрировать - у них все работало, причем, как я понимаю, и работает по сей день. т.е. с функционалом все в порядке, никто ж не виноват что тебе не нравится конструкция. Степень вероятности ее превращения в тыкву - я бы определял по месту. В том числе по прошлым факапам и эффективности их устранения. Может там и с этим все нормально, и пожарный переезд не сделает конструкцию ни надежнее, ни удобнее.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	139. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 14-Ноя-19, 21:18
	> В том числе по прошлым факапам и эффективности их устранения Прошлые факапы закончились тем, что оно оказалось финансово несостоятельным, и продалось.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	140. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 14-Ноя-19, 21:19
	> Прошлые факапы закончились тем, что оно оказалось финансово несостоятельным, и продалось. А от инженерного состава осталось полтора инженера, и то временно. Подход был "берём всё модное и рулим".
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	141. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 15-Ноя-19, 11:57
	в смысле, это коммерческое решение какого-то 3d-party, ныне накрывшегося? Тогда да, печаль. (небось, во всем виноваты те твари, которые это понапроектировали - жрать, паскуды, хотели, слишком много. А уволить их нельзя, где ж таких умных новых-то взять, чтоб чинить, если сдохнет. Не менеджеры же ж, действительно.)
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	56. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от mumu (ok), 08-Ноя-19, 11:23
	> Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали. Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и никому не нужно. Это примерно как в ReactOS контрибьютить: оно вроде и есть, но зачем не понятно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	59. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от пох. (?), 08-Ноя-19, 11:53
	> Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и > никому не нужно. херассебе неиспользуется? Даже оставляя в стороне оракла с его загадочными клиенты-есть-но-мы-никому-их-не-назовем и непонятной политикой (хотя хранилки все еще производятся и куда-то, видимо, продаются за невменяемые деньги). Погугли командную строку svn (я понимаю, что современные "специалисты" ничего кроме гита не умеют, но гугель знает) - и погрепай там "Sponsored by" где-нибудь в районе svn://svn.freebsd.org/base/releng/12.1/cddl - для начала. Это не говоря уже о том, что уежища из NetApp (гуглите, почему уежища) походу тихо сп-ли и пошли, называетсо, нашли удобное решение, и лицензия хорошая, и головой думать не надо, можно уволить еще пару десятков разработчиков и нанять адвоката подороже. И да, трем хохлам iX платит тоже не за красивые глаза. Кто-то еще эти корыта у них вполне себе покупает, а не ставит халявный freenas чтоб потом грустно моргать над сдохшим пулом. Я бы попросил показать что-то аналогичных масштабов, сделанное на готовых и популярных решениях на базе линуха и его одобренных и с правильной лицензией fs. Желательно не в 2008м году. Что, кроме кластеров (которые совершенно отдельная тема, кстати, довольно больная) - показать нечего? От тож.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	71. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 08-Ноя-19, 13:03
	>>> Там пару phd защитили на деталях этой самой реализации, а не за вечерок кое-как наляпали. >> Обидно, наверное, было вложить столько сил и времени в то, что в итоге нигде не используется и >> никому не нужно. > Это не говоря уже о том, что уежища из NetApp (гуглите, почему > уежища) походу тихо сп-ли и пошли, называетсо, нашли удобное решение, и > лицензия хорошая, и головой думать не надо, можно уволить еще пару > десятков разработчиков и нанять адвоката подороже. Постгрес однажды чуть не перешёл так в 8.0 на ARC, но чуваки потом нашли US20040098541, поняли, что внедрение поломает бизнесы, продающие сборки этой самой постгри (слава BSDL!), и спешно отказались от уже написанного кода. И что-то я не слышал о том, чтобы NetApp пытались засудить за нарушение этого патента.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	74. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:36
	Вместо перехода на ARC лучше бы вакуум-фри озаботились, а то очередной танцор с костяной ногой.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	120. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 11-Ноя-19, 15:12
	> Вместо перехода на ARC лучше бы вакуум-фри озаботились, а то очередной танцор > с костяной ногой. Фанаты MySQL опять забыли о существовании OPTIMIZE TABLE в их любимой СУБД?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	124. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 17:52
	И как часто ты им пользуешься? InnoDB прекрасно реюзает освободившиеся страницы без OPTIMIZE TABLE. Т.е. если много удалить - оно файл не сожмёт, но и пухнуть дальше не будет. Костыль же пухнет безразмерно ровно до момента VACUUM, который к тому же ещё и блокирующий.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	131. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 11-Ноя-19, 18:27
	> InnoDB прекрасно реюзает освободившиеся страницы без OPTIMIZE TABLE. …путём запуска подчищалок в отдельном треде: https://dev.mysql.com/doc/refman/5.7/en/innodb-purge-configu... Это, знаете ли, не сильно отличается по принципу работы от сто лет доступного в постгресе autovacuum. > Костыль же пухнет безразмерно ровно до момента VACUUM, который к тому же > ещё и блокирующий. Предъявляйте претензии человеку, приучившего вас писать FULL после VACUUM (да и вообще приучившего писать VACUUM).
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	132. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:53
	Нет, совершенно не тот же процесс. Purge thread подчищает undo логи завершённых транзакций, и уже вслед за ними вычищает собственно строки и страницы. То есть это maintenance транзакционного лога, а не "упаковка" записей таблицы (которая VACUUM). Далее. Purge thread в отличие от вакуума для своей работы таблицу намертво не блокирует, ага. Автовакуум от блокировки тоже не спасает.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	133. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:55
	То есть в отличие от вакуума purge thread - это часть механизма ACID. А вакуум - костяная нога, которую пришлось делать из-за изначально уродского дизайна ACID.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	134. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 11-Ноя-19, 19:04
	> Нет, совершенно не тот же процесс. > Purge thread подчищает undo логи завершённых транзакций, и уже вслед за ними > вычищает собственно строки и страницы. То есть это maintenance транзакционного лога, > а не "упаковка" записей таблицы (которая VACUUM). Вы опять смешали в одну кучу VACUUM и VACUUM FULL. Последний, да, упаковывает, а первый ровно так же вычищает страницы для последующего использования. > Далее. Purge thread в отличие от вакуума для своей работы таблицу намертво > не блокирует, ага. Автовакуум от блокировки тоже не спасает. И ещё раз: «standard form of VACUUM can run in parallel with production database operations». Это же касается и автовакуума. Хватит пихать full vacuum в крон по заветам старых форумов.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	135. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 12-Ноя-19, 09:30
	И даже SHARE UPDATE EXCLUSIVE блокировку оно не берёт? Да ладно? Неужели?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	136. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 12-Ноя-19, 11:40
	Так надо было сразу уточнять, что вы работаете с наркоманами, ежесекундно испускающими ALTER TABLE пачками! Где, кстати, они водятся?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	80. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 14:59
	у NetApp есть свой патент. И она вполне успешно им воспользовалась - против sun. Отчасти по этой причине, отчасти из-за очень "вовремя" случившегося отглота ораклом, zfs не стала файловой системой для maxosx, хотя такие попытки делались. После чего, судя по некоторым данным - сп...ла технологию, и именно ее, а не свою теоретическую поделку и применяет по сей день.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	73. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:35
	Ничего обидного. PhD есть, а то, что оно в реальности летает только с прицепленным к жопе пропеллером и на пинковом приводе - уже дело десятое.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	53. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (53), 08-Ноя-19, 10:02
	Это у вас ваш Линух жрёт, очевидно же.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	37. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от xm (ok), 08-Ноя-19, 01:43
	> ZFS жрет память как не в себя Враньё.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	66. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 12:28
	>> ZFS жрет память как не в себя > Враньё. да нет, все правильно - не будет жрать - у нас будет пустая память, которая могла бы служить дисковым кэшэм. Вон, видал как линух-то жрьооот? Из 8 гиг сожрал восемь! То что там не все гладко и если хочется выжать последние килобайты нужно запастись кучей ненужных знаний - на фоне ужаса с lvm поверх dm поверх luks поверх непойми что без системды не работает - как-то особо уже и не пугает. (кстати, прикинь, какая у тех чудес эффективность кэширования, если там правая рука не знает, кому др..ит левая)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	4. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от Аноним (22), 07-Ноя-19, 21:03
	Я тут недавно шарился по зфсным реддитам (это там где ребятки увлекаются пулами на зфс) и сделал вывод, что не всё с ней так гладко. Чуть ли не лучший вариант это купить солярис под неё (но тогда придётся отказаться от форка зол и его фишечек). >IBM CANONICAL Лучше бы бтрфс допиливали, право, эта фрагментация бич опенсорса. Всё зло от жадных корпораций, как мы в очередной раз наблюдаем.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	8. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от rinat85 (?), 07-Ноя-19, 21:39
	что именно не гладко? если по уму, когда память ecc, когда стоит ИБП, когда /boot на отдельном пуле zfs (достаточно большом для вмещения снапшотов, ≈1Гб хотя бы), когда на объеме  RAM не сэкономили $150, когда scrubbing проводят хотя бы пару раз в месяц, когда не юзают raidz1 вообще, и не юзают raidz2  для всего 4 дисков, когда не пытаются в одном пуле держать больше 12 дисков (не для того zfs, чтобы СХД заменить), когда send/receive бэкапы делают, какие проблемы? жалуются только, вот мол что делать, если всё таки рассыпался массив, где инструменты для восстановления, так ребята, нету их, для чего бэкапы то? :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (22), 07-Ноя-19, 21:56
	Слишком много "если", не? Типичный юзкейс - это "схд" на антресолях или в чулане, я думаю сегодня каждый не против его иметь. Люди берут готовые сборочки под эти задачи, и очень удивляются, когда всё сыпется.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–2 +/–
	Сообщение от zzz (??), 07-Ноя-19, 22:57
	Можно и проще: если не заниматься дичью. И часто сыпется FreeNAS, есть репрезентативная выборка или очередное мнение эксперта?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	28. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 07-Ноя-19, 23:22
	когда (не если, а когда) он лично у тебя посыплется - тебе от "репрезентативной выборки" жарко станет, или холодно?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	50. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от zzz (??), 08-Ноя-19, 09:22
	Всё это разговоры в пользу бедных. Если человек взялся говорить про то, что btrfs после допила будет лучше и надежнее zfs, то хотелось бы увидеть основания.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	67. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 12:38
	> Всё это разговоры в пользу бедных. Если человек взялся говорить про то, > что btrfs после допила будет лучше и надежнее zfs, то хотелось > бы увидеть основания. откройте рот! Так, закройте. Не вижу оснований, мешающих вам говорить ровно обратное. "будет" "после допила" - угу. Может btrfs, а может ядерная пустыня по причине массовых самоподрывов реакторов, обслуживаемых чудо-автоматикой, не требующей квалификации эксперта по системам с ядерным топливом. А пока, в среднесрочной перспективе - лучше поизучать устройство метаслабов. Поверьте, пригодится :-( В любом случае моя личная статистика - на стороне zfs, а не "well tested xfs". (отсюда: https://opensource.com/article/18/4/stratis-lessons-learned если что. Обратите внимание на год ;-)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	55. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от rinat85 (?), 08-Ноя-19, 11:07
	сказал ведь, "если по уму", 80% перечисленного относится ко всем видам массивов, даже железных
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	38. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от xm (ok), 08-Ноя-19, 01:52
	Какой-то набор из мифов и пограничных случаев кривой реализации, по большей части, на Linux. Ну да, некоторые баги и проблемы там наблюдаются. Однако, судя по FreeBSD в последний год, источник всех этих проблем это кривой код идущий из ZoL. Если не явно кривой, так уж наверняка ломающий обратную совместимость. И что делать с этим "херак-херак и в продакнш" подходом, столь традиционным для линуксоидов, в нормальных системах не вполне понятно.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	48. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от SOska (?), 08-Ноя-19, 08:50
	Mdadm + lvm на 48 винтов, полет нормальный, памяти жрет мало, не разу не рассыпалось, чяНдр
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	75. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:40
	Не очень понятно, чем вообще ZFS спасёт от повреждения данных _вне_ дисков - они будут повреждены ещё до расчёта сумм и записи. А на самих дисках и прочих носителях - внезапно - имеются свои ECC. Т.е. весь этот сомнительной надобности вторичный чексумминг и прочие бла-бла-радости спасут разве что от повреждения данных в цепочке шина-контроллер связи с накопителями-шина-контроллер накопителя.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	98. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от rinat85 (?), 08-Ноя-19, 17:07
	"на самих дисках и прочих носителях - внезапно - имеются свои ECC" - а с этого момента можно поподробнее? особенно при повреждении уже записанных данных. zfs спасет тем, что воспользуется избыточностью, как бы все raid массивы с ней для этого существуют :) отличие же от mdraid в том, что целостность за счет хэшей обеспечивается сквозная и сканирование с последующим исправлением происходит во много раз быстрее. Ну и пресловутой writehole проблемы нет
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	105. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 23:53
	> особенно при повреждении уже записанных данных Объясни мне, как они случатся, если на каждый блок данных на диске пишется ещё ECC? > zfs спасет тем, что воспользуется избыточностью, как бы все Это уже raidz, а не просто zfs. > целостность за счет хэшей обеспечивается сквозная Вот этот вот баззворд уже набил оскомину. Какая целостность? Чего целостность? Сквозная, навылет? Данные когда с диска или флеша читаются - сверяются с ECC самим носителем. Если проверка не прошла - возвращается ошибка чтения, и никакие хеши тут уже не спасут, блок потерян.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	121. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 11-Ноя-19, 16:01
	>> особенно при повреждении уже записанных данных > Объясни мне, как они случатся, если на каждый блок данных на диске > пишется ещё ECC? ECC не покрывает всех возможных ошибок (сколько их там на сектор максимум?..), ошибок в firmware диска,  ошибок в ядрах (привет, md raid 6, blkmq и прочие случаи записи не того или не по тому смещению — а сколько ещё не успели найти?), битфлипов в разных частях железа (необязательно памяти без ECC), операторов, бездумно делающих dd не на тот диск и т. д. В большинстве случаев ECC будет верным, данные с точки зрения диска — тоже, а с точки зрения ФС и пользователя — каша. Кроме того, можно бесконечно теоретизировать, но моя практика показывает, что zpool scrub нет-нет, да находит и исправляет какие-то битые данные, которые диск с радостью отдаёт без роста reallocated, uncorrectable и вот этого всего. Да, немного (от сотни килобайт до мегабайта), да, редко (диск-другой в год, наверное, но специально я не следил), но они есть. Не, ну, если вам не жалко данных, то так сразу и скажите, вместо того, чтобы пытаться доказать, что «этого не может быть, потому что этого не может быть никогда». >> zfs спасет тем, что воспользуется избыточностью, как бы все > Это уже raidz, а не просто zfs. И? >> целостность за счет хэшей обеспечивается сквозная > Вот этот вот баззворд уже набил оскомину. Какая целостность? Чего целостность? Даааааааанныыыыых! Ну не железо же мы сберечь тут пытаемся этими трюками, логично? > Сквозная, навылет? Знакомьтесь, https://en.wikipedia.org/wiki/Merkle_tree
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	122. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 17:37
	Merkle tree - сначала бы хоть разобрались, для чего он там, потом писали. ECC на HDD и SSD покрывает достаточное число ошибок, чтобы не париться по поводу возможного единичного битфлипа. Ошибки в firmware диска - да (выше писал). Ошибки в ядрах - нет, точнее, почти нет - с наибольшей вероятностью данные будут повреждены ещё до расчёта сумм и записи. Битфлипы в памяти - также почти нет, с максимальной вероятностью данные будут повреждены до расчёта сумм. Против dd и прочего никакие доп. суммы не помогут - данные уже потеряны. Только дублирование и т.п. Ещё раз: весь этот checksum bloat нацелен на контроль повреждений данных на участке _между_ контроллером диска и системной памятью. Таковые возможны, конечно. Для решения этой проблемы существуют диски и хост-контроллеры, поддерживающие работу с Protection Information (PI). То, что ZFS тоже пытается решать эту проблему, похвально, но вот цена вопроса...
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	129. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 11-Ноя-19, 18:13
	> Для решения этой проблемы существуют диски и хост-контроллеры, поддерживающие работу с 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
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	130. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 18:24
	Ну надо понимать, что это для весьма специфичных мест, где стандартной защиты канала недостаточно.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	119. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (119), 11-Ноя-19, 15:11
	>Не очень понятно, чем вообще ZFS спасёт от повреждения данных _вне_ дисков - они будут повреждены ещё до расчёта сумм и записи ZFS должна еще конролировать что там и как для записи в файл подготавливают сторонние левые программы, не испортили ли они свои данные, неумёхи? А так, для уже отправленного на запись куска данных ZFS таки посчитает контрольную сумму ("_вне_ дисков"! до отправки на винты), но не для "спасения поврежденных данных", а для диагностики возможной ошибки, когда эти данные понадобятся. Причем разнесет данные и "ихние" ECC макисмально далеко друг от друга, вплоть до разных дисков, если таковые имеются. Так же, как по разным местам/дискам реплицируются (копируются) блоки метаданных вне зависимости от избыточности зависимого пула, чтобы потом подняться можно было. > Т.е. весь этот сомнительной надобности вторичный чексумминг и прочие бла-бла-радости спасут разве что от повреждения данных в цепочке шина-контроллер связи с накопителями-шина-контроллер накопителя. Это для тебя сомнительный. А то, получается, ОЗУ у тебя с ECC будет, момент записи из контроллера накопителя на пластины - тоже c ECC, а вот сама передача данных до винта - не защишена. Если в твоем сомнительном (для тебя) случае в процессе передачи до контроллера накопителя один битик таки изменится, то твой контроллер с поблочным ECC сожрет это как хорошие данные и потом отдаст их тоже как хорошие. Вот только с ZFS такое не пройдет, он ECC еще "в ОЗУ посчитал" ("_вне_ дисков"), так сказать, "в первоисточнике". Сами пользовательские данные спасены и восстановлены не будут. Это уже забота raidzX и бэкапов с админами.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	123. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 11-Ноя-19, 17:47
	> ZFS должна еще конролировать что там и как для записи в файл > подготавливают сторонние левые программы, не испортили ли они свои данные, неумёхи? Ты слышал звон, но не понял где он. Объясняю: лежит кусок данных на запись в памяти. Приложение может быть ещё пошлёт их на запись, может быть уже сформировало запрос, и он начал обрабатываться по дисковому стеку. И тут происходит битфлип. В этом самом куске. ZFS благополучно посчитает суммы от этого битфлипа, разнесёт их "максимально далеко друг от друга", и запишет на диск. Уже повреждёнными :D И ещё отреплицирует. Передача данных "до винта" защищена минимум CRC32 - в случае SATA. Это старый алгоритм, увы, но от единичных битфлипов он защищает, т.е. твоё "один битик изменится" - случай невозможный.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	17. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от пох. (?), 07-Ноя-19, 22:38
	> Чуть ли не лучший вариант это купить солярис под неё только его тебе никто не продаст. вот в чем беда. Даже если бы и продали - где ты возьмешь сервер из HCL ? И куда эту дуру будешь ставить? > (но тогда придётся отказаться от форка зол и его фишечек). весь этот мусор никому и не нужен. Но отказаться придется еще от последних версий самбы и понятного тюнинга под нее (потому что в солярке он непонятный, а версия будет та, которую тебе осилит собрать орацл), от дешевых и доступных китайских 10G сетевух, и в общем-то не очень понятно, ради чего - потому что когда все развалится, у тебя нет даже комьюнити, которое хоть чем-то могло бы помочь. (потому что никто не знает, как устроена оракловая zfs и как и чем ее чинить если вдруг, и ядро на коленке не попатчишь) btrfs не допиливают по очень простой и очевидной причине - код - безумное г-но, с которым ничего поделать нельзя, только выкрасить и выбросить. А не потому что враги убивают по ночам разработчиков. > Всё зло от жадных корпораций, как мы в очередной раз наблюдаем. угу, мерзкие жадные твари - не дают денег мертворожденным прожектам. А just for fun ты не хочешь, тебе жрать давай четыре раза в день.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	25. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Аноним (22), 07-Ноя-19, 23:00
	С оракловой проблемы у людей возникали только при миграции на опенсорсную версию -- в ней совместимость только с очень древней зфс. >будет та, которую тебе осилит собрать орацл Так вроде с этим там проблем нет? В принципе, линуксовая самба вообще никуда не годится, если уж на то пошло. >зфс >комьюнити
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	29. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от пох. (?), 07-Ноя-19, 23:42
	> С оракловой проблемы у людей возникали только при миграции на опенсорсную версию во времена, когда оракловая еще была сановской - проблемы возникали. Лечились, бывалоча, прямо патченьем ядра по живому. Для этого тогда были и умельцы, и способы получить толику их внимания. Сейчас, боюсь, проблемы по прежнему вполне вероятны, система, с-ка, сложная, а железо - ненадежное, но вот людей, способных их решать - либо нет, либо до них не добраться. > Так вроде с этим там проблем нет? В принципе, линуксовая самба вообще никуда не годится, если уж > на то пошло. так другой нету - разработчики самбы работают и тестируются угадай на какой системе. А что там и как оракл соберет и какой древней версии - загадка. Учитывая, что они свою систему давным-давно не позиционируют как универсальную хранилку для всех - вряд ли они особо заинтересованы делать хорошо. >зфс >комьюнити https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683 я бы не сказал что в том случае community сильно помогло, хотя пыталось. Но от разработчиков, как видишь, пользы было даже не около нуля, а отрицательное количество.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	47. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от hhhg (?), 08-Ноя-19, 08:18
	Кто тебе расскажет о проблемах если этим никто не пользовался и теперь уже точно не будет? В лохматые года полтора компа и сисадмина были, интернета напротив не было, а теперь каждый себе сисадмин и зфс дома держит и воняет на форумах. Если тихо - это не значит что все хорошо.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	41. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Gannet (ok), 08-Ноя-19, 04:05
	А ты значит провёл аудит кода Btrfs?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	35. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от zzz (??), 08-Ноя-19, 00:26
	btrfs в принципе не допиливаема, поскольку изначально криво спроектирована. Балансировка сверху-вниз неповоротлива на больших деревьях, хоть сколько там процессов балансировки пускай. Она хранит блоки переменного размера прямо в деревьях, из-за чего на куче мелких файлов пожирает огромное количество места под метаданные - на разделе с исходниками может свободно пожирать половину объема. Сбой по питанию во время балансировки может окончиться смертью ФС. По сути, её пропихнули в обход всех правил, лишь из-за того, что настоял Oracle. Никаких других причин пихать это поделие в основную ветку нет и не было.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	42. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Gannet (ok), 08-Ноя-19, 04:06
	Оналитег нариловался.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–2 +/–
	Сообщение от Fracta1L (ok), 08-Ноя-19, 11:54
	Нубяра с протухшими методичками детектед
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	9. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от ff (??), 07-Ноя-19, 21:45
	У всех перечисленных есть свои + и -, хотя про стратис этот я ничего не понял, но подобные велосипеды поверх обычных фс и без него есть. Это линуксвей кстати =)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	19. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от пох. (?), 07-Ноя-19, 22:43
	> хотя про стратис этот я ничего не понял чего тебе непонятного - хрустоподелка, собирается исключительно хрустокомпилятором позавчерашней сборки. Ничего не умеет, включая то, что давно умеют нижележащие слои (уж что-что, а хотя бы 2x redundancy lvm умел еще полтора десятка лет назад - а эти даже и того ниасилили), просто очередное средство для мышевозюкалок, прячущее редхатовское нагромождение адских уродов - до первой поломки, разумеется. Кто уже пытался загрузить в single user редхатосистему с thin lvm - тот меня поймет. А чинить там уже и нечего будет, в случае чего. Получишь хорошо перемешанную кашу байтиков, размазанную ровным слоем по всем дискам. При желании - еще и зашифрованную. write only storage system. (c) redhatbm
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	103. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Roman (??), 08-Ноя-19, 17:44
	Вангую что это такой storage spaces из мира линукса от RH ( сам эти storage spaces руками не трогал впрочем)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	104. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 18:43
	> Вангую что это такой storage spaces из мира линукса от RH storage spaces у нас называются lvm, и существовали за много-много лет до их переизобретения MS Работали странно, надежность была стремной. В результате (в основном руками rh) всю хрень изрядно переписали, насколько сейчас ей можно пользоваться (учитывая что переписали очень многое, при этом параллельно было много чего поломано и переделано в ведре - включая прекрасную историю с blk-mq, тихо портившим данные на fs - что характерно, это нововведение уже и не выключается) - дело темное. Особенно когда поверх в качестве основной рекомендации лежит "проверенная временем" xfs, которую тоже пару раз переписали чуть ли не с нуля, потому что "проверенно" было в основном ее умение необратимо ломаться. А уровень местных "экспертов", не отличающих где шоколад, где дерьмо, потому что слаще морковки вообще не едали - к сожалению, не позволяет никому из них верить на слово. А этот stratis - всего лишь user-friendly междумордие поверх, для альтернативно-одаренных, которым их данные точно не нужны. За полтора года разработки не научился даже избыточности - хотя lvm умеет от рождения (впрочем, они, кажется, любят thin-lvm, а что этот умеет - для меня самого загадка)
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	13. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 07-Ноя-19, 22:26
	конечно, это ж орацл вам сломал использование модулями aes-инструкций процессора, это орацл, проклятущий, вам назло написал невменяемую систему управления памятью, у которой единственный объект - это страница, причем если она, вдруг, не 4k, то ничего толком не работает, это орацл пихал под локоть (сановских, что характерно - ту еще, оригинальную начинавших писать) разработчиков чтоб они сажали совершенно изумительно глупые баги, и никогда-никогда не проверяли результаты своих правок. Орацл, проклятый, во всем виноват, конечно же ж. А совсем не отсутствие сановского менеджера с палкой над горбом разработчиков, из-за которого вся разработка выродилась в последовательное ухудшение и доламывание хорошей системы, оставленной без присмотра. Он, кстати, вам еще и в шта..в btrfs нас...л, потому что это разработка, долгое время чуть ли не в одно жало делавшаяся сотрудником оракла в рабочее время. При этом те кто хотели - вполне себе zfs пользуются. Той, увы, которую мы все заслуживаем, а не той, которую по прежнему пилит себе оракл, но при закрытых дверях.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	16. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–2 +/–
	Сообщение от ilyafedin (ok), 07-Ноя-19, 22:34
	>[оверквотинг удален] > Орацл, проклятый, во всем виноват, конечно же ж. > А совсем не отсутствие сановского менеджера с палкой над горбом разработчиков, из-за > которого вся разработка выродилась в последовательное ухудшение и доламывание хорошей > системы, оставленной без присмотра. > Он, кстати, вам еще и в шта..в btrfs нас...л, потому что это > разработка, долгое время чуть ли не в одно жало делавшаяся сотрудником > оракла в рабочее время. > При этом те кто хотели - вполне себе zfs пользуются. Той, увы, > которую мы все заслуживаем, а не той, которую по прежнему пилит > себе оракл, но при закрытых дверях. Так и знал, что не пройдешь мимо и рассыпешься в большой поток сознания ❤️
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	43. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от имя (ok), 08-Ноя-19, 05:29
	> это ж орацл вам сломал использование модулями aes-инструкций процессора Ого, а Грег КХ в курсе, что он работает теперь на Эллисона?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Olololo (?), 07-Ноя-19, 22:34
	Btrfs не стала стабильной только в одной конфигурации. И то даже в этой конфигурации она или уже стабильна или в самое ближайшее время её пометят стабильной в следующем релизе.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Olololo (?), 07-Ноя-19, 22:43
	В raid-6 оно не стабильно, но обещают в следующем релизе исправить.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	33. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+4 +/–
	Сообщение от хомяк (?), 08-Ноя-19, 00:13
	«не стабльно» недостаточно точно описывает ситуацию «гарантировано разрушает пул при отключении или аварийном завершении процесса на протяжении некоего фрагмента цикла записи». И не только raid6, но и raid5.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	36. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от анонимно (?), 08-Ноя-19, 00:39
	D-BUS одна из прекраснейших технологий 21 века. Очень годная вещь сосредоточившись на управлении через неё можно забыть о фрагментации дистрибутивов и подходов. Единый API ну разве это не шикарно!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от ilyafedin (ok), 08-Ноя-19, 02:51
	> D-BUS одна из прекраснейших технологий 21 века. Очень годная вещь сосредоточившись на > управлении через неё можно забыть о фрагментации дистрибутивов и подходов. Единый > API ну разве это не шикарно! Одна и прекраснейших технологий, которая... тормозит как не в себя. Нет, не шикарно, API не должно требовать демона. Они сделали го*но и только додумались, что никакой демон не нужен, а достаточно лишь либы, которая реализует API (Varlink).
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	46. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от iCat (ok), 08-Ноя-19, 07:28
	>Требую немедленно сделать ZFS истинно-GPL'овой, встроить в ядро и принять во все дистрибутивы по дефолту. А смысл? Разные задачи - разные инструменты. Поиски единственной FS на все случаи жизни - занятие столь же безсмысленное, как поиски "универсальной операционной системы".
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	81. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от пох. (?), 08-Ноя-19, 15:13
	ну вообще-то весь смысл этого cpaтиса, прости Г-ди - это как раз заменить возможности современных fs "проверенными внутриядерными механизмами линуха". Что они проверенно умеют превращать ваши данные в кашу, причем каждый отдельно - lvm умеет, xfs умеет, про чудо-шифровалки и новые модные веяния с block cache я уж молчу - как-то случайно выносят за скобки. > Поиски единственной FS на все случаи жизни у нас пока не то что единственной нет, а хотя бы одной - приемлемо удобной и допустимо надежной. А требования к функционалу и надежности - растут, потому что прошли времена, когда ты мог сбэкапать свой замечательный сервер на пачку дискет, да еще и регулярно повторять процесс с проверкой восстановления. Сейчас его часто не на что и незачем бэкапать, и при отказе хранилки можно просто поставить на этом месте красивый крест.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	58. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Fracta1L (ok), 08-Ноя-19, 11:53
	> элегантную ZFS В голосину
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	72. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:33
	ZFS элегантна примерно настолько же, насколько эленгантен ожиревший танцор балета весом 200кг с протезом вместо одной ноги, который к тому же вдвое длиннее оставшейся целой.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
Сообщение от Аноним (3), 07-Ноя-19, 21:01
Есть истории успеха в восстановление рейда на уровне LVM? mdraid при флапе нескольких линков восстанавливается с полпинка. Аппаратный чуть сложнее. lvcreate --type raid5 при тестах восстановить не удалось.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от Аноним (7), 07-Ноя-19, 21:33
	А что такое флап линков?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	54. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (54), 08-Ноя-19, 11:00
	например вот такое: 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 находил ошибки, с монтированием проблем не было). в моем случае проблема была с кабелем (после его замены диск начал нормально работать), хотя внешний осмотр повреждений не выясвил.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	76. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:42
	Простите, но рейд и должен разваливаться при таком поведении. Флап линка - повод выбросить носитель из рейда до ручного вмешательства.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	77. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:44
	Интересно то, что md похоже по умолчанию этого не делает... и тем более - не запоминает состояния на момент отвала. Битмап-то включен, надеюсь? Если нет, ССЗБ.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	82. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 15:15
	> Интересно то, что 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 persistent        Update Time : Mon Sep  9 21:05:07 2019              State : clean, degraded     Active Devices : 5    Working Devices : 5     Failed Devices : 0      Spare Devices : 0 Consistency Policy : none               Name : (none):0             Events : 7     Number   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
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	87. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 16:13
	Ну вот у писателя выше, судя по написанному, этого не произошло. Что он там выкрутил и где - мне неведомо.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	96. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 17:06
	> Ну вот у писателя выше, судя по написанному, этого не произошло. видимо, не успело - традиционная беда линукса с несвязанными как следует между собой деталями - 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 системах.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	106. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 23:55
	multipathd настроен на пропагацию ошибок вверх по стеку вместо повторов? :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	107. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 23:56
	Или md при сборке массива нашёл суперблок не на multipath-устройстве, а на как раз том самом, которое отвалилось, и заюзал? Кстати последнее случается, реальные устройства надо из доступного md списка выкидывать первым делом.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	142. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 15-Ноя-19, 12:09
	> multipathd настроен на пропагацию ошибок вверх по стеку вместо повторов? :) у меня нет multipathd и прочих дискмаперных наворотов - поэтому и работает. То есть там голый in-kernel md поверх физического multipath, который он сам собирает из отдельных дисков, и сам - разбирает, если вдруг путь отваливается. При этом схема проста как палка, и ломаться в ней особо нечему (пока альтернативно-одаренные не запустят свои корявки в "неэффективный и устаревший" код md-multipath, и оно не приедет с пылу, с жару в "LTS" версию системы, но, я очень надеюсь, что это уже после моего увольнения или смерти произойдет) systemd иногда не может загрузиться, но это не фатальная проблема.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	109. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (109), 09-Ноя-19, 08:11
	bitmap включен, возможно поэтому диск и не вылетел из массива (но проверять с отключеным не хочу).
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	11. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от ананим.orig (?), 07-Ноя-19, 21:56
	на данный момент (а это уже лет 10) lvm - это всего-лишь комбинация тех или иных преднастроенных вызовов к dm. фактически как сабж, но без дбаса и с рэйдом.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	34. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от хомяк (?), 08-Ноя-19, 00:15
	однако инструментов для аварийного ковыряния в пуле не имеет. А инструменты от dm-* не подходят, потому что это хоть и dm* глубоко в душе — но снаружи всё же не dm*.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	61. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (54), 08-Ноя-19, 12:10
	эм... а какие инструменты вам нужны? и какие есть у zfs? lvm/mdadm/cryptsetup - это обертки над dmsetup, но вам никто не мешает в существующий lvm лезть руками при помощи dm-утилит (на свой страх и риск разумеется). из моей практики, у меня были проблемы с lvm, но мне его родных утилит хватило для восстановления. поделитесь своим опытом, когда lvm-утилиты не справились?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	31. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (31), 08-Ноя-19, 00:05
	> нескольких линков если вы несколько дисков отключили от raid 5 то восстановить его будет нельзя.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	62. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (54), 08-Ноя-19, 12:10
	флап != отключение.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	88. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 16:14
	> флап != отключение. При нормальной работе нормальной системы флап должен == отключению, за исключением единственного случая - когда от отключения до подключения не было записи, да и то нежелательно назад подключать. В противном случае последствия непредсказуемы.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	110. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (109), 09-Ноя-19, 08:18
	это в идеале. а еще raid1 на чтение должен читать с обоих дисков и в случае несовпадения данных или ошибок чтения выдавать предупреждение, а по факту mdadm raid1 (возможно и другие, но за этот ручаюсь точно) при чтении из raid1 массива использует методику raid0 - данные читаются попеременно с обоих дисков (для увеличения скорости), и если на одном диске есть badblock на который никогда не попадает чтение, то такой диск не будет выброшен из массива, а когда накроется его сосед будет уже поздно. увидеть это можно на практике при помощи fio, но не помню деталей (вроде чтение из массива raid1 из двух дисков равняется удвоенной скорости чтения с одного диска при половинной очереди, которая использовалась для теста массива, т.е. ядро разбивает запросы на два потока и направляет их на два диска, если бы это было не так - чтение с массива не отличалось бы от чтения с одного диска, если диски одинаковые).
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	112. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 09-Ноя-19, 10:40
	По факту аппаратные рейд делают так же, а для сверки данных и обнаружения дохлых блоков есть скраббинг. В mdadm он тоже настраивается, кстати.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	113. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 09-Ноя-19, 10:40
	// рейды // в md (по ночам надо спать...)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	111. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (109), 09-Ноя-19, 08:57
	нет, почему же? могу говорить только за mdadm, но отключение двух и более дисков из raid5 (на горячую) не убивают массив безвозвратно: доступ к данным массива теряется (io error на read/write), по /proc/mdstat видно что несколько дисков отсутствуют, перезапуск массива (mdadm --stop/mdadm --assemble --scan) результата не дает - массив все так же игнорирует отключеные диски (даже если они уже в системе), но mdadm --assemble --force - проблему решает, mdadm забивает на разные timestamp'ы у дисков одного массива и собирает их - массив можно дальше использовать. естественно данные, которые записывались в момент сбоя могут быть неполные, но все данные при этом не теряются.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	79. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:47
	> mdraid при флапе нескольких линков восстанавливается с полпинка RAID5? При флапе нескольких линков? Я очень сомневаюсь, что на том, что там восстановилось, данные будут корректны - при условии, что в момент отвала шла какая-то запись, естественно. Вылет двух дисков в RAID5 - это фатал.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	85. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 15:26
	ну так ты продожай тут постить fud про zfs, не владея темой от слова нихрена. У которой флап (а не тотальный отказ) любого количества дисков в raidz1 - ведет всего лишь к потере последней не синхронной операции записи и необходимости ручного переподключения. Вот такие вот чудеса, с 2004го года. А у тебя сразу п-ц и фатал, и непонятно, какие данные испортились, и как их отличить, но ты продолжай рассказывать какая плохая zfs, как не нужны чексуммы, и как все хорошо и замечательно у л@п4@тых в их поделках. P.S. поздравляю Максима с новой победой г0вноробота над людьми. А на новость про lizard времени так и не нашлось. P.P.S. mdadm таки переживет флап и с raid5, но гарантии что потом хваленый xfs восстановится родными утилитами нет никакой, разумеется.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	86. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 16:11
	raidz1 raid5 FUD ... слов нет ... речь не про дублирующий рейд, да и там флап двух дисков (если дублей 1 штуко) - фатал А вообще в любом нормальном отказоустойчивом хранилище флап диска - это повод выкинуть диск до ручного вмешательства.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	92. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от пох. (?), 08-Ноя-19, 16:50
	> raidz1 > raid5 > FUD > ... слов нет ... речь не про дублирующий рейд, да и там Наш всезнайка еще и не в курсе что такое raidz. Это не "дублирующий рейд", так, на минуточку. mirror у zfs называется, внезапно, mirror. Но мнение при этом про zfs - он имеет, ага. > флап двух дисков (если дублей 1 штуко) - фатал нет. Флап в нормально спроектированных системах - просто флап. Моргнуло, терабайты данных от этого не должны мгновенно аннигилироваться. > А вообще в любом нормальном отказоустойчивом хранилище флап диска - это повод > выкинуть диск до ручного вмешательства. именно так и происходит. Но одно дело, когда ручное вмешательство - просто вручную выдать команду attach или перезагрузиться в надежде на автоматику, а потом проверить консистентность дисков, совсем другое - когда ты сидишь перед рухнувшим dm, и не знаешь, как его теперь собрать обратно, а stackoverflow недоступен из-за аварии у оператора.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	94. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 17:00
	> Флап в нормально спроектированных системах - просто флап. Моргнуло, терабайты данных Ну давай, расскажи мне про нормально спроектированные системы, где так происходит. Желательно с названиями. Терабайты данных от этого никуда не деваются, диск вылетает, остальные работают. Если есть резерв - начинается копирование на резерв. > рухнувшим dm Так не надо его заставлять работать с выпавшим диском после флапа, и он никуда не денется. Да и md назад собрать - не бог весть какая затея, достаточно man с машины не удалять. Стэковерфловы - удел девляпсов.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	99. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от пох. (?), 08-Ноя-19, 17:08
	> он никуда не денется. Да и md назад собрать - не бог весть какая затея md - да. А как насчет dm-raid? (по понятным причинам, первый использовать, к сожалению, не стоит)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	100. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 17:14
	> md - да. А как насчет dm-raid? > (по понятным причинам, первый использовать, к сожалению, не стоит) В смысле первый не стоит? Как раз таки второй aka fakeraid использовать не стоит. Если используется - все вопросы к биосу.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	101. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 17:16
	Ну и грань между ними так себе, в общем случае dmraid банально надстройка над md, объясняющая как унылые биосовые массивы собирать.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	97. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 17:07
	Чтобы иметь мнение насчёт несъедобности говна, пробовать его на вкус вовсе не обязательно.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	102. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 17:21
	> Чтобы иметь мнение насчёт несъедобности говна, пробовать его на вкус вовсе не обязательно. чтобы это мнение имело ценность - надо иметь либо обоняние, либо хотя бы зрение. А ты, увы, судя по невладению даже базовой терминологией - слышал в перепеве Рабиновича непонятно что и о чем.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

5. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
Сообщение от SOska (?), 07-Ноя-19, 21:09
И чем эта смузирастахрень лучше lvm?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+3 +/–
	Сообщение от ананим.orig (?), 07-Ноя-19, 21:51
	ничем. это фронтэнд.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 07-Ноя-19, 22:47
	который не умеет даже mirror
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	20. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от Аноним (20), 07-Ноя-19, 22:47
	Так написано же: Проект изначально преподносится как не требующий для администрирования квалификации эксперта по системам хранения. Пора редхету начать выпускать домашние аэс, не требующие квалификации эксперта.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	49. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от SOska (?), 08-Ноя-19, 08:54
	Чес слово для mdadm и lvm не надо быть гением
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	63. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (54), 08-Ноя-19, 12:11
	при создании нет, но при нештатных ситуациях, нужно уметь их исправлять.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	68. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 12:44
	> при создании нет, но при нештатных ситуациях, нужно уметь их исправлять. ты правда думаешь что dbus-поделка что-то умеет - исправлять? Ну и про создание - пожалуйста, список команд для ручного создания xfs over thin-lvm (потому что мы, наверное, все же хотим lightweight-снапшоты) в студию, не подглядывая в стековерфлоу. шит-криптографию и redundancy, чорт с ними, пока пропустим.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	114. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 09-Ноя-19, 10:45
	> при создании нет, но при нештатных ситуациях, нужно уметь их исправлять. При нештатных ситуациях подобные управлялоподелки разваливаются первыми.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	26. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+2 +/–
	Сообщение от Аноним (26), 07-Ноя-19, 23:14
	Я читал их документацию. Они собирают из кучи подсистем ядра (dmcrypt llvm xfs and friends) 5 слоев абстракции и управляют этим всем через ОДНУ утилиту в юзерспейсе. На выходе должна получится та же ZFS, только построенная на старом надежном функционале встроенном в ядро линукс. Вот только ZFS-фичи начнутся с версии 3.0. А еще, мне очень интересно, что случится с пулом если этот демон "внезапно" умрет (скажем от ommkiller-a), а система продолжит работать...  а потом, как произойдет перемещение пары тройки терабайт пропадет питание. Хорошо что у меня есть бекапы.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	32. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от Аноним (31), 08-Ноя-19, 00:11
	> 5 слоев абстракции Ещё интересно как это всё будет работать при обновлении ядра или утилит, с учётом "stable api nonsense". Если конечно у них вообще есть планы развивать это, а не делать эксклюзивно для redhatibm.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	93. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 16:54
	>> 5 слоев абстракции > Ещё интересно как это всё будет работать при обновлении ядра или утилит, > с учётом "stable api nonsense". Если конечно у них вообще есть ну типа, чем дальше ты от "nonsense", тем безопаснее. То есть обновления ядра не затронут это чудо совсем, а при обновлении dbus скорее всего отвалится управление, но не развалится fs. А если ты так обновился, что в /sbin/lvm код несовместим с dm-*.ko - это, вероятно, либо очень кривой дистрибутив, либо нефиг лезть руками в сложные системы без понимания что и от чего тут зависит. Это тебе не "мы тут в новой версии запретили aes", и модуль не грузится и не компилируется.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

23. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
Сообщение от IdeaFix (ok), 07-Ноя-19, 22:55
т.е. refs таки всех победил?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–2 +/–
	Сообщение от пох. (?), 07-Ноя-19, 23:44
	лежа в гробу? Вряд ли... что-то перспективы ms'овских стораджей сегодня выглядят еще более сомнительными чем перспективы йежа.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	117. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от IdeaFix (ok), 10-Ноя-19, 12:46
	> лежа в гробу? Вряд ли... что-то перспективы ms'овских стораджей сегодня выглядят еще > более сомнительными чем перспективы йежа. Вы не поверите, но и МСовских гипервизоров и МСовской гиперконвергенции несколько больше, чем всяких проксмоксов и пр. вместе взятых...
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	118. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от пох. (?), 11-Ноя-19, 07:28
	не поверю. Где они, блжат? У MS в ажурном облачке? Проксмоксу видел, от наколенных поделок в конторе на пятнадцать страдальцев (с затолканым туда же фринасом, ховнклаудом и фрипое6иксой, как тут кто-то гордился) до довольно больших (где реально ссыкотно как оно все еще вообще не навернулось) Впопенштифт, с ceph и вот этой всей херней, настроенный методом next-next-next без малейшего понимания чем чревато - каждый день вижу, с..ные аутсорсеры. Про кластеры из г-на и палок (в смысле гластеров/прочих хреньфс) - ну живьем не видел, кроме собственных экспериментов, но слышал и читал - дохрена. У кого-то даже и работает, пока еще. Даже вмварьскую vsan видел (да, п-ц, непонятно ни зачем, ни как они вообще еще живут - но есть). Винду - не, не видел. При том что винда - везде, а вот эти линуксоподелки из дерьма и палок - очень местами и временами, и я еще и сознательно держусь от них как можно дальше, чтоб чинить не припахали. У всех в этом "везде" почему-то обычные san-стораджи, иногда в обертке какой-нибудь виртуализации, иногда просто так. То есть вот если для линукса еще десять лет назад было _общим_ решением - "ставимся на машину с двумя дисками - включаем lvm с --mirrors 2, если железным рейдом обделили", то увидеть винду с включенным storage space (что можно было до недавнего времени в любой десяточке любому васяну) - ни разу. Васяны не в курсе, а остальным, видимо, не надо.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	137. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от IdeaFix (ok), 13-Ноя-19, 22:51
	Практически все крупные ВУЗы, некоторые "типы" крупных госконтор и пр. оченно аквтивно используют гиперв. Просто гиперконвергенция от МС получается куда дешевле и понятнее гиперконвергенции от DELL-EMC даже на том же самом железе. И если дедупликацию от EMC мало кто на поде юзал, то тут есть шанс... Сам удивился как много в мире этого добра. Как много аутлук веб аппа и соответственно известного почтовика, как много ИИСа на проде наружу. Работает как-то. А азура нет... там другое.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

39. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
Сообщение от Аноним (39), 08-Ноя-19, 02:17
Как там насчёт интеграции с systemd?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Аноним (53), 08-Ноя-19, 09:51
	systemd-stratisd
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	69. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 12:46
	> Как там насчёт интеграции с systemd? без него ты даже не подключишь thin-раздел. Такие вот пирожки с крысятами :-( P.S. буду рад увидеть инструкцию, опровергающую это утверждение. Чур - лично проверенную.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

45. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
Сообщение от Аноим (?), 08-Ноя-19, 06:59
> Значительное изменение номера версии связано с переименованием некоторых интерфейсов D-Bus и переработкой организации работы с D-Bus Вот это кстати, очень показательно: разрабы D-Bus занимаются "перестановкой кроватей" а все, чей софт от этого дибаса зависит, вынуждены эту имитацию деятельности отслеживать и переделывать свои проги. PS: Поигрался с этим стратисом: простой, удобный, ненужный. Как-то так)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	52. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+3 +/–
	Сообщение от Аноним (53), 08-Ноя-19, 09:54
	>разрабы D-Bus занимаются "перестановкой кроватей" Или удовлетворением требований не использовать оскорбляющие чьи-то чувства имена.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

57. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+3 +/–
Сообщение от mumu (ok), 08-Ноя-19, 11:27
> Значительное изменение номера версии связано с переименованием некоторых интерфейсов D-Bus и переработкой организации работы с D-Bus Обновил дебас - развалился кластерный рейд. Энтерпрайзненько так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от Аноним (54), 08-Ноя-19, 12:14
	ну, пользователям mdadm/lvm этого не понять.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	70. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+1 +/–
	Сообщение от пох. (?), 08-Ноя-19, 12:47
	> ну, пользователям mdadm/lvm этого не понять. ну да, невостановимый отвал стораджа при смене hostname (внезапно, фича начиная с rhel7) - это ж мелочи жизни.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	78. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 14:46
	> невостановимый отвал стораджа при смене hostname Щито, простите? Или вы смогли так кластерный сторейдж завалить? Если да - я вас поздравляю, к кластерам вас лучше не подпускать.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	84. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от пох. (?), 08-Ноя-19, 15:21
	>> невостановимый отвал стораджа при смене hostname > Щито, простите научись пользоваться гуглем, неумешка. А то можешь оказаться в один непрекрасный день в очень неприятной позе, вместо любимой позы всезнайки.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	89. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 16:15
	Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет, и прекрасно знаю, где соломку подстелить, чтобы оно не рассыпАлось.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	90. "Выпуск Stratis 2.0, инструментария для управления локальными..."	–1 +/–
	Сообщение от Онаним (?), 08-Ноя-19, 16:17
	Если ребята на кластерах додумались хостнеймы менять бездумно и всё завалить - это вообще непонимание базы, неумение читать доки, ССЗБ и ЛПП, а не проблема RHEL.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	108. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от J3 (?), 09-Ноя-19, 08:04
	Hostname не должен влиять на что-то отличное от сетевых настроек/служб и т.п.. Если при его изменении волится сторадж, то на лицо явная ошибка проектирования конечных софтин.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	91. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от пох. (?), 08-Ноя-19, 16:44
	> Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет, next-next-next нажимаешь? Ну, ок. > прекрасно знаю, где соломку подстелить, чтобы оно не рассыпАлось. непохоже. Больше похоже что пока - проносило. P.S. что характерно - пользоваться поисковиком пациент не умеет.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	95. "Выпуск Stratis 2.0, инструментария для управления локальными..."	+/–
	Сообщение от Онаним (?), 08-Ноя-19, 17:01
	>> Тьфу-тьфу, я с 5-6-7-8 и разнотипными сторейджами работаю уже много лет, > next-next-next нажимаешь? Да, в голой консоли пишу next, и после пальцем на несенсорный экран там, где написал, нажимаю.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

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

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