The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Кодовая база FreeBSD переведена на использование OpenZFS (ZFS on Linux) , opennews (??), 25-Авг-20, (0) [смотреть все]

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


25. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от пох. (?), 25-Авг-20, 10:31 
Просто п-ц какой-то. Начиная от реализации "мы не хотим отдельной пропети, но она нужна, поэтому мы ее размажем по метаданным" (что это было, блжад?) и заканчивая "ну тут библиотека, которую втащили целиком без ревью, лопается по стеку, но мы (сегодня) уверены что мы эти части не используем".

В общем, типичный пример как раз того, чем плоха разработка от дельфиксов. Невменяемая помойка, слепленная из того что было под рукой. Причем не проходящая где-то по границам хорошо отлаженного и понятного кода, а норовящая влезть во все возможные и невозможные места, делая ни fs, ни код несовместимыми в принципе на каждом новом "улучшизме".

Ответить | Правка | Наверх | Cообщить модератору

85. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от benu (ok), 25-Авг-20, 16:56 
Вы постоянно всё хаите. zfs, xfs, ext3 — это то, что я сам читал в Ваших ответах. Так какая файловая система сейчас по Вашему оптимальная для продакшена на файловом сервере? Именно файловая система. Бекапы, снапшоты, кластеры и прочее — это отдельный разговор.
Ответить | Правка | Наверх | Cообщить модератору

93. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от пох. (?), 25-Авг-20, 17:41 
хнык-хнык... Сам хотел бы знать.

Но можно для начала уточнить - что есть "продакшн", что такое в нем "файловый сервер", [зачеркнуто: и кто отвечать потом будет] ?

А то вынос за скобки кластера - как-то несколько удивляет. А подвальная файлопомойка вряд ли "продакшн" который вы имели в виду?

У меня вот на работе вполне себе продакшн, кластеры, терабайты сложноуложенного мусора - на винде 2012 (то есть голый виндовый кластер, поверх промышленной схд, не sds - сильно устаревшее, может не самое надежное, но уже хорошо знакомое решение).

С одной стороны - я всю эту этажерку тихо ненавижу - в ней все глючит и вызывает недоуменные вопросы менеджеров. То в хранилке сложновоспроизводимые глюки, то падает (не в разы, а, скажем, на 10%, глазами ты это даже не заметишь) скорость отдачи с кластера (и у нас все становится колом, потому что не успевает диск - не успевают веб-приложения вовремя отдать клиенту данные - растет число процессов, клиенты начинают жмакать релоад - все накрывается окончательно) И ничего нельзя быстро починить, потому что "надо открыть тикет в поддержке".

А с другой - там сейчас что-то в районе 120T только нашего добра (то есть одной отдельной системы к которой я имею косвенное отношение и связанных с ней) - и в общем-то именно серьезные проблемы, с вопросами от менеджеров - не чаще раза в месяц, и чаще всего связаны с действиями человеков, а не совсем уж непонятно, откуда.

Хочу я попробовать это все заменить не понарошку построенным хренилищем из дерьма и открытых палок? Да конечно же, само собой разумеется, нет! (И, кстати, последним вопросом тут будет - fs, доступ все равно будет не локальным.)

С другой стороны, свои личные данные - те, которых единицы терабайт - я могу доверить и ext4. Я примерно понимаю, как она устроена, и как, случись даже что, я ее буду чинить.

Но по факту они write once, read newer (большинство, что-то, разумеется, раз в три года достается). И вполне могли бы продолжать храниться в любимом моем стиле - стопкой отключенных дисков на полке, в большистве случаев надежность такого хранения в одном экземпляре - приемлема.
На дисках этих, так исторически сложилось - ntfs.
Читается (и пишется, при некоторых ньюансах) на всех имеющихся у меня системах и устройствах, не имеет проблем с кодировками (в отличие от exfat-fuse), никогда не ломалась, а если даже сломается - полно разной степени автоматических средств извлечения данных.

Вполне возможный вариант дальнейшего развития для дома - кластер из корейских уродцев, для долгосрочного хранения крупных файлов. Какая под ним fs - совершенно не имеет значения, я вот снова всерьез про ntfs думаю, опять же - проще чинить и маловероятно что поломается. Снапшоты, фэйловер, bitrot prevention и т д - мне обеспечит сам кластер, от fs ничего особого не требуется.
Но тот же gluster, к примеру, требует исключительно xfs, на всем остальном работает кое-как (хранение метаданных в EA) или не работает вовсе.

Ответить | Правка | Наверх | Cообщить модератору

106. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +3 +/
Сообщение от zzz (??), 25-Авг-20, 18:34 
Кароч, если опустить всю воду - NTFS рекомендуете для продакшна. Здраво.
Ответить | Правка | Наверх | Cообщить модератору

121. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от пох. (?), 25-Авг-20, 21:41 
> Кароч, если опустить всю воду - NTFS рекомендуете для продакшна. Здраво.

э... еще раз, если не дошло: мои рекомендации в тех случаях, когда я готов нести за них хотя бы моральную ответственность - будут различаться в разных ситуациях.

Мне вот общие слова "файловая система для продакшна" вообще не говорят ни о чем.

Возможно для именно вашей конкретной задачи идеалом окажется gluster, а он вообще ни на чем кроме xfs не жилец, да и той полезно недефолтные настройки при создании задать (потому что индусы тестировали только с ними).

Или вы в принципе ограничены в выборе платформы freebsd, например потому что упираетесь на всем остальном в сетевой стек, и не владеете фейсбуком, чтобы просто приказать работящим и грамотным рабам быстро перенести его в userspace. Тогда вы и с zfs будете обниматься и плакать - потому что остальное вообще "works as intended"(c).

Вариантов - мильен, серебрянной пули, увы, нет. Есть откровенно дерьмовые решения, которых надо избегать любой ценой, а есть приемлемые, разной степени геморройности.

Ответить | Правка | Наверх | Cообщить модератору

134. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от Аноним (133), 26-Авг-20, 05:45 
> А с другой - там сейчас что-то в районе 120T только нашего добра

зачем тебе хранилка с 120T ? берем какую нить 2U24 с JBOD- ставим туда старенькие 6Т диски.. в какой нить raid5/6.. и вперед.https://andpro.ru/catalog/storage/rack_storage/sistema_khran.../

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

140. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от pofigist (?), 26-Авг-20, 09:40 
Мой онанимный друг, если ты не понимаешь зачем нужна хранила, то тебе не стоит рассуждать о продакшене.
Кратко и упращенно - без хранилки не будет отказоустойчивого кластера, а без него - продакшене.
И не надо вспоминать про OMV, FreeNAS и прочие аналоги - это все равно хранилка. Самопальная, медленная и убогая. Медленная потому что даже FC ты запаришся запускать и придется использовать тормозной iSCSI. И 2х годовую конфигурацию ты не осилишь. И 528е сектора.. И кучу всего ещё, что есть на нормальной хранилке.
Ответить | Правка | Наверх | Cообщить модератору

153. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от Аноним (29), 26-Авг-20, 10:48 
Ничего себе сколько пафоса и дешёвых понтов! "если ты не понимаешь зачем нужна хранила, то тебе не стоит...". Читая это я аж расплылся в экстазе...
Тем временем, я не стал бы разводить понтов по своим, довольно стандартным, отказоустойчивым решениям на петабайты или локальным - на миллионы IOPS(тут по сети уже будут трудности). Да, всё это - достаточно стандартный и надежный ынтырпрайз.
Ответить | Правка | Наверх | Cообщить модератору

177. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 13:06 
> Тем временем, я не стал бы разводить понтов

пока что ты именно разводишь понты. А предложил - дерьмо на постном масле.

Вот опиши что у тебя за "стандартные и отказоустойчивые" (и что там лежит, заодно - а то может это ненужно в кубе, накроются все петабайты - перезальют) - будем задавать вопросы и может у тебя чему-то поучимся. А может нет.

Ответить | Правка | Наверх | Cообщить модератору

163. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 11:36 
> Кратко и упращенно - без хранилки не будет отказоустойчивого кластера, а без

почему не будет - будет. Сейчас именно такие решения впихивают хошь с малиновой, не хошь - с солидоловой, причем выбора уже в общем-то не остается. Причем и в впопеносии, и в ms, и в прочих вендорских поделках - sds, это ж еще круче уже провалившейся идейки sdn.

Но вот я за них отвечать - не возьмусь, включая (единственно возможный, собственно) вариант с контрактом от подрядчика. Ну...э...ок, с вариантом от vmware я еще готов иметь дело, но не для той цели, которой заняты пресловутые 120 тер, а по прямому назначению - диски виртуалок хранить (_мелкие_).

> И не надо вспоминать про OMV, FreeNAS и прочие аналоги - это
> все равно хранилка. Самопальная, медленная и убогая. Медленная потому что даже

первое это, как следует из названия, хранилка для домашней пронухи. От нее требуется видосик на шибкоумныйтиви транслировать, а не данные надежно и быстро хранить.

