Как загрузиться с RAID?

энтропия, сынок. Ничего личного

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

к этому треду (ну вот нафига ты его от анонимусов огородил?)

MUMPS — многомерная нереляционная (а где-то и постреляционная) СУБД разработана в конце 60-х начале 70-х годов для задач управления медицинскими данными (карточка учёта пациентов, лабораторные анализы LIS системы, GCP/GMP/GLP, симптомы и диагнозы и доказательная медицина, и т.п.)

структура хранения данных — многомерные гиперкубы. фактически, многомерные хеш-таблицы. могут быть локальными для процесса (не хранимыми в файле не диске) и глобальными, персистентными (отсюда название: «глобалы»)

фактически это напоминает OLAP-кубы: но если в классическом OLAP в data warehouse нужно отдельно закачивать (например, MDX) из SQL-ного OLTP, то тут данные УЖЕ есть гиперкубы сами по себе.

set x=5

set foo[1]["boo"][x]=123 — локальная (для процесса) многомерная переменная (хеш-таблица с тремя ключами, третий-- значение переменной)

set ^bar(1,2,3)="QWERT" — глобальная, хранимая

СУБД имеет встроенный язык MUMPS: есть сопрограммы (рутины), процессы, транзакции, многомерные переменные.

нет индексов, но их можно (нужно) сделать руками.

СУБД похожа внутри на миниОС с сопроцессами, транзакциями, файлами, устройствами (включая виртуальные ZDEVICE), а язык СУБД MUMPS — на миниассемблер (на самом деле, интерпретатор байткода, 26 команд всего).

физически «глобалы» хранятся в BTree, подкачиваются на лету в СУБД как пейджинг страниц при своппинге в ОС.

язык простой (типа FOCAL), но гибкий и мощный: есть такая конструкция как «косвенность», eval и макросы.

прозрачно подключаются Си библиотеки как ZDLL.

в 60-70-е и далее на MUMPS была написана Vista ещё вики ещё — медицинская информационная система госпиталя ветеранов. потом они открыли исходники (git), это примерно 200 Мб такого вот интуитивно понятного кода

из-за требований для тендеров в США 60-х годов исходники не закрыли, а отдали в public domain и разработали стандарт MUMPS

далее MUMPS применялась для здравохранения, LIS-систем, OLAP, SCADA, банковские системы, трейдинг, хранение астрономических данных и т.п.

//ЛОР, ты упоролся со своей капчей! не работает под Palemon, WTF?

текущие актуальные програмные продукты MUMPS СУБД: это Cache, GT.M, MiniM, и прочие поделки типа GPL MUMPS, Mumps-to-C++ compiler и т.п.

в общем, чего повторяться: см. раз и далее по треду — например, MUMPS book от автора MiniM СУБД (бесплатно 3 пользователя, версии под все ОС, 4+ пользователя платно, есть встраиваемый абсолютно бесплатный вариант MiniMono)

есть Cache и бесплатная версия Globalsdb. есть GT.M open source (Windows вариант недопилен).

ещё советую почитать Кевина О'Кейна: O'Kane book про MUMPS и презентации, Kevin O'Kane — библиотека С++(в исходниках к книге ) и GPL MUMPS , исходники к книгам, ещё

он написал свою реализацию интерпретирующего GPL MUMPS, а также «компилятор» MUMPS-to-C++. фактически, в примерах к книге, например, ISR MUMPS глобалы используются из библиотеки С++.

полностью компилятор написать невозможно из-за макросов и конструкций языка типа @ и дважды косвенности.

в общем, читай книги — там интересно (и MUMPS book даже по русски)

если что, задавай сюда свои вопросы.

Я думаю, что ты поленился прочитать всё что написано выше, либо не всё из написанного понял.

Два в одном не получится.

неверно.

Метаданные это же не только UUID'ы дисков и тип рэйда, но и журнал.

Верно, если не будет суперблока, то будет raid без журнала. Но если подвинуть core.img, то место для суперблока будет.

Я думаю, что ты поленился прочитать всё что написано выше, либо не всё из написанного понял.

Ну как скажешь.

