LINUX.ORG.RU
Форум — Admin  

создание хранилища на btrfs

 , ,


2

2

Идея состоит в том, чтобы использовать максимально возможное количество винтов и их объема. Создаю ФС 

mkfs.btrfs -m raid10 -d single /dev/sdb /dev/sdd /dev/sde /dev/sdf
закидываю данные, балансирую, 
root@debian-gpt:~# btrfs fi show
Label: none  uuid: b26e5067-4ca5-4809-9785-6a64470279d4
        Total devices 4 FS bytes used 2.32GiB
        devid    1 size 2.00GiB used 992.00MiB path /dev/sdb
        devid    2 size 2.00GiB used 992.00MiB path /dev/sdf
        devid    3 size 2.00GiB used 160.00MiB path /dev/sdd
        devid    4 size 2.00GiB used 992.00MiB path /dev/sde
смотрю вывод, 
root@debian-gpt:~# btrfs fi usage /srv/
Overall:
    Device size:                   8.00GiB
    Device allocated:              3.06GiB
    Device unallocated:            4.94GiB
    Device missing:                  0.00B
    Used:                          2.32GiB
    Free (estimated):              5.06GiB      (min: 2.59GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00    Global reserve:               16.00MiB      (used: 0.00B)

Data,single: Size:2.44GiB, Used:2.31GiB
   /dev/sdb      832.00MiB
   /dev/sde      832.00MiB
   /dev/sdf      832.00MiB

Metadata,RAID10: Size:256.00MiB, Used:2.47MiB
   /dev/sdb       64.00MiB
   /dev/sdd       64.00MiB
   /dev/sde       64.00MiB
   /dev/sdf       64.00MiB

System,RAID10: Size:64.00MiB, Used:16.00KiB
   /dev/sdb       16.00MiB
   /dev/sdd       16.00MiB
   /dev/sde       16.00MiB
   /dev/sdf       16.00MiB

Unallocated:
   /dev/sdb        1.11GiB
   /dev/sdd        1.92GiB
   /dev/sde        1.11GiB
   /dev/sdf        1.11GiB
Останавливаю систему, выдираю один из винтов после этого монтирование возможно только в RO режиме 
 mount -o ro,degraded,recovery /dev/sdb /srv/
root@debian-gpt:~# btrfs fi usage /srv/
Overall:
    Device size:                   8.00GiB
    Device allocated:              3.06GiB
    Device unallocated:            4.94GiB
    Device missing:                2.00GiB
    Used:                          2.32GiB
    Free (estimated):              5.06GiB      (min: 2.59GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               16.00MiB      (used: 0.00B)

Data,single: Size:2.44GiB, Used:2.31GiB
   /dev/sdb      832.00MiB
   /dev/sde      832.00MiB
   missing       832.00MiB

Metadata,RAID10: Size:256.00MiB, Used:2.47MiB
   /dev/sdb       64.00MiB
   /dev/sdd       64.00MiB
   /dev/sde       64.00MiB
   missing        64.00MiB

System,RAID10: Size:64.00MiB, Used:16.00KiB
   /dev/sdb       16.00MiB
   /dev/sdd       16.00MiB
   /dev/sde       16.00MiB
   missing        16.00MiB

Unallocated:
   /dev/sdb        1.11GiB
   /dev/sdd        1.92GiB
   /dev/sde        1.11GiB
   missing         1.11GiB
Текущая система будет работать на уровне предсказания отказа HDD. Возможно у меня недомонимание принципов работы ФС, возникло куча вопросов:

  • почему я не могу смонтировать, в дегрейд режиме на запись
  • можно ли создать фс обычный stripe с зеркалированием метаданных, чтобы в случае выпадения железки система теряла только то, что было на потерянном винте, после ребалансировки данные обновились и система дальше продолжила работу в режиме rw
  • можно ли и как подмонтировать отдельно взятое устройство из собранного массива и вытащить оттуда данные

 ← 1 2 →

почему я не могу смонтировать, в дегрейд режиме на запись

зачем?

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

зачем??

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

зачем???

у тебя шесть хардов и жуткая нехватка экстрима? неудержимо хочется фигачить btrfs-restore по живому массиву?

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Вопросом на вопрос отвечать некорректно, есть идеи делитесь, нет воду переливать из пустого в порожнее нестоит. Мое понимание разделения data/metadata означает восстановление первого из второго. Винты расходники. При последовательно расположеных данных и зеркалировании метаданных хотелось бы в случае выпадения одного из устройств (в идеале неважно - сколько позволяет уровень рэйда метаданных), заменить нерабочее устройство, перепроверить фс на целостность выкинув нерабочие цепочки данных и продолжить работу. Потерянные данные будут и так восстановлены из бэкапа. На текущий момент потеря винта физически - это потеря всего массива данных, хоть и кое что можно считать если фс в режиме ro. Пойдем с другой стороны, вынимаю винт с рабочей/нерабочей системы, монтирую ее чтобы считать остаток данных, копия метаданных на диске есть, но вот считать ничего не получается, а хотелось бы хотя бы остатки вытащить.

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

Мое понимание разделения data/metadata означает восстановление первого из второго.

разупорись

Потерянные данные будут и так восстановлены из бэкапа.

не мудри

На текущий момент потеря винта физически - это потеря всего массива данных

raid 5 и закрывай тред

t184256 ★★★★★
()

Идея состоит в том, чтобы использовать максимально возможное количество винтов и их объема

С raid10 это невозможно. Напоминаю, что в таком случае будет доступна только половина объема всех дисков, остальное будет зеркалом.

почему я не могу смонтировать, в дегрейд режиме на запись

Это by design, чтобы не угробить данные, если они еще остались.

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

Конечно нельзя, у тебя же файловая система растянута на несколько дисков, один файл может начинаться на одном и заканчиваться на другом (очень грубо).

Вообще, почему не взять mdraid, если хочется софтрейд? Он несложный и понадежнее бтрфс.

lu4nik ★★★
()
Ответ на: комментарий от Niko_F

Зачем так усложнять? Рейд был придуман, чтобы при отказе дисков он с какой-то вероятностью сохранил ВСЕ данные, чтобы не было простоя на разворачивание бэкапов. Но если, как ты пишешь, бэкапы есть, то почему при аварии, разрушившей рейд, просто не восстановиться полностью из бэкапов?

lu4nik ★★★
()
Ответ на: комментарий от lu4nik 
       --type SegmentType
              Create  a  logical  volume  that uses the specified segment type
              (e.g.   mirror(-m),   raid5,   snapshot(-s),   thin(-T),   thin-
              pool, ...).   Many segment types have a commandline switch alias
              that will enable their use (-s is an alias for --type snapshot).
              However, this argument must be used when no existing commandline
              switch alias is available for the desired type, as is  the  case
              with  cache,  error, raid1, raid4, raid5, raid6, raid10 or zero.
              See lvmcache(7) for more info about caching support.  Note  that
              the cache segment type requires a dm-cache kernel module version
              1.3.0 or greater.
anonymous
()
Ответ на: комментарий от t184256

raid 5 и закрывай тред

Да, raid5 на 6и 3хтерабайтниках хороший путь решения проблем с отсутствием геморроя, как раз то, что хочет ТС. +1, присоединяюсь.

Deleted
()
Ответ на: комментарий от anonymous

Интересно, надо запомнить, обычно встречал гайды, как запилить LVM поверх mdraid. А LVM умеет во всякие штуки вроде e-mail оповещения из коробки?

lu4nik ★★★
()
Ответ на: комментарий от lu4nik

dmeventd

LVM PLUGINS
Mirror — Attempts to handle device failure automatically. See lvm.conf(5).

Raid — Attempts to handle device failure automatically. See lvm.conf(5).

anonymous
()
Ответ на: комментарий от lu4nik

под самбу надо одно, под базы данных второе, под почтовик третье. тут помню тему я поднимал, почему перешёл на btrfs с ext4, так мне про оптимизацию md тогда весь мог промыли...

erzented
()
Ответ на: комментарий от erzented

зачем - зашкафом raid10 метаданные - нужен для того чтобы в случае потери восстановить из рабочей копии, single данные - этот режим меня вполне устраивает, максимальный отдаваемый объем

Niko_F
() автор топика
Ответ на: комментарий от Deleted

raid 5 и закрывай тред

Да, raid5 на 6и 3хтерабайтниках хороший путь решения проблем с отсутствием геморроя, как раз то, что хочет ТС. +1, присоединяюсь.

raid 5/6 еще не на продакшен уровне

Niko_F
() автор топика
Ответ на: комментарий от erzented

md сложнее и геморнее в оптимизации, в то время как zfs/btrfs рейды уже оптимизированы сразу под несколько задач.

Да ладна... Почитай, например, мануал по оптимизации zfs для всяких разных БД. А в mdadm на raid-5(6) всего то надо большие чанки забабахать и stripe_cache_size увеличить, а на raid-1(10) и этого не надо делать.

King_Carlo ★★★★★
()
Ответ на: комментарий от lu4nik

Идея состоит в том, чтобы использовать максимально возможное количество винтов и их объема

С raid10 это невозможно. Напоминаю, что в таком случае будет доступна только половина объема всех дисков, остальное будет зеркалом.

Кто вам такое сказал? уровень raid10 только для метаданных, а метаданные, это не данные, читайте внимательно.

Конечно нельзя, у тебя же файловая система растянута на несколько дисков, один файл может начинаться на одном и заканчиваться на другом (очень грубо).

насколько я понял btrfs как раз таки располагает данные именно по устройствам, а не по файловой системе

Btrfs предоставляет достаточно гибкие средства по зерклированию данных и расширению доступного пространства раздела. Дополнительные диски можно подключить в любое время, расширив таким образом размер ФС или обеспечив отказоустойчивость. По умолчанию при размещении радела на нескольких дисках осуществляется зеркалирование метаданных на двух дисках, но сами данные распределяются по данным дискам без резервирования (размер ФС получается равным суммарному размеру дисков). Если диск один, то две копии метаданных размещаются на нём. Учите матчасть.

Niko_F
() автор топика
Ответ на: комментарий от King_Carlo

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

erzented
()
Ответ на: комментарий от svr4

инфа на 14й год https://btrfs.wiki.kernel.org/index.php/Production_Users

а то, что у них есть не стабильные фичи, аля RAID5/6, никто этого не скрывает и не заставляет юзать, а такие фичи есть у всех :)

сам использую 3й год на обьёмах в 20-40T (у ext4 из коробки были проблемы с таким обьёмом, поэтому начал использовать btrfs) - полёт отличный, пару раз вытягивал данные при неслабых аппаратных сбоях на уровне hwraid/hdd, при этом система несколько часов шуршала вениками/рейдами при монтировании после сбоя, но данные не пропадали, хотя думал, что так не бывает :)