На втором, _теоретически_ ты мог бы что-то сделать работающее (правда, не быстрее чем на голой фре и не надежнее) - но сколько это будет стоить, и как в результате работать (вот с учетом всех works as intended и грозящего перехода на линуксные недотехнологии) - в стоимость не забываем включить свое время на развертывание, тщательное тестирование и сбор граблей - лучше не задумываться.

То есть это даже в колхозном решении для подвальных не будет хорошо, надежно и дешево.

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

154. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от пох. (?), 26-Авг-20, 10:51 
> зачем тебе хранилка с 120T ?

сам не знаю... наверное...э... во - файлики на ней хранят, точно! (Я посмотрел - херня какая-то, ни одной сиськи или письки, все больше какие-то фотки документов попадаются, а если даже видосик - то ничего похожего на прон)

> берем какую нить 2U24 с JBOD- ставим туда старенькие 6Т диски.. в
> какой нить raid5/6..

на каком-нибудь унылом гуанеце типа md, с raid write hole, после чего - быстро-быстро увольняемся, пока к тебе не пришли с _вопросами_ ?

Отдельный вопрос - как ты будешь подключать эту херню к распределенному кластеру и обеспечивать фэйловер (для начала - наипнувшегося контроллера в этом шлаке)?

Причем я даже не буду уточнять из чего ты будешь лепить кластер, и как дальше с этим жить - начнем с физики.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

219. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от Онаним (?), 27-Авг-20, 09:29 
Сейчас он - мухаха - предложит DRBD или что-нибудь в этом роде.
Все новички делают эту ошибку, не понимая особенностей среды.
Ответить | Правка | Наверх | Cообщить модератору

240. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от НямНямка (?), 28-Авг-20, 17:19 
Какой ужос. Что-то с DRDB никаких проблем никогда не имел.
Ответить | Правка | Наверх | Cообщить модератору

175. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от benu (ok), 26-Авг-20, 12:59 
Спасибо за развёрнутый ответ. СХД небольшое из нескольких машин. Доступ к данным по сети 10Gbit/s. Данные — мультимедиа на десятки терабайт. Не так важна скорость отдачи, сколько надёжность хранения. Думаем в сторону ext4, программный RAID, кластер, типовое решение на Linux. Очень похоже на файловый сервер для среднего офиса, только с большей устойчивостью. C xfs было гораздо меньше опыта использования, поэтому и спрашивал.
Дальнейшее развитие — готовые СХД от производителей с гарантией. Но для этого требуется увеличение бюджета.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

181. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 13:21 
> Думаем в сторону ext4, программный RAID

это очень ссыкотно, если программный рейд - md (поскольку ресинк при любом нештатном завершении требует перечитать все байты до единого, включая свободное пространство).
Это еще более ссыкотно, если он - lvm, потому что вот "no matching physical volumes found" у меня прямо в консоли сейчас. Чинить его не умеет абсолютно никто.
Да, мы такое использовали во времена оны, и оно работало - но это явное решение из серии "чтоб денег не заплатить".

Мне очень импонировала идея gluster. Но ознакомившись с реальными случаями уничтожения им данных при split-brain - я зассал что-то им пользоваться. (Хотя окончательную точку, конечно, поставили мои расистские взгляды)

Возможный для вас выбор - коммерческая moose. Там все страшненько и странненько, но она во-первых не зависит от  fs на подах, во-вторых у нее не очень большой и достаточно понятный код на plain c.


Ответить | Правка | Наверх | Cообщить модератору

212. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от Demo (??), 26-Авг-20, 23:05 
> Думаем в сторону ext4, программный RAID, кластер, типовое решение на Linux.

Имели дело как c ext4, так и с XFS на больших хранилищах.
Проблемы начинаются с самого начала, когда ты просто не можешь стандартными тулзами
отформатировать несчастный раздел, скажем, в 40 ТБ.
Это все на CentOS (приходилось патчить mkfs), как на других — не знаю.

ext3/4 иногда падает, но, обычно, легко восстанавливается, с потерей пары сотен файлов.
XFS же работает крайне надёжно до определённого времени, потом может так запороться на
ровном месте, что никакие танцы с бубнами не позволят вытянуть из этих терабайтов хоть
сколько-нибудь гигабайт незапорченной инфы, и альтернативой остаётся только полное
форматирование раздела и восстановление из бекапа (если он есть, хе-хе).