Если не получится, то я обязательно сообщу. Иначе же ты никогда не узнаешь правду.

Боюсь, что если результаты ты опишешь в такой же форме, как и саму идею, то я всё равно не узнаю правду.

в бложике Rob Tweed про сопряжение GT.M, Node.js и асинхронность.

любопытны примеры представления моделей данных на MUMPS: EWD часть 1 https://robtweed.wordpress.com/2013/02/11/using-mumps-globals-to-model-a-syst... 2 , JSON, Extreme Database programming with MUMPS Globals

про установку GT.M

MiniM knowledge base, бложик автора MiniM (ещё у него про гиперкомплексные интересно).

любопытное встречается за 2016 год: суровые M программисты советский MUMPS и серия интервью с разработчиками на MUMPS, чем мне не нравится SQL и прочее.

из комментариев к анекдотичному A Case of MUMPS (бедный программист Брайан.. чем-то мне напомнило когда я на 1С прогал):

yeah, it's outdated, write-only, job secure etc bla bla bla...

i keept on laughing all the way to the bank

изучать и внедрять из всего этого наверное имеет смысл в первую очередь Intersystems Cache' Cache Object Script и его объектно-ориентированные расширения MUMPS. во-вторую GT.M (емнип, Ulmart что ли его использует? какие-то куски видел в JavaScript разметке). в третью чисто для себя для каких-то простых минипроектов — ту же человекопонятную MiniM db и книжку.

вообще язык гибкий и мощный. Norton Commander в MUMPS это наверное всё-таки перебор :)) (хотя, если написать обёртку в FUSE к MUMPS и изобразить из этого какие-то «псевдофайлы» в духе plan9 и ctl командных файлов, может и взлетят такие вот микросервисы).

двигаться, ИМХО нужно в направлении типа того же Org-mode M-x org-babel-tangle — вот есть там уже примеры типа Sweawe, Rnw, Knitr. вполне можно и MUMPS воткнуть через сокеты.

и LitProg программирования непосредственно в MUMPS глобалах и рутинах (MUMPS — это кеширующий сервер глобалов и рутин), напрямую из Emacs org-mode.

в четвертую очередь, были попытки замены языка M чем-то более человекопонятным: те же Cache Object Script типа бейсика, FIS Profile PSL, Magic, MUMPS-II с ООП и прочими.

здесь, на мой взгляд, стоит обратить пристальное внимание на языки типа того же Open Object REXX. Stems в ooREXX это фактически почти «глобалы», только локалы и недопиленные. если отодрать язык M и использовать чисто уровень хранения глобалов (как например в хипстерском Globalsdb от Intersystems: = Cache - MUMPS + JavaScript, но хранилище глобалов всё то же самое).

и например, переписывать далее на другие языки, более гибкие и понятные. например: red, nimrod, common lisp :) picolisp

связка «интерпретирующий язык» типа rebol, или picolisp + хранилище глобалов может быть очень мощной

особенно если сами исходники интерпретирующие хранить в MUMPS-глобалах, и отображать напрямую REBOL-выражения, rexx-выражения и stems, персистентные символы в picolisp, CLOS и MOP в CL и прочее, например S-выражения — напрямую на глобалы MUMPS-а.

модель памяти Rust, например, тоже хорошо отображается на архитектуру СУБД MUMPS.

если бы переписать вот то что написал Kevin O'Kane с трансляцией МУМПСа в С++ и компиляцией, и использовать здесь зелёные треды и асинхронность — получаем более переносимый, гибкий и расширяемый MUMPS.

в идеале, в некоторой MUMPS-OS в духе воспоминаний старожилов MUMPS вполне себе может работать напрямую на железе, вместо ОС.

в такой ОС не нужны файлы. их можно эмулировать многомерными гиперкубами — глобалами. типа облака тегов, теги и категории, многомерная фасетная классификация...

получилась бы вполне себе интересная и расширяемая многомерная картина мира — вместо файлов и папок.

и векторный тензорный гипертекстовый фидонет поверх всего этого...

горшочек, можно было сделать отдельную тему и меня туда кастануть