TuxBy
()
Ответ на: комментарий от lu4nik

Raid1,5,6,10 все потеря дискового ресурса. Объем хранилища растет геометрически, уже >30Тб, а завтра 300Тб и все это синкается на 3 удаленных офиса. И к примеру когда теряется один винт на 30Тб пересборка массива и балансировка уже сейчас идет 3-и сутки. Нужно решение на уровне файловой системы, а не на уровне железа(гибридные решения софт+железо не интересует, практическая сторона исъезжена и используется максимально эффективно). А теперь еще раз про идею и попрошу не лить воду. Интересны только рабочие решения и практика применения.

идея в том что: - веников будет не 6ть, а допустим 16 или 160, различного размера и так далее - так как данные изначально «избыточны», ценность данных на одном hdd не имеет значения (из предварительных тестов в режиме данных single файл записывается целиком на один hdd и выпадут только целые файлы, а не туча кусков ) - режим rw нужен для того, чтобы спокойно продолжать работать, не обращая внимания на выпадения 1-2x hdd, просто добавлять новые hdd по мере необходимости свободного места

возможно btrfs это не правильное направление, поэтому попытаюсь другими словами описать идею на примере бумажной библиотеки, где этаж = hdd, книга = файл:

дано: - библиотека из 5ти этажей (ala DATA) - картотека (не уверен как это правильно в библиотеке называется) где лежит опись всех книг и ссылки на каком этаже книга (ala METADATA) , но копий картотеки как минимум два (ala METADATA в режиме RAIDxxx) - уникальных книг нет, то есть любую потерянную книгу легче заново купить в магазине за Х рублей, чем каждую покупать дважды/трижды и потом думать где хранить копии или потратить XXX миллионов на мега систему пожаротушения и так далее - книга является единым целым и не может быть половина книги на одном этаже, а вторая на другом

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

или в итоге, при сгорании всего, кроме например одного этажа: - мы просто смотрим книги которые остались и заново формируем картотеку - ремонтируем сгоревшие этажи и на них размещаем новые книги и копии сгоревших

Niko_F
() автор топика
Ответ на: комментарий от erzented

что zfs рейд на много лучше md

Бесспорно лучше, но лучше не значит проще. Самба подразумевает большой i/o на чтение и запись, следовательно нужны выносить ZIL на SSD и L2ARC на другой SSD.

King_Carlo ★★★★★
()
Ответ на: комментарий от erzented

Смотря какие задачи, где то ARC в ОЗУ достаточно, где то нужны большие iops-ы и нужно выносить кэши на ssd.

King_Carlo ★★★★★
()
Ответ на: комментарий от Niko_F

Я, кажется, понял, что имеешь ввиду, хотя объяснение в высшей мере непонятное. Если я правильно понял, при аварии ты хочешь только знать какие файлы утеряны, чтобы восстановить именно их из бэкапа, при этом сохранить rw доступ ко всем остальным файлам.

Также ты неверно указал начальные условия. Так тебе хранилище на 18 ТБ, или на сотни терабайт? Это разные вещи, и требуют разных подходов. Если тебе действительно нужно хорошее горизонтальное масштабирование на много-много терабайт, то лучше уж смотреть в сторону готовых решений, если есть деньги. Там многое продумано до нас, и надежность повыше.