На протяжении эксплуатации потихоньку перевел все ноды на ZFS. В последней версии
объём хранилища был 497 ТБ. Шесть лет в продакшене ZFS-хранилище проработало почти идеально.

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

227. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 27-Авг-20, 09:57 
> Имели дело как c ext4, так и с XFS на больших хранилищах.  
> Проблемы начинаются с самого начала, когда ты просто не можешь стандартными тулзами
> отформатировать несчастный раздел, скажем, в 40 ТБ.

мне кажется, это они о вас так позаботились - мягко намекая, что и сама fs для этой цели - "неочень" ;-)

> На протяжении эксплуатации потихоньку перевел все ноды на ZFS. В последней версии
> объём хранилища был 497 ТБ.

это, надеюсь, кластера, а не одиночного zpool? А про конфигурацию zpool можете что-то рассказать?
(мне вот очень интересно, до каких размеров можно увеличивать raidz пока он не лопнет)

Ответить | Правка | Наверх | Cообщить модератору

232. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от edo (ok), 27-Авг-20, 21:47 
>мне вот очень интересно, до каких размеров можно увеличивать raidz пока он не лопнет

zpool же увеличивается добавлением новых vdev (возможно, с raidz внутри), расширение же raidz (добавление дисков в vdev с raidz) не предусмотрено.

Ответить | Правка | Наверх | Cообщить модератору

234. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 27-Авг-20, 23:30 
> zpool же увеличивается добавлением новых vdev

да, но тебе вот не становится немножко ссыкотно, когда число этих vdev перевалит за третий десяток, осознавать что отказ любого из них по любой причине - накроет весь пул (вместо того чтобы вернуть ошибку на поврежденных файлах и продолжить работать с оставшимися - если бы ее разработчики были хоть сколько-то вменяемы)?

Причем удалить raidz'шный vdev собирающийся накрыться из пула - до сих пор, по-моему, нельзя. А еще недавно нельзя было никакой.

Ответить | Правка | Наверх | Cообщить модератору

235. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от edo (ok), 27-Авг-20, 23:43 
>> zpool же увеличивается добавлением новых vdev
> да, но тебе вот не становится немножко ссыкотно, когда число этих vdev
> перевалит за третий десяток,

у меня нет пулов такого размера )

Ответить | Правка | Наверх | Cообщить модератору

236. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 27-Авг-20, 23:56 
вот поэтому мне очень интересны комментарии того, у кого они есть - как все это организовано и как вообще с таким живут. Но, похоже, как обычно, ответа мы уже не дождемся.

Ответить | Правка | Наверх | Cообщить модератору

242. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +1 +/
Сообщение от Demo (??), 30-Авг-20, 22:24 
> похоже, как обычно, ответа мы уже не дождемся.

Сорри, не видел вопроса.

> мне кажется, это они о вас так позаботились - мягко намекая,
> что и сама fs для этой цели - "неочень" ;-)

Я тогда только год как устроился, поэтому лезть с "ценными" советами смысла не было.
Тем более, что, повторюсь, периодически падали ноды с extX, а на XFS другие ноды
с таким же железом работали весьма стабильно. А потеряли мы где-то 90 ТБ на ноде
с XFS, там были проблемы с блоками питания.

> это, надеюсь, кластера, а не одиночного zpool?

Основной массив на Gluster, другой — копия основного, физически на другом железе, —
aufs over NFS. Т.е., фактически два отдельных реплицированных массива по 497 ТБ.

Хотя я бы предпочёл один zpool на FC или SAS DAS, но у нас мало связи с теми, кто
закупает оборудование и кто эксплуатирует, поэтому так.

> А про конфигурацию zpool можете что-то рассказать?

Один vdev raidz1 до 15 дисков. (Не рекомедую так делать. Максимум 10 дисков.)

>  становится немножко ссыкотно, когда … отказ любого из них по любой причине - накроет весь пул

В нашем случае не очень было "ссыкотно", т.к. есть бекап физически в другм месте и
в случае чего можно перезалить из бекапа.

Ответить | Правка | Наверх | Cообщить модератору

243. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 31-Авг-20, 18:07 
> Сорри, не видел вопроса.

ну опеннет же ж не место для технических дискуссий, а площадка для тролинга. ;-)
Спасибо огромное за детали - хотя, конечно, конфигурация и use-case, кхе-кхе, специфические.

> Основной массив на Gluster, другой — копия основного, физически на другом железе,
> — aufs over NFS. Т.е., фактически два отдельных реплицированных массива по 497 ТБ.

и оба на очень странных технологиях, мда. Но я так понимаю, ни гластер ни aufs у вас всерьез не разваливались, не смотря на дохнущие отдельные ноды?

