Реализация файловой системы ZFS в основной ветке FreeBSD (HEAD) переведена на использование кода OpenZFS, развивающего кодовую базу "ZFS on Linux" в качестве эталонного варианта ZFS. Весной поддержка FreeBSD была перенесена в основной проект OpenZFS, после чего в нём была продолжена разработка всех связанных с FreeBSD изменений, а разработчики FreeBSD получили возможность оперативно переносить в систему все новшества, развиваемые проектом OpenZFS...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53594
ZFS on Linux, которому не светит попасть в Linux. Забавно.
А какая альтернатива ?
Утки!
Уу
Ну, все вроде поставляют ZoL. В ядро линукса она не попади последовать общему примеру и не пытатёт, но это не так уж важно.
Пытаюсь понять что ты написал.
Виталий К - залогинтесь!
ПыСы не только лишь все))
В Убанте он уже из коробки поставляется, а жопные боли мейнтейнеров ядра не то чтобы кого-то сильно волнуют.
да-да, да так там прекрасно работает, что в случае чего после обновления ядра систему иногда приходится чинить, если root на zfs, если приводить пример, то хотя бы NixOS или Proxmox, которые действительно следят за такой конфигурацией при выкате обнов...
Ну как бы всегда рекоменуется под рут ставить "классическую" ФС, а не экзотику.
Мне кажется, что достаточно /boot держать на ext3/ext4 и проблем не будет.
Я, например, всегда /boot на отдельном ext3 разделе держу.
> Я, например, всегда /boot на отдельном ext3 разделе держу.Полагаю, EFI не используете? Из-за него приходится в FAT держать этот раздел.
С lts-веткой проблем не будет. Если же гнаться за свежим ядром, то определенно настанет момент, когда модуль zfs под него не собереться.
> С lts-веткой проблем не будет. Если же гнаться за свежим ядром, то
> определенно настанет момент, когда модуль zfs под него не собереться.Товарищи выразили мнение минусами, а между тем если вникнуть в то, о чём я говорил, то станет понятно, что вовсе не о том, как плох ZFS на линуксе (он у меня много где), и не о том, какие юзеры ССЗБ, а о том, что компания добавила функционал, заявив мол пользуйтесь! всё работает! а на деле люди столкнулись с проблемами, которые были легко выявляемы если бы на тестовых стендах у них стояли конфигурации с вариантом когда root на ZFS, т.е. Canonical дала функционал и нифига не отслеживала качество его работы!.. Камень был именно в этот огород..
У мэйнтейнеров ядра нет жопных болей, потому что ZFS не свободна.
ZFS свободна и более свободна чем вирусный GPL. Проблема в несвободности linux kernel.
Линуксовое ядро свободно - для кого надо свободно. Как хромиум. Хомячкам также предоставляется полная свобода жрать с лопаты, что туда навалили корпорасты. Хошь сустемду жуй, хошь bpf.
А как в zol реализовано вытеснение arc? Если системе понадобится память
> А как в zol реализовано вытеснение arc? Если системе понадобится память#ifdef illumos
[вытесняем arc]
#else
crash
#endifНо есть два прекрасных костылика и четыре подпорочки, позволяющие тебе зарезервировать неиспользуемую память, чтобы она пропадала впустую, пока не понадобится системе - и ни в коем случае не могла использоваться под кэш.
notabug. wontfix.
Arc умеет возвращать память, но происходит это не моментально. Лучше ограничит zfs_arc_max до разумных пределов опираясь на статистику arcstat в рабочих нагрузках. Использую дома с пределом в 4G. С десяток виртуальных машин. Летает как ракета!
До первого oлoлo и потери всех твоих виртуалок. Это же ZoL и линукс, иначе быть не может.
> До первого oлoлo и потери всех твоих виртуалок. Это же ZoL и линукс, иначе быть не может.может. если не нагружать и не хотеть необычного.
А вот если нагружать - 64x write multiplication, жор памяти, и прочие прелести - нет, не фатальные, для файловой системы - но вполне могут быть фатальными для того, что ты поверх держишь, поскольку оно перестанет успевать и лопнет, когда могло бы на том же железе работать с шестнадцатикратным запасом мощности.
Проблема усиления записи решается правильно выбранным размером записи.
> Проблема усиления записи решается правильно выбранным размером записи.во-первых не решается, а загоняется под ковер.
Во-вторых у стандартного размера есть архитектурные причины.В-третьих, 64x это очевидно полный п-ц, и скорее всего ты не сумеешь выбрать единственноправильный размер.
А вы точно в теме? Несете какую-то бессмыслицу.
> А вы точно в теме? Несете какую-то бессмыслицу.обычно это означает что не в теме - другой оппонент. Настолько, что не в состоянии понять, что ему говорят.
Продолжайте верить что "волшебный" размер записи спасет вас от всех бед на свете, не буду отвлекать.
_разумный_ предел - это как раз вся неиспользуемая в данный момент системой память - за вычетом совсем малого куска на срочные-срочные нужды (он спасает от дидлоков). Как это, собственно, делает ядро с buffer cache - свободно на мало-мальски нагруженной машине не больше 1%
Непатченная zfs (и тем более ZoL) положат тебе систему до перезагрузки ресетом при таких настройках - проверено.(ZoL еще и имеет бесконечные проблемы с тем самым buffer cache, ради их решения там много чего попортили и так и не решили окончательно - двойное кэширование никуда не делось)
"разумный предел" по документации (тому недоразумению что вместо) - половина оперативной памяти.
Что полный бред.
Тот момент, когда точно "на", а не "в".
в линукс не светит, а в убунту и дебиан уже попало.
В Ubuntu 19+ его можно из коробки на корень ставить, там есть свой демон zsys, который интегрирован с apt (снапшоты), да и docker тоже zfs storage умеет.
Да, это все еще тестовое, но по сравнению с тем что было пару лет назад это огромный шаг.
> Да, это все еще тестовое, но по сравнению с тем что было пару лет назад это огромный шаг.не вижу разницы - использовал подобную конструкцию с 18го года, на lts, и померла не от zfs.
Да, надо следить что оно творит при обновлениях - но это не специфично для zfs
Так лол ZFS on Linux, а код то сановский и лицензия CDDL
мне так помнится хоронили мертворожденный ZoL вдоль и поперек...
а тута вот оно как михалыч....
Ну, фрю тоже хоронят, а у них скоро и системд будет и всё такое :)
systemd это хорошо, сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать
О, маркетинговые заклинания от РедХет!СистемД придумали для тупых, которые ленятся даже основы построения инфосистем изучить. Ну и дело идёт к связыванию пользовательских машин в распределённое облако, не беспокойтесь, вкрутят и не пискните. А "тысячи глаз", как водится, сразу ослепнут.
СистемД -- для плохих и глупых людей.
systemd - это прекрасно.
Хотя бы тем, что кривые-косые скрипт-портянки инициализации больше не нужны.
Тем, что есть система состояний, которая отслеживает реальное поведение процессов.
Да, там много лишнего, но базовая функция - упрощение конфигурации инициализации - выполняется "на ура".
>Да, там много лишнего, но базовая функция - упрощение конфигурации инициализации - выполняется "на ура"."Что то тут много лишнего" - подумала мышь залезая в мышеловку,
"но ведь как все упрощенно чтоб добраться до сыра !" - продолжала восхищаться мышь...
Чем этот миллион кривых строк на сях лучше runit?
> Чем этот миллион кривых строк на сях лучше runit?Тем, что им реально можно пользоваться.
Боже, хоть от freebsd отстаньте со своим systemd поганым, наркоманы, чОртовы.
> Боже, хоть от freebsd отстаньте со своим systemd поганым, наркоманы, чОртовы.Да мы к нему и не пристаём. Ну, знаем, что есть такая поделка, но на практике связываться смысла нет.
теперь эти костыли перенесли в код systemd - там их столько что ...
одна привязка d-bus чего стоит.
> ... кривые-косые скрипт-портянки инициализации больше не нужны.полагаю, Вы про при линуховые портянки. ибо сдаётся мне, что фришные Вы не видели. в 500 байт (с комментариями), как правило, вмещается описание сервиса.
> полагаю, Вы про при линуховые портянки. ибо сдаётся мне, что фришные Вы не видели. в 500 байтя тоже полагаю, что он про линуксовые. ибо функционал фришных настолько убог, что сложно представить себе там хоть какие-то портянки. разве что портянки в комментариях...
>Тем, что есть система состояний, которая отслеживает реальное поведение процессов.monit? =)
а на деле всего 2 состояния - процесс есть, процесса нет.
и справлялись с этим прекрасно с 1970 года.
> а на деле всего 2 состояния - процесс есть, процесса нет.С состояниями-то всё просто. А вот со своевременной на них реакцией, желательно без говнокода на баше...
Получите и распишитесь гонку между запуском monit и инициализацией процессов, которые он будет мониторить.
Почему? Переплетение глистных sh-скриптов, в которых вообще ничего не разберёшь, по-моему, куда хуже.
Это только на Linux так было. rc.d (NetBSD, потом FreeBSD) скрипты декларативны.
> Это только на Linux так было. rc.d (NetBSD, потом FreeBSD) скрипты декларативны.Угу. И чтобы добавить в них трекинг демонов с автоперезапуском - надо или каждый говноскрипт держать в фоне, или плодить ещё говноскриптов.
Зачем пользовать говнодемоны, которые падают?
О-вэй, линухвэй? - Спасибо, не надо.
> Зачем пользовать говнодемоны, которые падают?К сожалению, таковы современные реалии, что делать это надо. Балансируем понемногу.
> Зачем пользовать говнодемоны, которые падают?Вы пишете идеальный софт?
Упало - собрать бектрейс и всё прочее, например через abrt, поднять заново.
А зачем это в системе инициализации ?Пусть этим занимается сервис - например monit
А теперь нам надо сокет-активацию.
xinetdА теперь нам надо бы ещё при падении убить зависимости и поднять заново.
А теперь нам надо бы зависимость от монтирования FS.
А теперь нам надо бы зависимость от...
А теперь наш конкретный демон с monit не работает, pid-файла у него нет, форкается не совсем стандартно.
А теперь нам бы убить целую пачку процессов при падении основного.И начинается костыляние тучами "сервисов".
> Угу. И чтобы добавить в них трекинг демонов с автоперезапуском - надо
> или каждый говноскрипт держать в фоне, или плодить ещё говноскриптов.Еще хуже - нужно ЧИТАТЬ документацию, а не просто придумывать "как оно должно быть устроенно, если брать за эталон вендочку!".
man fscd
NAME
fscd – service state monitoring daemon
DESCRIPTION
The fscd FreeBSD, service control daemon, is a service which monitors
states of other services and attempts to restart them if they die.
Так, костыль к init засчитан.
В systemd этого костыля нет, слежение за процессами - часть самой системы инициализации.
В общем-то там и место.
>Угу. И чтобы добавить в них трекинг демонов с автоперезапускомmonit? не, не слышал =)
> monit? не, не слышал =)Ну вот, начинаем костылять.
systemd позволяет обходиться без говноскриптов и говнокостылей в фоне.
> Ну, фрю тоже хоронят, а у них скоро и системд будет и всё такое :)А кто этим заниматься будет? Попытка перенести launchd закончилась тем, что нет разработчиков.
Только если Поттеринг лично займется.
На это были разработсики, и даже было несколько однотипных реализаций, просто оно никому нахрен ненужНО во фре!
> просто оно никому нахрен ненужНОпросто онА никому нахрен не нужнА, ты хотел сказать
Да лана. Третья попытка присесть на линуховый десктоп возвращала на фрю - шо хочу, то и ворочу. От шапков с поцтерингами и каканикалами не зависеть - сплошная радость.
И те и другие не нужны когда есть нормальная, человеческая эталонная реализация в солярке. Не в опен солярке и ее отростках, а в правильной, закрытой./thread
О да, яб даже согласился, но... Есть одно но - сама солярка напоминает хорошо протухшего кадавра.
Как вообще можно называть правильной закрытую реализацию ?
Тебе конпелять или чтобы работало? 🤣
Мне и то, и другое.
Или без обрезания вам ну никак? Понимаю.
Посоветуйте, пожалуйста, современный браузер для нее
Зачем тебе браузер на сервере с дисковыми полками?
а зачем тебе закрытая ось когда есть открытая...
Вот именно
Если в приоритете стабильность и надежность то закрытая без вариантов. 🤗
И вот теперь расскажи это портворксу, который основой для своей закрытой хранилки выбрал открытую бтрфс. И деллу, который за основу взял люстру+ext3.
А им твои данные, походу, ни разу не жалко.> И деллу, который за основу взял люстру+ext3.
Серьезно? Нет, в целом там феерических м-ков хватает, но этот выбор антитехнологий - просто второе место на конкурсе м-ков за каждую, и еще раз, почетное второе место - за уникальнейшее умение выбрать обе сразу.
И почему они тогда твоими услугами не пользуются, если ты такое умное всё из себя?
А почему и твоими не пользуются, если ты считаешь себя даже умнее?Правильный ответ, полагаю, прост: они вообще не нуждаются в хороших специалистах (нуждаются, но в хороших специалистах по продажам).
Им твои данные совершенно не нужны - им нужны твои деньги.
Я, возможно, когда-нибудь выложу весеннюю переписку с такими - там все прекрасно, и настойчивое желание немного денег с меня поиметь, и полный факап по всем техническим (и даже организационным - но с технической стороны) вопросам.
Насчет схавает ли рынок такое - дело темное. Он может и не схавать - ну подумаешь, инвестор "зафиксирует убытки", пойдут другое фуфло на коленке сочиненное продавать.
Но вот у тех ребят - схавал. Подтвержденная потеря всей хранилки? Да и похрен.
Ну так, проникни к "ним" как продажник и научи уму-разуму! На опеннете трындеть все гаразды.
> Ну так, проникни к "ним" как продажник и научи уму-разуму!ты-то, надеюсь, уже?
А я на откровенных м-ков предпочитаю не работать.
Я бы не стал приводить Dell как эталон адекватности и технологичности.
P.S. Как обычно, никого не хочу обидеть и все это мое личное предвзятое мнение.
А подробнее можно ? С каким именно железом или софтом ?
Как-то вот именно с Dell всегда было значительно меньше проблем, чем с CISCO UCS, например.
С массивами тоже всё вполне неплохо.
Про сетевое оборудование ничего не могу сказать т.к. не работал.
>люстру+ext3А могли бы взять бтрфс! Терять так терять! Или ещё лучше, ceph, на котором пару лет назад один крупный хостер проcpaл все свои виртуалки. 😂
Ты понимаешь что приводишь в пример совсем криворуких товарищей?
это потому что не купил сапорт у redhat! RedHat Storage (в девичестве ceph) такого не позволит!
А разве не gluster?
gluster. И это п-ц полный.но ceph они тоже продают, как в составе впопенштифта, так и отдельно, там какое-то другое название.
"google: unable to import zpool - что делать, АААААА!"
Гугл говорит что это проблема из ZoL. Не по адресу, дорогуша. 😂
https://docs.oracle.com/cd/E26505_01/html/E29493/fhknh.html> System Reboots Continuously Because of a ZFS-Related Panic (15809921)
Снова мифотворцы опростались прилюдно
> Зачем тебе браузер на сервере с дисковыми полками?Превьюхи страниц формировать, например
А какая именно у тебя из соляр? Я вон в опениндиане один из распоследних, уже растаманских огнеглистов видел. Вроде менее полугода отставания, но сходу версию не припомню.
> А какая именно у тебя из соляр? Я вон в опениндиане один
> из распоследних, уже растаманских огнеглистов видел. Вроде менее полугода отставания,
> но сходу версию не припомню.Это хорошо, но речь о сабже
Извиняй, не понял. О каком сабже? Проприетарная солярка? Если да, то попробуй бинари из опениндианы скопировать, может заведутся. У меня нет ни одной из них, потому не проверял.
> Извиняй, не понял. О каком сабже? Проприетарная солярка? Если да, то попробуй
> бинари из опениндианы скопировать, может заведутся. У меня нет ни одной
> из них, потому не проверял.О , спасибо, интересная мысль, хотя, возможно, придется и либы тащить (лучше уж тогда всю систему сборки сразу)
>Посоветуйте, пожалуйста, современный браузер для нееИспользуй FreBSD дистрибутив FuryBSD с KDE PLASMA https://www.opennet.ru/opennews/art.shtml?num=51821
п.с. все те же браузеры что в этом вашем линуксе.
А, это тот который из-под вантуза разрабатывают? Смотрите видео в статье.
Нет, браузеры там не все. Ungoogled-chromium и Palemoon отсутствуют.
> А, это тот который из-под вантуза разрабатывают? Смотрите видео в статье.
> Нет, браузеры там не все. Ungoogled-chromium и Palemoon отсутствуют.А во фряхе самой ни есть ;)? Все-таки превратить ее в какой-то десктоп - дело не очень многих минут
>Ungoogled-chromium и PalemoonПервое - странное удовольствие, лучше взять обычный. Второе - вообще нeнужнo-джекпот, тормозное уг не поддерживающее последние стандарты. Лиса есть квантовая, что тебе ещё надо.
> И те и другие не нужны когда есть нормальная, человеческая эталонная реализация в солярке.а тебя совсем не смущает тот факт, что авторы "нормальной-эталонной" предыдущие десять лет получали зарплату - от Дельфикса, а имена "разработчиков" орацла вообще никто не слышал?
И при этом даже trim ниасилили.
Я не знаю уже, куда от этого п-ца бежать. На марс на бочке под управлением андроида - идите нах.
Что-то мне как-то ссыкотно, Дэвид Блейн. Испортят ведь бедную ZFS своими пингвиньими лапками, как пить дать испортят! :(
Ну не без этого... Хотя XFS вроде не сильно пострадала с другой стороны.
И в конце-концов для особо крaсноглазых есть вечно нерабочая btrfs...
Нельзя испортить то, что уже испорчено безнадежно.И пингвиньими лапками там не делается ровно ничего - портят все в угоду текущим дуновениям ветра совершенно правильные пацаны - те самые, что (вроде бы) и писали когда-то еще на сановской галере. Но то ли надсмотрщик там лучше кнутом махал, то ли место было намоленным...
В принципе, вся суть завершившейся подковерной битвы - продавцов дерьмонаса оттерли от управления проектом. Причем те, хотя и отвечали notabug и копипастили из апстрима всякую дрянь, ниасиливая полезных мелочей - ничего сами по своей инициативе не ломали. Правда, и не чинили.
на очереди ядро
> на очереди ядро
>> OpenZFS brings together developers and users from various open-source forks of the original ZFS on different platforms and we're always looking to grow our community.
>> OpenZFS was announced in September 2013 as the truly open source successor to the ZFS project. Our community brings together developers from the illumos, FreeBSD, Linux, macOS, NetBSD, and Windows platforms,
>> OpenZFS is an advanced file system and volume manager which was originally developed for Solaris and is now maintained by the OpenZFS community. This repository contains the code for running OpenZFS on Linux and FreeBSD.На очереди очередная опеннетная битва перепончатых за кубок Петросяна?
Ты давай через systemd не перескакивай, ядро будет финальным аккордом.
СистемД и будет ядром и будет называться сисдром.
>> поддержка алгоритма сжатия ZSTDЭто когда же в OpenZFS появилась "поддержка алгоритма сжатия ZSTD" ?!.
в changelog 0.8.2 - 0.8.4 я таких сообщений не видел, а до 0.8.2 такого функционала точно не было...
https://github.com/openzfs/zfs/pull/9735
Просто п-ц какой-то. Начиная от реализации "мы не хотим отдельной пропети, но она нужна, поэтому мы ее размажем по метаданным" (что это было, блжад?) и заканчивая "ну тут библиотека, которую втащили целиком без ревью, лопается по стеку, но мы (сегодня) уверены что мы эти части не используем".В общем, типичный пример как раз того, чем плоха разработка от дельфиксов. Невменяемая помойка, слепленная из того что было под рукой. Причем не проходящая где-то по границам хорошо отлаженного и понятного кода, а норовящая влезть во все возможные и невозможные места, делая ни fs, ни код несовместимыми в принципе на каждом новом "улучшизме".
Вы постоянно всё хаите. zfs, xfs, ext3 — это то, что я сам читал в Ваших ответах. Так какая файловая система сейчас по Вашему оптимальная для продакшена на файловом сервере? Именно файловая система. Бекапы, снапшоты, кластеры и прочее — это отдельный разговор.
хнык-хнык... Сам хотел бы знать.Но можно для начала уточнить - что есть "продакшн", что такое в нем "файловый сервер", [зачеркнуто: и кто отвечать потом будет] ?
А то вынос за скобки кластера - как-то несколько удивляет. А подвальная файлопомойка вряд ли "продакшн" который вы имели в виду?
У меня вот на работе вполне себе продакшн, кластеры, терабайты сложноуложенного мусора - на винде 2012 (то есть голый виндовый кластер, поверх промышленной схд, не sds - сильно устаревшее, может не самое надежное, но уже хорошо знакомое решение).
С одной стороны - я всю эту этажерку тихо ненавижу - в ней все глючит и вызывает недоуменные вопросы менеджеров. То в хранилке сложновоспроизводимые глюки, то падает (не в разы, а, скажем, на 10%, глазами ты это даже не заметишь) скорость отдачи с кластера (и у нас все становится колом, потому что не успевает диск - не успевают веб-приложения вовремя отдать клиенту данные - растет число процессов, клиенты начинают жмакать релоад - все накрывается окончательно) И ничего нельзя быстро починить, потому что "надо открыть тикет в поддержке".
А с другой - там сейчас что-то в районе 120T только нашего добра (то есть одной отдельной системы к которой я имею косвенное отношение и связанных с ней) - и в общем-то именно серьезные проблемы, с вопросами от менеджеров - не чаще раза в месяц, и чаще всего связаны с действиями человеков, а не совсем уж непонятно, откуда.
Хочу я попробовать это все заменить не понарошку построенным хренилищем из дерьма и открытых палок? Да конечно же, само собой разумеется, нет! (И, кстати, последним вопросом тут будет - fs, доступ все равно будет не локальным.)
С другой стороны, свои личные данные - те, которых единицы терабайт - я могу доверить и ext4. Я примерно понимаю, как она устроена, и как, случись даже что, я ее буду чинить.
Но по факту они write once, read newer (большинство, что-то, разумеется, раз в три года достается). И вполне могли бы продолжать храниться в любимом моем стиле - стопкой отключенных дисков на полке, в большистве случаев надежность такого хранения в одном экземпляре - приемлема.
На дисках этих, так исторически сложилось - ntfs.
Читается (и пишется, при некоторых ньюансах) на всех имеющихся у меня системах и устройствах, не имеет проблем с кодировками (в отличие от exfat-fuse), никогда не ломалась, а если даже сломается - полно разной степени автоматических средств извлечения данных.Вполне возможный вариант дальнейшего развития для дома - кластер из корейских уродцев, для долгосрочного хранения крупных файлов. Какая под ним fs - совершенно не имеет значения, я вот снова всерьез про ntfs думаю, опять же - проще чинить и маловероятно что поломается. Снапшоты, фэйловер, bitrot prevention и т д - мне обеспечит сам кластер, от fs ничего особого не требуется.
Но тот же gluster, к примеру, требует исключительно xfs, на всем остальном работает кое-как (хранение метаданных в EA) или не работает вовсе.
Кароч, если опустить всю воду - NTFS рекомендуете для продакшна. Здраво.
> Кароч, если опустить всю воду - NTFS рекомендуете для продакшна. Здраво.э... еще раз, если не дошло: мои рекомендации в тех случаях, когда я готов нести за них хотя бы моральную ответственность - будут различаться в разных ситуациях.
Мне вот общие слова "файловая система для продакшна" вообще не говорят ни о чем.
Возможно для именно вашей конкретной задачи идеалом окажется gluster, а он вообще ни на чем кроме xfs не жилец, да и той полезно недефолтные настройки при создании задать (потому что индусы тестировали только с ними).
Или вы в принципе ограничены в выборе платформы freebsd, например потому что упираетесь на всем остальном в сетевой стек, и не владеете фейсбуком, чтобы просто приказать работящим и грамотным рабам быстро перенести его в userspace. Тогда вы и с zfs будете обниматься и плакать - потому что остальное вообще "works as intended"(c).
Вариантов - мильен, серебрянной пули, увы, нет. Есть откровенно дерьмовые решения, которых надо избегать любой ценой, а есть приемлемые, разной степени геморройности.
> А с другой - там сейчас что-то в районе 120T только нашего добразачем тебе хранилка с 120T ? берем какую нить 2U24 с JBOD- ставим туда старенькие 6Т диски.. в какой нить raid5/6.. и вперед.https://andpro.ru/catalog/storage/rack_storage/sistema_khran.../
Мой онанимный друг, если ты не понимаешь зачем нужна хранила, то тебе не стоит рассуждать о продакшене.
Кратко и упращенно - без хранилки не будет отказоустойчивого кластера, а без него - продакшене.
И не надо вспоминать про OMV, FreeNAS и прочие аналоги - это все равно хранилка. Самопальная, медленная и убогая. Медленная потому что даже FC ты запаришся запускать и придется использовать тормозной iSCSI. И 2х годовую конфигурацию ты не осилишь. И 528е сектора.. И кучу всего ещё, что есть на нормальной хранилке.
Ничего себе сколько пафоса и дешёвых понтов! "если ты не понимаешь зачем нужна хранила, то тебе не стоит...". Читая это я аж расплылся в экстазе...
Тем временем, я не стал бы разводить понтов по своим, довольно стандартным, отказоустойчивым решениям на петабайты или локальным - на миллионы IOPS(тут по сети уже будут трудности). Да, всё это - достаточно стандартный и надежный ынтырпрайз.
> Тем временем, я не стал бы разводить понтовпока что ты именно разводишь понты. А предложил - дерьмо на постном масле.
Вот опиши что у тебя за "стандартные и отказоустойчивые" (и что там лежит, заодно - а то может это ненужно в кубе, накроются все петабайты - перезальют) - будем задавать вопросы и может у тебя чему-то поучимся. А может нет.
> Кратко и упращенно - без хранилки не будет отказоустойчивого кластера, а безпочему не будет - будет. Сейчас именно такие решения впихивают хошь с малиновой, не хошь - с солидоловой, причем выбора уже в общем-то не остается. Причем и в впопеносии, и в ms, и в прочих вендорских поделках - sds, это ж еще круче уже провалившейся идейки sdn.
Но вот я за них отвечать - не возьмусь, включая (единственно возможный, собственно) вариант с контрактом от подрядчика. Ну...э...ок, с вариантом от vmware я еще готов иметь дело, но не для той цели, которой заняты пресловутые 120 тер, а по прямому назначению - диски виртуалок хранить (_мелкие_).
> И не надо вспоминать про OMV, FreeNAS и прочие аналоги - это
> все равно хранилка. Самопальная, медленная и убогая. Медленная потому что дажепервое это, как следует из названия, хранилка для домашней пронухи. От нее требуется видосик на шибкоумныйтиви транслировать, а не данные надежно и быстро хранить.
На втором, _теоретически_ ты мог бы что-то сделать работающее (правда, не быстрее чем на голой фре и не надежнее) - но сколько это будет стоить, и как в результате работать (вот с учетом всех works as intended и грозящего перехода на линуксные недотехнологии) - в стоимость не забываем включить свое время на развертывание, тщательное тестирование и сбор граблей - лучше не задумываться.
То есть это даже в колхозном решении для подвальных не будет хорошо, надежно и дешево.
> зачем тебе хранилка с 120T ?сам не знаю... наверное...э... во - файлики на ней хранят, точно! (Я посмотрел - херня какая-то, ни одной сиськи или письки, все больше какие-то фотки документов попадаются, а если даже видосик - то ничего похожего на прон)
> берем какую нить 2U24 с JBOD- ставим туда старенькие 6Т диски.. в
> какой нить raid5/6..на каком-нибудь унылом гуанеце типа md, с raid write hole, после чего - быстро-быстро увольняемся, пока к тебе не пришли с _вопросами_ ?
Отдельный вопрос - как ты будешь подключать эту херню к распределенному кластеру и обеспечивать фэйловер (для начала - наипнувшегося контроллера в этом шлаке)?
Причем я даже не буду уточнять из чего ты будешь лепить кластер, и как дальше с этим жить - начнем с физики.
Сейчас он - мухаха - предложит DRBD или что-нибудь в этом роде.
Все новички делают эту ошибку, не понимая особенностей среды.
Какой ужос. Что-то с DRDB никаких проблем никогда не имел.
Спасибо за развёрнутый ответ. СХД небольшое из нескольких машин. Доступ к данным по сети 10Gbit/s. Данные — мультимедиа на десятки терабайт. Не так важна скорость отдачи, сколько надёжность хранения. Думаем в сторону ext4, программный RAID, кластер, типовое решение на Linux. Очень похоже на файловый сервер для среднего офиса, только с большей устойчивостью. C xfs было гораздо меньше опыта использования, поэтому и спрашивал.
Дальнейшее развитие — готовые СХД от производителей с гарантией. Но для этого требуется увеличение бюджета.
> Думаем в сторону ext4, программный RAIDэто очень ссыкотно, если программный рейд - md (поскольку ресинк при любом нештатном завершении требует перечитать все байты до единого, включая свободное пространство).
Это еще более ссыкотно, если он - lvm, потому что вот "no matching physical volumes found" у меня прямо в консоли сейчас. Чинить его не умеет абсолютно никто.
Да, мы такое использовали во времена оны, и оно работало - но это явное решение из серии "чтоб денег не заплатить".Мне очень импонировала идея gluster. Но ознакомившись с реальными случаями уничтожения им данных при split-brain - я зассал что-то им пользоваться. (Хотя окончательную точку, конечно, поставили мои расистские взгляды)
Возможный для вас выбор - коммерческая moose. Там все страшненько и странненько, но она во-первых не зависит от fs на подах, во-вторых у нее не очень большой и достаточно понятный код на plain c.
> Думаем в сторону ext4, программный RAID, кластер, типовое решение на Linux.Имели дело как c ext4, так и с XFS на больших хранилищах.
Проблемы начинаются с самого начала, когда ты просто не можешь стандартными тулзами
отформатировать несчастный раздел, скажем, в 40 ТБ.
Это все на CentOS (приходилось патчить mkfs), как на других — не знаю.ext3/4 иногда падает, но, обычно, легко восстанавливается, с потерей пары сотен файлов.
XFS же работает крайне надёжно до определённого времени, потом может так запороться на
ровном месте, что никакие танцы с бубнами не позволят вытянуть из этих терабайтов хоть
сколько-нибудь гигабайт незапорченной инфы, и альтернативой остаётся только полное
форматирование раздела и восстановление из бекапа (если он есть, хе-хе).На протяжении эксплуатации потихоньку перевел все ноды на ZFS. В последней версии
объём хранилища был 497 ТБ. Шесть лет в продакшене ZFS-хранилище проработало почти идеально.
> Имели дело как c ext4, так и с XFS на больших хранилищах.
> Проблемы начинаются с самого начала, когда ты просто не можешь стандартными тулзами
> отформатировать несчастный раздел, скажем, в 40 ТБ.мне кажется, это они о вас так позаботились - мягко намекая, что и сама fs для этой цели - "неочень" ;-)
> На протяжении эксплуатации потихоньку перевел все ноды на ZFS. В последней версии
> объём хранилища был 497 ТБ.это, надеюсь, кластера, а не одиночного zpool? А про конфигурацию zpool можете что-то рассказать?
(мне вот очень интересно, до каких размеров можно увеличивать raidz пока он не лопнет)
>мне вот очень интересно, до каких размеров можно увеличивать raidz пока он не лопнетzpool же увеличивается добавлением новых vdev (возможно, с raidz внутри), расширение же raidz (добавление дисков в vdev с raidz) не предусмотрено.
> zpool же увеличивается добавлением новых vdevда, но тебе вот не становится немножко ссыкотно, когда число этих vdev перевалит за третий десяток, осознавать что отказ любого из них по любой причине - накроет весь пул (вместо того чтобы вернуть ошибку на поврежденных файлах и продолжить работать с оставшимися - если бы ее разработчики были хоть сколько-то вменяемы)?
Причем удалить raidz'шный vdev собирающийся накрыться из пула - до сих пор, по-моему, нельзя. А еще недавно нельзя было никакой.
>> zpool же увеличивается добавлением новых vdev
> да, но тебе вот не становится немножко ссыкотно, когда число этих vdev
> перевалит за третий десяток,у меня нет пулов такого размера )
вот поэтому мне очень интересны комментарии того, у кого они есть - как все это организовано и как вообще с таким живут. Но, похоже, как обычно, ответа мы уже не дождемся.
> похоже, как обычно, ответа мы уже не дождемся.Сорри, не видел вопроса.
> мне кажется, это они о вас так позаботились - мягко намекая,
> что и сама fs для этой цели - "неочень" ;-)Я тогда только год как устроился, поэтому лезть с "ценными" советами смысла не было.
Тем более, что, повторюсь, периодически падали ноды с extX, а на XFS другие ноды
с таким же железом работали весьма стабильно. А потеряли мы где-то 90 ТБ на ноде
с XFS, там были проблемы с блоками питания.> это, надеюсь, кластера, а не одиночного zpool?
Основной массив на Gluster, другой — копия основного, физически на другом железе, —
aufs over NFS. Т.е., фактически два отдельных реплицированных массива по 497 ТБ.Хотя я бы предпочёл один zpool на FC или SAS DAS, но у нас мало связи с теми, кто
закупает оборудование и кто эксплуатирует, поэтому так.> А про конфигурацию zpool можете что-то рассказать?
Один vdev raidz1 до 15 дисков. (Не рекомедую так делать. Максимум 10 дисков.)
> становится немножко ссыкотно, когда … отказ любого из них по любой причине - накроет весь пул
В нашем случае не очень было "ссыкотно", т.к. есть бекап физически в другм месте и
в случае чего можно перезалить из бекапа.
> Сорри, не видел вопроса.ну опеннет же ж не место для технических дискуссий, а площадка для тролинга. ;-)
Спасибо огромное за детали - хотя, конечно, конфигурация и use-case, кхе-кхе, специфические.> Основной массив на Gluster, другой — копия основного, физически на другом железе,
> — aufs over NFS. Т.е., фактически два отдельных реплицированных массива по 497 ТБ.и оба на очень странных технологиях, мда. Но я так понимаю, ни гластер ни aufs у вас всерьез не разваливались, не смотря на дохнущие отдельные ноды?
> В нашем случае не очень было "ссыкотно", т.к. есть бекап физически в
> другм месте ии, видимо, есть время на перезалив. Бэкапы-то у нас (предположительно ;-) есть, и ленточные, по отдельности, и репликация целиком, но ни то, ни другое не подключишь за пять минут, и пока оно будет лежать - контора будет терять деньги, поэтому хочется устойчивости схемы без аварийных восстановлений.
> У меня вот на работе вполне себе продакшн, кластеры, терабайты сложноуложенного мусора
> - на винде 2012 (то есть голый виндовый кластер, поверх промышленной
> схд, не sds - сильно устаревшее, может не самое надежное, но
> уже хорошо знакомое решение).Аналогично, только на линухах. Поэтому здорово понимаю.
Тоже тихо матерюсь, но масштаб такой, что из вариантов только жить с тем, из чего можно это более-менее вменяемо собрать. Третьего не дано.
> Вы постоянно всё хаите.Не пытайся ввернуть редкое слово, если не знаешь, как оно пишется. Хаять, хаю, хаешь, хаете.
> Так какая файловая система сейчас по Вашему оптимальная для продакшена на файловом сервере? Именно файловая система.<trollface>
NTFS
</trollface>
А если серьезно - есть только один дистрибутив, жёстко заточенный под кровавый энтерпрайз, то есть - под сервера в продакшене, а не под хипстеровские поделки, обмазанные смузи. Вот и смотри что в нем за ФС...
> хипстеровские поделки, обмазанные смузи. Вот и смотри что в нем за
> ФС...и? В рекомендованной особенно позе (thinlvm под ней, как велит нам лучший редхатовский инженер Кумар (его на самом деле зовут Кумар, блжад!) ? Смотрим, и...
И как - ты уже летишь из окна?
И что там? Ты прям саспенсу нагнал как в лучших триллерах.
> И что там? Ты прям саспенсу нагнал как в лучших триллерах.ну раз ты спрашиваешь - в окно тебя выкинут. Просто потому что нехер спрашивать "и чо там".
Кто владеет темой - задает уточняющие вопросы, ну или сам в окно прыгает, если давно знает все ответы - потому что кроме "п-ц!" там их в конечном итоге не остается.P.S. сглазил.
Пришли с вопросами. В смысле "у нас все упало". lvm, даже не thin.
pvscan
No matching physical volumes found
гуглите. Особенно вас порадуют paywall'ы на найденном том, что, теоретически могло бы быть ответом.
Не найду чето никаких ужасов: или сами харды отвалились, или админы наадминили. Так, чтобы оно само куда-то девалось, не находится. Баг вот еще есть от 2017 г. https://bugzilla.redhat.com/show_bug.cgi?id=1468355. В RHEL и CentOS LVM по-умолчанию используется, вся багзилла такими проблемами была бы забита. Можно хоть ссылку какуюнить?
> В RHEL и CentOS LVM по-умолчанию используется, вся багзилла такими проблемами была бы забита.а она и забита, только там - paywall. Не только лишь каждому можно не то что тикеты там создавать, а хотя бы ответы на них видеть.
(но на самом деле даже с подпиской я ничего путного с первой попытки не увидел - большинство порешало свои проблемы быстрой переустановкой)
> Можно хоть ссылку какуюнить?
google: pvscan No matching physical volumes found
> google: pvscan No matching physical volumes foundкстати, ларчик-то открылся, но осадочек остался.
Действительно, молиться на zfs надо.
Совсем умом тронулись
Ну, в 2020 пользоваться FreeBSD — уже некоторое благородное безумие.
Благоразумие, вы хотели сказать? :)
FreeBSD хоть когда-то предназначалась для использования дома? Она делает две свои главные задачи: благодаря лицензии служит основой для операционных систем устройств самых разных направлений (ввиду чего и постоянно контрибутится, а потому будет жить вечно), а также стоит на серверах
Ввиду чего из неё постоянно коммуниздится код проприерасами.
> Ввиду чего из неё постоянно коммуниздится код проприерасами.Че там с Теслой-то? Через всего 7 лет открыли наработки?
Кстати, не могли бы опеннетные спецы-по-всему-на-свете объяснить, какой именно пункт в GPLv2 мешает проприерасам типа Гугл, Амазон, КлаудФлер (и прочим облачникам с миллиардными оборотами) коммуниздить код при использовании пингвиникса для облачных и прочих сетевых сервисов (заодно, просветите - Гугл свои патчи для ext2 из 200X таки открыл хотя бы 10 лет спустя или "да уже и не нужно!")?
На счёт открытия кода - положим я добавляю в код ну скажем ext2 супер-пупер алгоритм сжатия "на лету" для использования в своих решениях. А алгоритм - патентованный, я его лицензировал, но по условиям лицензии - не могу публиковать его реализацию.
А сей алгоритм - именно то что обеспечивает продажи моего решения...
Ну вы угадали куда пойдут гэпэльщики?
> Она делает две свои главные задачи: благодаря лицензии служит основой для операционных систем устройств самых разных направлений (ввиду чего и постоянно контрибутится, а потому будет жить вечно)В силу своей лицензии, контрибутится на несколько порядков слабее, чем пингвины.
> а также стоит на серверах
Годах в девяностых-нулевых - да, популярная серверная система была, когда линукс пешком под стол ходил. Потом еще некоторое время сохраняла популярность за счет ядерного PPTP. Но последние лет десять классическая опенсорсная фря остается уделом энтузиастов.
На фоне сустемды, кокпита, докеров и прочих девопсов - далеко не фря стала уделом энтузиастов и прочей школоты.
Illumos, давай досвиданья!
> шифрование наборов данныхВ полку славянофилизмов прибыло.
Догадайся, мол, сама, что имелось в виду шифрование датасетов.*лупашит себя ладонью по лбу*
>шифрование датасетов.а фиглишь кирилицей?
> В полку славянофилизмов прибыло.этот термин, для опоздавших родиться, широко использовался в советской компьютерной литературе 70х и 80х годов - потому что таки да, является прямым переводом data set (и да, в литературе по os/360 эти слова писали раздельно)
В отличие от прочих порождений спящих разумов - ничего неправильного я в нем не вижу.
> ничего неправильного я в нем не вижуА я представил себе ход моих мыслей, и какой бы ответ
я подготовил своему начальнику, и в каком стиле,
если бы мне пришла от него в чате, как это часто бывает,
очередная головоломка:"Какие наборы данных у нас в резервуаре?"
> очередная головоломка:
> "Какие наборы данных у нас в резервуаре?"ну вот если "в хранилище" (потому что datastore как ни переведи, и не скалькируй - все одно бнопня какая-то) - то вполне себе понятный вопрос. И да, в терминологии zfs - именно datasetы лежат внутри пула. А если в голове у начальства резервуар - то ответь что в нем форель разводят, а данные мы пока туда не роняли.
Вы так и не поняли ничего.
Приходит, вдруготкуданивозьмись, как шаровая молния, мессага в Телеграм, начинающаяся:"А какие наборы данных у нас в хранилище?"
Какой триггер сработает в башке у нормального, не изнасилованного ЕС ЭВМ во
времена Брежнева, человека?
Первый же проблеск мысли был бы: "Текстовые документы, веб-документы, бекапы, мультимедиа".А теперь сравните с "А какие датасеты у нас в пуле…"
Ответ очевиден:data/samba
data/nfs
И т.д.
> "А какие наборы данных у нас в хранилище?"
> времена Брежнева, человека?Досье на жителей ул. Голикова дд.5-31, гг. 1920-1960.
Очередной любитель "комитов", "лукапов" и "митингов"?
>> шифрование наборов данных
> В полку славянофилизмов прибыло.
> Догадайся, мол, сама, что имелось в виду шифрование датасетов.С разморозкой! Уже лет пятьдесят как :)
Все, кому случилось применять JCL в ОС ЕС (давайте поностальгируем над «//GO.SYSIN DD *»?),
помнят выражение «набор данных».
Чорд, я уж думал тут одна школота, которая этого не знает, ибо младше айфона.
Ой, а порекомендуй что-нибудь про ОС ЕС, интересно же!//Без сарказма
Про ОС ЕС ничего припомнить не могу,
а про её базу - OS/360 можно почитать К.Джермейн, Программирование на IBM/360
Все мурзилки были распечатками с ацпу (кто помнит).Ну а так да, Джермейн.
> Все, кому случилось применять JCL в ОС ЕСУж ты ж ё…
Мы с rадителями жили на Кааме. Кама была шиоокая-шиоокая, эпоха была жуткая,
пrосто жутчайшая, и атмосфеrа была, меезопакостная!
Но не смотыя на это ыба в каме была!
FreeBSD как всегда поступают разумно, не зачем распылятся когда есть уже сообщество и общий вектор развития файловой системы. Ну вот опять у линуксоидов рвет зад...
Да, и то что из ведра линукса весь пермиссивный код пытаются тащить(штеуд-видео и т.д.) - это тоже разумно. Не писать же это самим. И то что вантузомакосями пользуются - тоже..., не пилить же свою десктопную ось!
> Да, и то что из ведра линукса весь пермиссивный код пытаются тащить(штеуд-видео и т.д.) - это тоже разумно. Не писать же это самим.
> из ведра линукса весь пермиссивный код
> GPLv2/0
> Не писать же это самим.Пермессивная лицензия немного намекает, что написано это отнюдь не перепончатыми. Для них, но не ими.
И никто не запрещает оналитекам опеннета запилить труЪ штеуд-видео под GPLv2 онли, который "бздуны" не смогут "спереть". Вперед и с песней! Или как обычно - горазды только каменты на опеннете писать? ))> И то что вантузомакосями пользуются - тоже..., не пилить же свою десктопную ось!
Неужели и тут утянули идею с реализацией из пингвникса и объявили "Год BSD на десктопе" с макоси? ))
https://developers.redhat.com/blog/2020/02/12/podman-for-mac.../
> Senior Solutions Architect, Red Hat
> My daily laptop is a MacBook Pro, which is great unless you want to dual boot into Linux and develop on containers.
Там не только GPLv2 код в ядре, но и BSD тоже.
> Пермессивная лицензия немного намекает, что написано это отнюдь не перепончатыми. Для них, но не ими.Ниочём.
> Senior Solutions Architect, Red Hat
> My daily laptop is a MacBook Pro, which is great unless you want to dual boot into Linux and develop on containersТам и вантузятины хватает, не только макоси. И зарплаты там раза в 2 ниже чем в средних конторах.
А вот теперь, если сравнить линукс и бздю в дуалбуте на моём ноуте, то внезапно выясняется, что в линуксе работает полностю всё, а в бзде - не всё и слегка плохо. Медленный и непросыпающийся вайфай, дичайший тиринг, как 15 лет назад был в линуксе.
В общем - отставание на 15 лет.
Срочно неси свой ноут в Парижскую палату мер и весов.
>>> БЗДУНЫ ВОРУЮТЬ НАШ КОД!
> Там не только GPLv2 код в ядре, но и BSD тоже.
>> Пермессивная лицензия немного намекает, что написано это отнюдь не перепончатыми. Для них, но не ими.
> Ниочём.Когда нечего возразить по существу - пиши "ниачём!1".
>> Senior Solutions Architect, Red Hat
>> My daily laptop is a MacBook Pro, which is great unless you want to dual boot into Linux and develop on containers
> Там и вантузятины хватает, не только макоси. И зарплаты там раза в
> 2 ниже чем в средних конторах.И вообще, там неправильные линуксоиды, а значит и не линусоиды вовсе и поэтому несчитается несчитается несчитается!
> А вот теперь, если сравнить линукс и бздю в дуалбуте на моём
> ноуте, то внезапно выясняется, что в линуксе работает полностю всё, а
> в бзде - не всё и слегка плохо. Медленный и непросыпающийся
> вайфай, дичайший тиринг, как 15 лет назад был в линуксе.
> В общем - отставание на 15 лет.Если сравнить линукс и бздю без дуалбута на моих трех ноутах, то бубунта слишком долго уходит в сон (с десяток секунд) и не умеет в fingerprint reader. В остальном, никакой особой разницы на глаз не видно, в общем - отставание методички анонима опеннета на 15 лет.
Срочно неси свой ноут в Парижскую палату мер и весов.
> И вообще, там неправильные линуксоидыПонимаешь, линуксоиды - пользуются линуксом, вантузятнеги - вантузом, макакосятники - вантузной виртуалкой под пареными рельсами в макакоси. Бояздешники - ну ты понял...
> отставание методички анонима опеннета на 15 лет.
На 15 дней, разве что. У меня войфай медленный(не все режимы поддерживаются) и не выходит из сна. Некоторые даже здесь на опеннете рекомендовали поставить OpenWRT под BHyve и отдать ему устройство. Может так и сделаю, посмотрим.
При том что звук и сон работают нормально. Что делать с тирингом - наверное наслаждаться.
>> И вообще, там неправильные линуксоиды
> Понимаешь, линуксоиды - пользуются линуксом,Предпочитая объявлять "Год Линукса на десктопе" с макоси. И разрабатывать его тоже - с макоси.
Ничто так не разводит срач на опеннете, как набор букв в данной последовательности: "FreeBSD"
Можно ещё так:
systemd
npm
drovorub
И RUST же !
Ну, скоро перейдут на ядро линукс, и правда, зачем самим разрабатывать?И будет еще дистр линукса с нескучным пакетным менеджером и не менее нескучными обоими.
Впрочем, всё идёт к тому, что все перейдут на ядро линукса, это сильно экономит деньги.
То есть качество кода ZFS во фре упадет и будет такое же говно как и все в линуксе?
Я, все еще, надеюсь, что Core Team пока еще в адеквате и понимает, что делает.
> Я, все еще, надеюсь, что Core Team пока еще в адеквате и понимает, что делает.А я уже лет 10 назад перестал надеяться.
> Я, все еще, надеюсь, что Core Team пока еще в адеквате и понимает, что делает.Да, но теперь ему все время выбирать: следовать в тренде наркоманских незаконченных идей или разгребать-переписывать и возращать назад в мейнстрим. Как бы работы меньше не становится, по сравнению просто с бэкпортированием в свой проект лучших фич.
Они, несомненно, понимают, но есть политика и есть политика обстоятельств.Сложность кодовой базы операционных систем выросла до такой степени, что реально их могут поддерживать только очень большие коллективы за много денег. Зачем вкладывать деньги в freebsd, когда уже есть линукс?
Судите сами, из более менее распространённых ОС ни одна не поддерживается и разрабатывается группой энтузиастов или мелкой конторой. Windows, Android, AIX, Solaris, Linux. За каждой из них стоит огромная корпорация, а за линуксом и вовсе толпа.
Если кто-то реально крупный, например HP, захочет развивать freebsd, ну типа для "домашнего решения", наилучшим образом оптимизированного под своё железо, да, есть шанс выжить.
А так freebsd постепенно скатится в академический проект на основе линукса. Нет возможности поддерживать силами 3,5 анонимусов.
> есть политика и есть политика обстоятельствесть политика намерений и есть политика обстоятельств
Да я все понимаю. Разработка ФС в принципе не может быть pet-project в свободное время, одно тестирование на железе чего стоит...
Но ведь есть то что работает надежно, пусть в нем и нет каких-то виртуальных "очень-важных-и-нужных-вещей". Это как вместо премиального автомобиля купить заниженное ведро, потому что на нем большинство ездит и каждый день находит новые способы его еще занизить или движок вкорячить от другого ведра. Ситуация не настолько безвыходная вроде бы.
Я не про файловые системы, а вообще, в целом.У команды freebsd просто нет ресурсов для разработки всех нужных сейчас функций, исправления ошибок, тестирования на железе.
И, ясное дело, то, что они не могут сами, берут со стороны, из линукса (а откуда ещё брать?), видео вот, теперь файловую систему, потом вейланд прикрутят, либо вовсе откажутся от графики, как в aix например. Потом сетевую подсистему стянут, ну нет возможности тестирования на железе.
И так оно и пойдёт, и пойдёт...
Freebsd уже сейчас по факту pet-project. На уровне haiku, illumos и прочих.
Жаль, что у Core Team дефицит кадров. Был бы их уровня знаний о системе, то постарался бы тоже что-то отправить на ревью. Но жизнь уже распорядилвсь личным временем иначе.
> Я, все еще, надеюсь, что Core Team пока еще в адеквате и
> понимает, что делает.угу - чувак из core team заблокировал этот нужный и важный шаг. Кажется, поторопились прокукарекать?
Кстати, количество ревьюеров настолько критичной системы - впечатляет, угу-мс.
Видево из ведра линукса перетащили, ZoL тоже. Ну тебе, вантузомакосятнику-то какая разница?
> То есть качество кода ZFS во фре упадет и будет такое же говно как и все в линуксе?Ровно вот с этим и связаны все опасения трудящихся =(
ZoL внутри редкая помойка. Прям страшно, что это живёт и где-то работает.
А после апгрейда на 13.0 RELENG будет страшно уже и за свою файлопомойку/
Сочувствую потребителям ZFS.
Самое забавное — это то, что "ZFS on Linux" не имеет ни малейшего отношения к этому самому Linux. Там же весь код SUNовский и лицуха совсем не GPL. Реализации для линя и фряхи тоже у каждого свои. Он уже даже и не ZoL вовсе, а OpenZFS.
> "ZFS on Linux" не имеет ни малейшего отношения к этому самому Linux.Громко сказано.
> Там же весь код SUNовский
Большая часть. В зулягисе SPL не было по понятным причинам.
> Реализации для линя и фряхи тоже у каждого свои.
Новость прочитай. Хотя бы 1 раз.
> Он уже даже и не ZoL вовсе, а OpenZFS.
Да, переименовать бы не мешало, согласен.
>Новость прочитай. Хотя бы 1 раз.Перечитал и снова увидел то, что FreeBSD переходит на мультиплатформенную реализацию OpenZFS вместо устаревшей illumos.
Линукс там каким боком?
Ибо это форк ZFS который разработали неудачники под Linux.
> Ибо это форк ZFS который разработали неудачники под Linux.Просто эти ребята слишком поздно поняли, что линукс — это проприетарная ОС с открытым исходным кодом.
> Просто эти ребята слишком поздно поняли, что линукс — это проприетарная ОС с открытым исходным
> кодом.с _бесплатным_. А "открытым" надо писать со сносочкой - "* по мнению пасущихся на ней адвокатишек из FSF".
Потому что ребята вовсе не собирались изменять линукс (включать в него намертво свою разработку или еще там что), в конце -концов, это их корм - но внезапно выяснилось, что код-то для _них_ - вовсе не "открыт", и в любой момент по желанию левой пятки - EXPORT_GPL_ONLY или вообще не экспортится наружу. Такая вот - открытость ;)
Ты с предыдущим комментатором - слились в блаженном жабогадюкинге.
Ну вот и ушел последний козырь freebsd, про который раньше кричали практически все фаны бсд - а у нас есть zfs. Шах и мат :D
>ушел последний козырь freebsdДоо, выкунили старый неподдерживаемый код, заменив его более современным решением — это прям провал тысячелетия, ага. Фряха как была единственной системой с НОРМАЛЬНО работающей ZFS, так и останется ею.
> ага. Фряха как была единственной системой с НОРМАЛЬНО работающей ZFS, так и останется ею.Обоснуй. С той самой кодбазой, и главное - тем же SPL.
И что такое "НОРМАЛЬНО работающей ZFS"? Откуда капслок? Поверь, я насмотрелся её сюрпризы с волшебными range-locks и никак не могу понять что же изменит здесь фряха.
>> ага. Фряха как была единственной системой с НОРМАЛЬНО работающей ZFS, так и останется ею.
> Обоснуй. С той самой кодбазой, и главное - тем же SPL.
> И что такое "НОРМАЛЬНО работающей ZFS"? Откуда капслок? Поверь, я насмотрелся её
> сюрпризы с волшебными range-locks и никак не могу понять что же
> изменит здесь фряха.OMG... У меня есть серваки, которые работают с 10-12 года и всё с ними хорошо. На линуксе же даже сегодня максимум, что можно сотворить на zfs, так это домашняя файлопомойка с некритичными данными. Да и то на свой страх и риск.
> У меня есть серваки, которые работают с 10-12 года и всё с ними хорошо.А это показатель? У меня с 2012 вообще на XFS, и им ничего.
> На линуксе же даже сегодня максимум, что можно сотворить на zfs, так это домашняя файлопомойка с некритичными данными. Да и то на свой страх и риск.
Та обоснуй жеж. Кончай повторять мантру, давай информацию. Есть одна такая на петабайты, есть на ZoL другие, тысячи мелких по несколько терабайт, каждая из которых - критична.
>У меня с 2012 вообще на XFS, и им ничего.Молодец, я очень рад за тебя. У меня тоже есть серваки на XFS и тоже работают хорошо. Что сказать-то хотел?
>Та обоснуй жеж.
Что тут обосновывать? Только поехавший наркоман будет разворачивать такое в проде. Нигде и никогда не видел серьёзных решений на линуксовом зфс. Я конечно всяких наркоманов насмотрелся, но до такого никто из них не додумался.
Ну зочем вы тгавите? Если смириться с неэффективностью (и write amplification, и жор cpu, и использование половины памяти при необходимости вторую половину держать в резерве), неумением увеличивать размер тома без перезагрузки, прочими мелочами - то вполне можно и такое.Не думаю что оно будет сильно (или вообще) ненадежнее чем zfs на фре.
И если тебе еще нужен raid6 и непременно линукс - то выбора в общем-то и нет.
По мне так если до усрачки нужен именно линукс, то для данного кейса лучше всего зайдёт XFS, но оно тоже говно.
> По мне так если до усрачки нужен именно линукс, то для данного кейса лучше всего зайдёт XFSключевое слово - raid.
В случае xfs это будет md. full resync на _любом_ нештатном завершении убьет тебе диски раньше, чем сдох бы сам по себе единственный без бэкапа (не говоря уже о том что убьет производительность, современные многотерабайтные диски ресинкаются неделями).Для снапшотов тебе понадобится еще и thin-lvm (то есть один п-ц поверх другого п-ца), а его понимают единицы, и совсем никто не умеет чинить.
Для доскера - какой-то lvm (потому что на xfs он будет через overlay).
В случае zfs - все перечисленное будет "просто работать". Медленно, неэффективно, но железо нынче дешевое.
xfs же можно использовать только на redundant-storage, предоставляемом либо виртуализацией, либо hardware raid (ну или если данных не жалко - кластер без особых требований к надежности отдельных нод). Причем рекомендации лучших собаководов (и, кажется, дефолтные галочки впопеншифтеров) - доскера при этом держать на отдельном lvm-томе.
После двух degraded pool экспериментировать с ZFS под линуксом как-то желания не возникает. А ещё после очередного обновления ядра можно не досчитаться энное количество дисков в системе.
> После двух degraded pooldegraded pool - это всего лишь пул, в котором отвалился диск в рейде, чинится заменой диска.
Вот когда оно "unable to import", причем и в readonly тоже - это п-ц. Но этого добиться надо таки суметь, и я никогда не слышал о таком на пустом месте (другое дело что zfs по идее должна была нас защищать и в тех случаях, или иметь хотя бы какие-то пути восстановления - "а оно, вот")
> возникает. А ещё после очередного обновления ядра можно не досчитаться энное
> количество дисков в системе.ну вот тут degraded pool точно не импортнется. Ну так может и не стоит его такой импортить-то, сначала диски надо найти? ;-)
Как-то у вас очень всё... драматично. Подобные ужасы, по-моему, происходят только в ночных рассказах в пионерлагерях. И ZFS вполне сносно работает там, где он адекватен задачам, и XFS -- тоже. Железо сбоит значительно чаще.
Так это ж пох, сказочник всего опеннета.
>>ушел последний козырь freebsdеще, кстати, не ушел - патч заблокирован gnn
> Доо, выкунили старый неподдерживаемый код, заменив его более современным решением —
даже жаль что a) неработоспособным b) "модное современное" даже trim научилось только по факту этого мержа - стянув его у фри. Ну ничего, ничего - "зато мы умеем сжатие модным-современным-ненужно алгоритмом - всосав в ядро библиотеку лопающуюся по стеку". Современно! (раньше как-то было не принято, действительно) А trim - ненужно, фуфу, устаревшее г-но.
> это прям провал тысячелетия, ага. Фряха как была единственной системой с
> НОРМАЛЬНО работающей ZFS, так и останется ею.главное - верить!
Она и раньше там нормально не работала, если не использовать стремные патчи, проигнорированные продаванами насов, да и то - от проблем "пул не импортируется - destroy, пересоздайте", или "система крэшится при обращении к каталогу - destroy, пересоздайте" это не поможет совершенно ничем. Просто жили с этим. notabug же ж.
>[оверквотинг удален]
> ядро библиотеку лопающуюся по стеку". Современно! (раньше как-то было не принято,
> действительно) А trim - ненужно, фуфу, устаревшее г-но.
>> это прям провал тысячелетия, ага. Фряха как была единственной системой с
>> НОРМАЛЬНО работающей ZFS, так и останется ею.
> главное - верить!
> Она и раньше там нормально не работала, если не использовать стремные патчи,
> проигнорированные продаванами насов, да и то - от проблем "пул не
> импортируется - destroy, пересоздайте", или "система крэшится при обращении к каталогу
> - destroy, пересоздайте" это не поможет совершенно ничем. Просто жили с
> этим. notabug же ж.Я не фанатик, мне проще. Если сломают, перейду на стильный модный молодёжный XFS.
> Я не фанатик, мне проще. Если сломают, перейду на стильный модный молодёжный XFS.а данные - хрен с ними? Или "у меня пока не падало" ?
У меня вот - падало, "лопнуло, и забрызгало, вот, меня и товарищей прессу". Причем ладно бы однажды.
Если мне все же понадобится где-то наколенная реализация хранилки для быстрой отдачи много мелких файликов с надежным их хранением - я вот хз, из чего ее теперь строить (ну, в смысле, не теперь, но через пару лет, когда 13 станет oldstable а 11/12 умрут)
>Или "у меня пока не падало" ?Кстати за 10 лет использования ни одного серьёзного косяка.
>через пару лет, когда 13 станет oldstable а 11/12 умрут
GEOM наше всё!
Столько ходит баек про zfs, но как только вы с ней поработает, то ничего другого просто уже не захотите. На данный момент, ничего лучше просто нет. Рекомендую!
Сразу видно Рубиста
Как дефрагментировать zfs?
- Попробуйте высоконагруженные субд погонять. Огребёте D-state с небходимостью перезагрузки на высоких нагрузках, и просто снижение производительности на низких. Вроде поправили в прошлом году, через год узнаем.
- Невозможность дефрагментации.
- Хрупкий ARC.
Это какие именно "высоконагруженные субд". Поимённо, если можно.
со времен 9-той фри юзаю zfs, был один трабл, все решилось через передачу снапшотов
А ещё https://zfsonfreebsd.github.io
>https://open-zfs.org/
>Warning: Potential Security Risk AheadКхм.
Оно https://zfsonlinux.org/
И https://openzfs.org
А ещё https://zfsonfreebsd.github.io ...
Короче не наплодить овер 100500 доменов для одного проекта - это не для академиков.