lu4nik ★★★
()
Ответ на: комментарий от lu4nik

Я, кажется, понял, что имеешь ввиду, хотя объяснение в высшей мере непонятное. Если я правильно понял, при аварии ты хочешь только знать какие файлы утеряны, чтобы восстановить именно их из бэкапа, при этом сохранить rw доступ ко всем остальным файлам.
Также ты неверно указал начальные условия. Так тебе хранилище на 18 ТБ, или на сотни терабайт? Это разные вещи, и требуют разных подходов. Если тебе действительно нужно хорошее горизонтальное масштабирование на много-много терабайт, то лучше уж смотреть в сторону готовых решений, если есть деньги. Там многое продумано до нас, и надежность повыше.

Да помоему понятнее уже некуда, в особенности для людей которые вращаются в этом. 18Тб я использовал как пример, на текущий момент у меня уже 30+Тб. Готовые решения известны и не интересуют т.к. стоят совсем не тех денег которые выделяются бюджетом.

Niko_F
() автор топика
Ответ на: комментарий от erzented

дада, вот прям и под почтовик, и самбу, и бд, сразу оптимизировано под всё.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Niko_F

Объем хранилища растет геометрически, уже >30Тб, а завтра 300Тб и все это синкается на 3 удаленных офиса.

Тогда ты вообще не на то смотришь </thread>

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Объем хранилища растет геометрически, уже >30Тб, а завтра 300Тб и все это синкается на 3 удаленных офиса.

Тогда ты вообще не на то смотришь </thread>

Ну так что вы здесь холивар на тему lvm raid. Конретики во всех постах никакой, в части Вас только фразы зачем? зачем?? зачем???, ни одного предложения касающееся темы. Зато Все дают понять что они в «теме». Есть предложения решения, излагайте, нет - ДО свидания.

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

18Тб я использовал как пример, на текущий момент у меня уже 30+Тб

Данные, хранимые на этом сторадже, не представляют вообще никакой ценности? Тогда можно и btrfs, как худшее из возможных решений.

King_Carlo ★★★★★
()
Ответ на: комментарий от King_Carlo

18Тб я использовал как пример, на текущий момент у меня уже 30+Тб
Данные, хранимые на этом сторадже, не представляют вообще никакой ценности? Тогда можно и btrfs, как худшее из возможных решений.

так как данные изначально «избыточны»...

а почему по вашему btrfs это худшее решение?

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

а почему по вашему btrfs это худшее решение?

Потому что это альфа версия, находится в статусе experimental и under heavy development. С этой штукой можно играть в игру «урони меня», но для хранения данных btrfs непригодна.

King_Carlo ★★★★★
()
Ответ на: комментарий от King_Carlo

Потому что это альфа версия, находится в статусе experimental и under heavy development. С этой штукой можно играть в игру «урони меня», но для хранения данных btrfs непригодна.

Мне кажется или только я живу в 21 веке, остальные коментаторы в каменном ?

https://www.opennet.ru/opennews/art.shtml?num=35561

Файловая система Btrfs

Дата представления Стабильная: 4.3.1, 16 ноября 2015 года

BTRFS используется конкретно мной и коллегами уже 3ий год в продакшене. Виртуализация, базы данных, файлопомойки более 100Тб данных. Все закрывайте пост и живите дальше облачными представлениями нестабильности ФС

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