> В нашем случае не очень было "ссыкотно", т.к. есть бекап физически в
> другм месте и

и, видимо, есть время на перезалив. Бэкапы-то у нас (предположительно ;-) есть, и ленточные, по отдельности, и репликация целиком, но ни то, ни другое не подключишь за пять минут, и пока оно будет лежать - контора будет терять деньги, поэтому хочется устойчивости схемы без аварийных восстановлений.

Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

200. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от Онаним (?), 26-Авг-20, 20:01 
> У меня вот на работе вполне себе продакшн, кластеры, терабайты сложноуложенного мусора
> - на винде 2012 (то есть голый виндовый кластер, поверх промышленной
> схд, не sds - сильно устаревшее, может не самое надежное, но
> уже хорошо знакомое решение).

Аналогично, только на линухах. Поэтому здорово понимаю.
Тоже тихо матерюсь, но масштаб такой, что из вариантов только жить с тем, из чего можно это более-менее вменяемо собрать. Третьего не дано.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

99. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от Sgt. Gram (?), 25-Авг-20, 18:05 
> Вы постоянно всё хаите.

Не пытайся ввернуть редкое слово, если не знаешь, как оно пишется. Хаять, хаю, хаешь, хаете.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

104. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от pofigist (?), 25-Авг-20, 18:18 
> Так какая файловая система сейчас по Вашему оптимальная для продакшена на файловом сервере? Именно файловая система.

<trollface>
NTFS
</trollface>
А если серьезно - есть только один дистрибутив, жёстко заточенный под кровавый энтерпрайз, то есть - под сервера в продакшене, а не под хипстеровские поделки, обмазанные смузи. Вот и смотри что в нем за ФС...

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

122. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  –1 +/
Сообщение от пох. (?), 25-Авг-20, 21:51 
> хипстеровские поделки, обмазанные смузи. Вот и смотри что в нем за
> ФС...

и? В рекомендованной особенно позе (thinlvm под ней, как велит нам лучший редхатовский инженер Кумар (его на самом деле зовут Кумар, блжад!) ?  Смотрим, и...

И как - ты уже летишь из окна?


Ответить | Правка | Наверх | Cообщить модератору

148. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от RHEL Fan (?), 26-Авг-20, 10:23 
И что там? Ты прям саспенсу нагнал как в лучших триллерах.
Ответить | Правка | Наверх | Cообщить модератору

155. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 10:55 
> И что там? Ты прям саспенсу нагнал как в лучших триллерах.

ну раз ты спрашиваешь - в окно тебя выкинут. Просто потому что нехер спрашивать "и чо там".
Кто владеет темой - задает уточняющие вопросы, ну или сам в окно прыгает, если давно знает все ответы - потому что кроме "п-ц!" там их в конечном итоге не остается.

P.S. сглазил.
Пришли с вопросами. В смысле "у нас все упало". lvm, даже не thin.
pvscan
  No matching physical volumes found
гуглите. Особенно вас порадуют paywall'ы на найденном том, что, теоретически могло бы быть ответом.

Ответить | Правка | Наверх | Cообщить модератору

168. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от RHEL Fan (?), 26-Авг-20, 12:15 
Не найду чето никаких ужасов: или сами харды отвалились, или админы наадминили. Так, чтобы оно само куда-то девалось, не находится. Баг вот еще есть от 2017 г. https://bugzilla.redhat.com/show_bug.cgi?id=1468355. В RHEL и CentOS LVM по-умолчанию используется, вся багзилла такими проблемами была бы забита. Можно хоть ссылку какуюнить?
Ответить | Правка | Наверх | Cообщить модератору

180. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 13:10 
> В RHEL и CentOS LVM по-умолчанию используется, вся багзилла такими проблемами была бы забита.

а она и забита, только там - paywall. Не только лишь каждому можно не то что тикеты там создавать, а хотя бы ответы на них видеть.

(но на самом деле даже с подпиской я ничего путного с первой попытки не увидел - большинство порешало свои проблемы быстрой переустановкой)

> Можно хоть ссылку какуюнить?

google: pvscan No matching physical volumes found

Ответить | Правка | Наверх | Cообщить модератору

189. "Кодовая база FreeBSD переведена на использование OpenZFS (ZF..."  +/
Сообщение от пох. (?), 26-Авг-20, 17:16 
> google: pvscan No matching physical volumes found

кстати, ларчик-то открылся, но осадочек остался.
Действительно, молиться на zfs надо.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру