LINUX.ORG.RU

Экспериментальная реализация RAID5 и RAID6 в Btrfs

 ,


0

2

Крис Мэйсон (Chris Mason), автор файловой системы Btrfs, сообщил об интеграции в основной git-репозиторий проекта экспериментальной реализации RAID5 и RAID6, встроенной в Btrfs. Поддержка RAID5/6 доступна для тестирования в рамках ветки raid56-experimental, созданной как для компонентов Btrfs уровня ядра, так и для набора утилит btrfs-progs.

Хотя реализация RAID5/6 во многом похожа на MD raid, встраивание поддержки RAID в Btrfs имеет ряд преимуществ. Например, имеется возможность применения разных уровней RAID к метаданным и непосредственно хранимым данным, или можно инициировать частичное перестроение RAID в случае выявления несоответствия контрольных сумм в процессе работы файловой системы. Появляется возможность выполнения таких операций, как перестановка данных между дисками (restriping) или добавление/удаление дисков в привязке к транзакциям в файловой системе. Планируется обеспечить привязку логики работы RAID к состоянию метаданных btrfs, например, в процессе функционирования RAID пропускать операции чтения для блоков, не задействованных в файловой системе.

При тестировании реализация RAID5/6 в Btrfs опередила по производительности MD raid, в основном, благодаря устранению некоторых узких мест и задействованию таких особенностей, как переработанный кэш распределения данных по дискам (Stripe cache), поддержка слияния частичных stripe-операций и вычисления контрольных сумм без задержки, в синхронном режиме. Кроме того, отмечается меньшая эффективность кэширования в MD, приводящая к большему числу операций чтения с дисков.

Из пока не реализованных, но запланированных на ближайшее время возможностей отмечается поддержка операции scrub для проверки наличия bad-блоков на входящих в RAID дисках; поддержка операции TRIM (discard), которая позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы; добавление в набор утилит поддержки частичного перестроения RAID (parity rebuild); возможность множественного зеркалирования (тройное зеркало из RAID1).

>>> Подробности

★★★★★

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

не забываем, кто спонсирует её разработку.

богатая компания которой нужны скорость, масштабируемость и надёжность?

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

богатая компания которой нужны скорость, масштабируемость и надёжность?

Оракл-то? Пусть zfs перелицензируют для начала и внезапно появится все сразу.

tazhate ★★★★★
()

Отлично, они изобрели zfs. Ну что ж, с разморозкой их.

redixin ★★★★
()

Не нужно!

Уже есть mdadm и LVM.

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

> А ты чем его смотришь?

Смотреть можно чем угодно. А попытка создать новый мегабайтный файл приводит к «no space left on device».

Смахивает на старые баги с global_rsv.

http://dev.gentoo.org/~slyfox/butter-meta.sh Так?

4096+0 записей получено
4096+0 записей отправлено
 скопировано 4294967296 байт (4,3 GB), 1,17299 c, 3,7 GB/c

WARNING! - Btrfs v0.20-rc1-37-g91d9eec-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on foo.img
        nodesize 4096 leafsize 4096 sectorsize 4096 size 4.00GB
Btrfs v0.20-rc1-37-g91d9eec-dirty
dd: запись «foo_is_here/4GB»: На устройстве кончилось место
3659+0 записей получено
3658+0 записей отправлено
 скопировано 3835691008 байт (3,8 GB), 29,7476 c, 129 MB/c
1+0 записей получено
1+0 записей отправлено
 скопировано 1048576 байт (1,0 MB), 0,359357 c, 2,9 MB/c
итого 1,0M
-rw-r--r-- 1 root root 1,0M февр.  4 19:19 1MB

Работает.

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

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

а что с ними?

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

А ты возьми да и посмотри на NTFS после полугода без дефрага.
Нормальным чем-то посмотри, перфектдиском или о&о.

pekmop1024 ★★★★★
()

Будет ли btrfs производительнее ext4, пусть даже через год-два после финального релиза? Если да, то нужно.

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

Будет ли btrfs производительнее ext4, пусть даже через год-два после финального релиза? Если да, то нужно.

btrfs намного больше, чем просто ФС. потому в лоб сравнивать бессмысленно.

btrfs может быть быстрее ext4 если включено сжатие. также CoW может дать прирост производительности по сравнению с аналогичным режимом ext4 (включено полное журналирование данных).

плюс btrfs с RAID удобнее, чем набор ext4 + LVM + mdadm.

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

btrfs может быть быстрее ext4 если включено сжатие

btrfs никак не быстрее ext4, даже если включено сжатие.

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

На моих тестах вышло, что ext4 с полным журналом чуток медленнее, чем btrfs с включенным lz4.

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

а что с ними?

Взрывной рост. Либо количества, либо внешней фрагментации. Первое приведёт к «на пустом разделе нет свободного места», второе к «открыть каталог с двумя файлами занимает 10 минут». С FFS-подобными аллокаторами (+ улучшения) это ещё терпимо, с NTFS-подходом «пишу куда придётся» это выльется в ад. Версионные ФС MS постоянно обещали в следующих версиях со времён выхода Windows 2000. Вот уже 13 лет прошло, а никак не родят.

i-rinat ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Btrfs - редкостные тормоза. Перевёл на прошлой неделе свой рут с ext4 на btrfs, потом долго чертыхался, возвращая всё обратно

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

А чего ты хотел от анонимуса? ЛОЛ

Я не поленился бы залогиниться, если btrfs от этого лучше бы стала работать...

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

в семерке походу встроенная дефрагментация в фоне или просто. в общем нет проблем. еесли том не под завязвку забит.

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

А в семёрке обычная NTFS. Если бы там было CoW, то дефрагментатор понадобился прямо во время установки. Прямо воплощение анекдота: «— Сколько места занимает Windows? — Сколько найдёт, столько и займёт.» Только на этот раз уже всерьёз.

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

я знаю, что там обычная нтфс. а еще знаю, что там нет проблем с фрагментацией. если том забит не под завязку.

и это не теория. это факт. а факт вещь упрямая.

в хр проблемы были. в висте - не знаю, не работал ни дня с ней.

dk-
()

объясните несведущему

нахрена логический уровень (рейд) хранения данных пихать в ФС?! зачем?! еще антивирус туда засуньте.

dk-
()

Оформи как новость

The native Linux kernel port of the ZFS filesystem. To get started with ZFS on Linux simply download the latest release and install using the directions for your distribution.

http://zfsonlinux.org/

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

не работал ни дня с ней.

А вот у меня в основном опыт с XP. Там тоже всё нормально, хрустит и хрустит. Но была забавная проблема. Расчётная программа передавала другой данные через файл на диске, единственный здравый способ в той ситуации. Данных на 20 Мб, но читались/писались они больше десятка секунд. Выяснилось, что этот жалкий 20-метровый кусок NTFS умудряется растерзать на сотню кусков. И это на разделе в 200 гигов с 50% свободного места. Я такого вообще не ожидал, просто не верилось, что такое возможно. Как понимаешь, дефрагментацию раз в 20-30 секунд делать не будешь.

С семёркой вообще было забавно. Включил её, она загрузилась и хрустит. Я помню, что она там что-то сама двигает, ладно, думаю, прохрустится, перестанет. Прихожу через час — она хрустит. И так пока восстановление не выключил, она хрустела. С обновлениями вообще просто сказка. «Не выключайте, пока идёт установка обновлений». На ноуте, ага. У меня на нетбуке с тормозным диском обновления быстрее ставились.

и это не теория. это факт. а факт вещь упрямая.

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

i-rinat ★★★★★
()
Ответ на: объясните несведущему от dk-

нахрена логический уровень (рейд) хранения данных пихать в ФС?! зачем?!

Ну вот допустим у тебя диск наполовину заполнен файлами и ты решил сделать raid. Докупил ещё такой же, подключил к пулу, сказал «хочу зеркало!». Объём данных, которые надо скопировать, в два раза меньше, чем в случае обычного raid'а. Для терабайтного диска это час вместо двух.

еще антивирус туда засуньте.

Анти что? :-)

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

у меня часто очень дискоемкие операции. сшивки панорам.

10-14 файлов по 150мб размером шьются в один файл 600мб размером. даже при 16гб рамы (1гб жрет ОСь, остальное сшивающий софт) файлы кэшей на диске - 15-30гб. шьет махом. делал грубые оценки - местами упирается в физическую скорость записи на носитель (было актуально до прехода на ссд).

а еще я несколько десяктов раз шил другого рода панораму: из 800 исходных файлов сшивалась панорам под 12-20гб размером. там кэши занимали по 300-500гб. тысячами постоянно перезаписываемых файлов, размером от килобайт до 512мб.

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

в линуксе - не пробовал. пробовал в макоси. разницы не увидел.

короче резюмирую из свого опыта: на ХР с нтфс проблемы бывали (фрагментация). на семерке - ниразу.

dk-
()
Ответ на: комментарий от i-rinat

Такие мысли мне приходили в голову, когда дома с рейдами (0, 1, 5, 6) баловался. Но думал что это адское извращение :)

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

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

У тебя профессиональный софт, написанный с учётом реалий ФС в Windows. Наверняка место резервируется и т.п., это и в XP будет работать так же хорошо.

А у меня самописная программа, которая тупо пишет данные подряд. Если б я заморочился, то тоже бы нормально было с фрагментацией. Но зачем это нужно, если ext4 делает это за меня?

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

Не, резервации места нет. пару раз обламывался, когда «оно там себе считает» а я место выжрал. Да и... заране незвестно сколько именно сожрется. Прдваритльная оценка груба.

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

И данные терял на нй ТОЛЬКО от своей же криворукости и того, что «Лез куда не следует» (руками там таблицы править или тома разрушать).

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от dk-

Не, резервации места нет. пару раз обламывался, когда «оно там себе считает» а я место выжрал. Да и... заране незвестно сколько именно сожрется. Прдваритльная оценка груба.

Достаточно метров по 50-100 за раз резервировать. Тогда ФС будет искать свободный кусок этого размера и занимать его целиком. Даже на кусках в 20 метров фрагментацию уже не почувствуешь.

i-rinat ★★★★★
()
Ответ на: комментарий от dk-

твоя теория, нахрена(!) в ФС пихать рейды?

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от Kindly_Cat

мне кажется, что это усложнение и увеличение числа сущностей.

а, как мы знаем, чем больше элементов в системе, тем выше вероятность отказа.

и... разве считать XOR на спец.железке (контроллере) не дешевле, чем на CPU? на приличных нагрузка оверхед не будет напрягать?

и да, я вкурсе, про XOR софтовый на пентиум 3.

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

мне кажется, что это усложнение и увеличение числа сущностей

Креститься надо.

а, как мы знаем, чем больше элементов в системе, тем выше вероятность отказа

Тут не надо теорию дрочить надо, а взвешить плюсы и минусы. Плюсы перевешивают минусы - значит, оправданно.

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

mdadm и LVM чем хуже? (на пальцах)

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

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

Тебя слово «дрочить» ввергло в бугурт? Или «креститься надо»? Может, мне с тобой как с девочкой общаться? Ок.

Kindly_Cat
()
Ответ на: комментарий от dk-

mdadm и LVM чем хуже?

С mdadm я, солнышко, не работал, а вот за LVM могу скромненько сказать, что это весьма непродуманненькая технология. Снапшоты ейные, дорогая, очень не дотягивают до оных в btrfs, как по скоростюшечке, так и по удобству использования. И потом, как уже говорили выше по тредюшку - очень плоховастенько, когда правая ручечка не ведает, что творит левая. То есть, умничка ты моя, менеджерчику томов лучше таки знать, что и как делает файловая системочка. Таки делишечки, хихи.

Kindly_Cat
()
Ответ на: объясните несведущему от dk-

еще антивирус туда засуньте

zfs set vscan=on

vscan=on | off 
Controls whether regular files should be scanned for viruses when a file is opened and closed. In addition to enabling this property, the virus scan service must also be enabled for virus scanning to occur. The default value is off.
unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

думаешь тут это,юзерам ext4 и ko, о чем нибудь скажет ?

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

Ну вот допустим у тебя диск наполовину заполнен файлами и ты решил сделать raid. Докупил ещё такой же, подключил к пулу, сказал «хочу зеркало!». Объём данных, которые надо скопировать, в два раза меньше, чем в случае обычного raid'а.

и это все? и ради этого смешивать слои блочного устройства и фс?!

достаточно было бы куда-нить в районе vfs (или отдельной утилитой, собираемой из исходников фс) сделать обязательным выдачу карты занятых секторов (1 бит соответствует 1 сектору, скажем 4 килобайтам на диске)

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

или же ты и это хочешь запихать в комбайн БлочноеУстройствоИОдновременноФайловаяСистема?

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