Сам читал что там написано? А я прочитал, цитирую:
«в SUSE пока не поддерживаются такие возможности Btrfs, как управление несколькими разделами, RAID и хранение данных в сжатом виде. Интеграция fsck.btrfs также пока находится только в планах»

Если в понимании разработчиков suse это готовность к применению в продакшене, то я очень сочувствую пользователям этого дистрибутива.

Виртуализация

Ну и зря, дисковое i/o в ВМ, расположенных в файлах-контейнерах на btrfs на порядок (в 10 раз, ага) ниже, чем на других ФС. Так что я примерно представляю что у тебя за продакшн.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

Сам читал что там написано? А я прочитал, цитирую:

Вот именно читал, пост на opennet от 11.12.2012 11:32 и следующая строка Стабильная версия: 4.3.1, 16 ноября 2015 года

а теперь умник читай, прежде чем постить https://en.wikipedia.org/wiki/Btrfs

не умеешь по вражески, читай на русском https://ru.wikipedia.org/wiki/Btrfs

Виртуализация

Да виртуализация, продакшен, 300+ машин и все это прекрасно работает, летает

Niko_F
() автор топика
Ответ на: комментарий от t184256

конкретно — создавай тред про распределенные ФС, этот хорони.

BTRFS - это не распределенная ФС

Интересуют конкретные практики применения этой фс или аналогичных для решения поставленой задачи. Вопрос был задан, ни ответа ни конкретных предложений решения. Куча «умников» и бесполезной туфтологии, что фс гавно, не продакшен система и покупки спец железок которые решат проблему.

Удалите пост, чтобы у Вас не появлялось желания бесполезной писанины

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

а теперь умник читай, прежде чем постить

Читаю:
as of August 2014, the file system's on-disk format has been marked as stable.
Для тебя, стало быть, нет разницы между file system's on-disk format и, собственно file system? Ну чё поздравляю, меньше знаешь - крепче спишь.

Да виртуализация, продакшен, 300+ машин и все это прекрасно работает, летает

Оно не может летать, я периодически тестирую это дело, как я уже писал выше дисковое i/o виртуалок на btrfs на порядок ниже чем на других ФС.
Не веришь мне, можешь поискать на phoronix-е, тестировали они это дело.

King_Carlo ★★★★★
()
Ответ на: комментарий от King_Carlo

Читаю:
as of August 2014,

А Вы часики научитесь переводить, на дворе 2015. Цирк уехал, а клоуны остались и пытаются мне доказать, что BTRFS до сих пор находится на стадии тестирования.

периодически тестирую это дело

Продолжай дальше, ПЕРИОДИЧЕСКИ, тестировать. А я использую и это все работает.

Оно не может летать, я периодически тестирую это дело, как я уже писал выше дисковое i/o виртуалок на btrfs на порядок ниже чем на других ФС. Не веришь мне, можешь поискать на phoronix-е, тестировали они это дело.

Может просто Вы не умеете это готовить? Ну не нравится Вам эта фс, не нада доказывать мне это. И то,что эта ФС не достойна ни вашего ни моего внимания.

Удалите пост плз

Niko_F
() автор топика
Ответ на: комментарий от King_Carlo

Вот нашёл ZFS, BTRFS, XFS, EXT4 and LVM with KVM – a storage >>performance comparison, наслаждайся:

http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-an...

Клоун, покажи мне здесь конкретное решение моей проблемы?

Свободен, продолжай дальше тестировать, а лучше мозг свой протестируй и глаза

Niko_F
() автор топика
Ответ на: комментарий от Niko_F

Цирк уехал, а клоуны остались и пытаются мне доказать, что BTRFS до сих пор находится на стадии тестирования.

А где цирковая лошадь увидела, что btrfs не находится на стадии тестирования? Да и ты сам тут стучал копытом мол 3 года в продакшне и всё было стабильно, ты уж определись. Я тебе намекну, когда оно станет стабильно, непременно появится в rhel.

А я использую и это все работает.

Вас тут на ЛОРе хватает таких, у которых всё работает, на мамином локалхосте, как выясняется.

Может просто Вы не умеете это готовить?

Научи.

Клоун, покажи мне здесь конкретное решение моей проблемы?

Круто, ты злишься, значит ты не прав. А проблема твоя, в твоей постановке, неразрешима.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Admin