Что скажете, непонятливые читатели ЛОРа, так и не смогшие ответить на простой вопрос два года назад?

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

да, у меня именно так и работает и я удачно пережил 6 лет и четыре отказа дисков

Примерно так, только лет 10+ и штук 6 горячих смен дисков без по причине pending sectors в smart.

И не лень столько писать было? Спасибо, конечно, за интересную инфу, но боюсь поциент ничего не поймёт.

Зеркалить весь диск удобно тем, что при замене диска на нем не надо вручную создавать разделы. Это работает с metadata 0.9 (потому что оно в конце дисков) и разметкой mbr внутри зеркала (потому что mbr разметка в начале диска и только в начале). С gpt разметкой все хуже, потому что она и в начале диска, и в конце (резервная копия разметки). Если делать разметку внутри зеркала, резервная копия окажется в конце зеркала, а не в конце диска. Поэтому efi firmware вполне может такой диск забраковать и не грузиться с него в режиме efi.

Но ты судя по разговору о bios boot partition собираешься грузиться в режиме legacy bios. В этом случае grub2 устанавливает boot.img в нулевой сектор (в котором расположен protective mbr), а core.img устанавливает в bios boot partition. В этом случае препятствий нет, загрузка с цельнодискового зеркала должна работать.

даже если разметка GPT не затирает метаданные mdadm v0.9:

The common format — known as version 0.90 — has a superblock that is 4K long and is written into a 64K aligned block that starts at least 64K and less than 128K from the end of the device (i.e. to get the address of the superblock round the size of the device down to a multiple of 64K and then subtract 64K). The available size of each device is the amount of space before the super block, so between 64K and 128K is lost when a device in incorporated into an MD array.

мне всё равно не хочется 0.9 применять. И возможность не применять есть - нужно отказаться от GPT и сдвинуть core.img при записи в пространство до первого раздела, чтобы он располагался после метаданных mdadm v1.2.

Суперблок v1.2 не затирает mbr, но и не позволяет зеркалить нулевой сектор диска. А суперблоки, располагающиеся в конце дисков (0.90, ddf, imsm), позволяют отзеркалить и нулевой сектор диска. Благодаря этому при замене сбойного диска вручную заполнять на нем нулевой сектор (таблицу mbr и boot.img) не требуется. Поэтому мне непонятно преклонение перед v1.2. v1.2 не подходит для полнодисковых зеркал.

Суперблок v1.2 не затирает mbr

Отлично! Осталось добиться, чтобы он ещё не затирал core.img.

но и не позволяет зеркалить нулевой сектор диска.

почему?

Потому что для полнодискового зеркала надо, чтобы нулевой сектор диска был нулевым сектором зеркала. У v1.2 это не так — нулевой сектор зеркала располагается за суперблоком. Вот пример с https://www.thomas-krenn.com/en/wiki/Linux_Software_RAID

[root@localhost ~]# mdadm -E /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 3a8605c3:bf0bc5b3:823c9212:7b935117
           Name : localhost.localdomain:0  (local to host localhost.localdomain)
  Creation Time : Tue Jul 26 07:49:50 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 20969472 (10.00 GiB 10.74 GB)
     Array Size : 20969328 (10.00 GiB 10.74 GB)
  Used Dev Size : 20969328 (10.00 GiB 10.74 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 10384215:18a75991:4f09b97b:1960b8cd

    Update Time : Tue Jul 26 07:50:43 2011
       Checksum : ea435554 - correct
         Events : 18


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)
[root@localhost ~]# 

Написано Data Offset: 2048 sectors. Значит нулевой сектор зеркала — это 2048-ой сектор диска. Сектора диска до 2048-го в состав зеркала не входят и соответственно не зеркалируются.

можно переопределить:
When creating an array, --data-offset can be specified as variable.

Нужен --data-offset=0. Сомневаюсь, что это возможно. Поскольку в 8-м секторе начинается суперблок.

Поскольку в 8-м секторе начинается суперблок.

Ну и что? Каким образом это делает невозможным --data-offset=0 ?

mbr будет на своём месте, суперблок - в своём восьмом секторе, core.img придётся сдвинуть.

Да, mdadm на двух дисках работал в сервере ещё лет 15 назад. Да, один диск умер и ничего не случилось, сервер отлично жил на втором диске.

Проверил, что --data-offset=0 не работает с --metadata=1.2:

# mdadm --create /dev/md/mirror -l 1 -b internal -n 2 --data-offset=0 --metadata=1.2 --assume-clean /dev/sdc /dev/sdd
mdadm: invalid data-offset: 0

Так что если хочешь зеркалить нулевые сектора дисков, то надо использовать суперблок формата 0.9, 1.0, ddf, или imsm — они в конце диска.

Про 1.0 интересно, потому что он располагается там же где 0.9, но при этом

The version-1 superblock is capable of supporting arrays with 384+ component devices, and supports arrays with 64-bit sector lengths.

то есть >2TB должен уметь.

Я надеюсь, что md восстанавливает эту метазапись на новом свежевставленном диске. Хотя кто его знает...

Конечно восстанавливает. У массива не может быть на одном мембере суперблок одного формата, а на другом мембере суперблок другого формата. Когда добавляешь чистый диск в массив, он создает на нем суперблок в формате этого массива. Создать на диске суперблок, не добавляя диск в существующий массив или не создавая новый массив с этим диском, невозможно.

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

Дальше переходим к отсутствию журнала

Если не поздно, то у меня получилась следующая конфигурация:

• Очистка сигнатур от старых ФС на каждом из дисков массива

  # dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024+64))
  # dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024*1024+64))
  # dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((256*1024*1024*1024+64))
  

• Подготовка всех 3-х дисков

  (parted) mklabel gpt
  (parted) mkpart bios 1MiB 3MiB
  (parted) set 1 bios_grub on
  (parted) mkpart root 3MiB 100%
  
  # mkfs.btrfs /dev/sda2 && mkfs.btrfs /dev/sdb2 && mkfs.btrfs /dev/sdc2
  

• Установка системы на 1-й диск (/dev/sda2)
• После загрузки в установленную систему делаю raid

  # btrfs device add -f /dev/sdb2 /dev/sdc2 /
  # btrfs balance start -v -dconvert=raid1 -mconvert=raid1 /
  

• Добавляю возможность системе загружаться даже при условии что один из дисков массива будет физически отключен, путем добавления опции degraded в GRUB_CMDLINE_LINUX
• Обновляю grub stage2 и на каждый из дисков пытаюсь накатить stage1 и stage1,5

  # update-grub
  # grub-install /dev/sda && grub-install /dev/sdb && grub-install /dev/sdc
  

Небольшие пояснения: у меня сервер hp microserver gen7, в нем используется bios а не uefi. После загрузки bios упавление передается в 1-й сектор зарузочного диска(grub stage 1(boot.img)). Сам по себе stage 1 сильно обрезан в размере, поэтому он не может работать с некоторыми ФС. Для расширения его возможностей придумали так называемую bios boot partition, куда записывается grub stage 1.5(core.img). Там имеется возможность поддержать продвинутые ФС, в том числе, как и в моем случае, загрузку с raid массива созданного средствами btrfs.

Возможно stage 1.5 умеет загружаться с mdadm, я бы пробовал копать в этом направлении.

не поздно, но мне непонятно, зачем btrfs. Я бы понял, если бы это была zfs. И самое главное - неясно, чем и то и другое лучше, чем mdadm. Ну ладно, у zfs больше контрольных сумм разных. А в части преимуществ btrfs у меня нехватка знаний.

Так исторически сложилось, мои рассуждения были такими:

zfs и btrfs имеют примерно одинаковые возможности, но zfs не включена в ядро linux, мене показалось что это не с проста, но разбираться особо не стал. Это немного напрягло и я выбрал btrfs из этих двух. mdadm+lvm+обычная ФС имеют +/- такие же возможности как вышеозвученные. А если нет разницы, зачем лишние уровни абстракции?

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

Так же мой опыт показал что вместо одной ФС на все диски(в моем случае 4), лучше иметь несколько ФС(в моем случае 2 даска в raid1 под систему и 2 даска в raid1 под данные). Так проще апгрейдь железо.