LINUX.ORG.RU

Деградация zfs, btrfs при заполнении диска

 ,


5

6

Не так давно я перевёл свою домашнюю файлопомойку (1x1TB, 2x500GB) на zfs. Дисков мало, все они разные, поэтому никакого рейда — просто критические данные лежат на подтоме, для которого включено дублирование данных.

Сначала всё было хорошо. Потом ввод-вывод стал дико тормозить. А потом я наткнулся на статью, в которой красочно рассказано, как расп-дорашивает zfs от случайных перезаписей, если забить её данными хотя бы наполовину. А у меня из 1.8T занято 1.5T, и, видимо, так дальше жить нельзя.

Отсюда три вопроса:

  1. что делать (помимо того, что «вдоль» и «докупать больше дисков»)?
  2. как будут обстоять дела в подобных ситуациях у btrfs?
  3. какие ещё есть ФС из «комбайнов» со снапшотами, подтомами, компрессией и так далее?

Update #1. Нагрузка на ФС — торренты и sqlite-овая БД размером в один гигабайт. Тормоза наблюдаются с последней.

Update #2. После того, как я сделал synchronous = 0; для sqlite-овой БД, всё стало сильно лучше. Вопрос «какого хрена?» всё ещё в силе, т. к. intent log имеется.

★★★★★

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

Если один из дисков в массиве умирает, spare-диск тут же подключается к массиву и происходит синхронизация.

ресилверинг который? как определяется критерий «диск умер»?

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

Роскошь это субъективно. Для тебя это золотой унитаз, для меня — проехать одну остановку общественным транспортом вместо того чтобы пройти пешком.

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

Я кажется понял в чём наше расхождение. Ты считаешь, что чанки всегда для доступа к данным нужно считывать полностью. То есть если нужны 100 байт, которые в чанке A2, то нужно всё считать с A1 по A4. Я всегда считал, что это не так, а то это же какой оверхед бы был. ИМХО, считывать чанки c A1 по A4, для доступа к 100 байтам данных в чанке A2 нужно только когда у тебя A2 потерян, из-за выхода из строя одного шпинделя.

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

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

В смысле все чанки одного страйпа ? Ну да.

ИМХО, считывать чанки c A1 по A4, для доступа к 100 байтам
данных в чанке A2 нужно только когда у тебя A2 потерян, из-за
выхода из строя одного шпинделя.

Это сильно логику усложняет, особенно, в случае работы с деградированным массивом. Рациональное зерно тут есть, в общем-то, но хотелось бы точно узнать о том, кто такое реализовал. EvgGad_303 вот утверждает, что этот алгоритм у кого-то описан.

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

Это сильно логику усложняет

Либо криворукие программисты BIOS писали

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

Меня ты радуешь сегодня

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

LOL. А куда деньги-то переводить? На какой счет?

Деньги переводить в счёт оплаты купленного RHEL/SLES/SLED/любого другого дистрибутива с техподдержкой и btrfs.

Баг - это то, что внезапно обнаружили, и знают, как исправить :)

Как можно видеть, далеко не всегда.

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

с техподдержкой
и btrfs

Никто этот адский трэш не поддерживает, btrfs поставляется as is и никто не даёт гарантий явных или подразумеваемых.

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

Меня ты радуешь сегодня

Ну радуйся, радуйся. Может, ты описание работы покажешь, где пишут про раздельную работу с чанками ?

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

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

Кончай юлить уже. Противно, мля!

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

до тебя наконец-то начинает доходить как работает raid

Я это уже слышал. Повторяю свой вопрос: " Может, ты описание работы покажешь, где пишут про раздельную работу с чанками ?".

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

Кончай юлить уже. Противно, мля!

Вас два анонимуса, один, или три ? Мне у каждого надо один и тот же вопрос спросить ? :-)

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

Либо криворукие программисты BIOS писали

В не кривом BIOS все просто идеально работает с отдельными чанками. Не покупай всякое говно!

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

ресилверинг который?

можно и так сказать.

как определяется критерий «диск умер»?

Смарт ставит диск в состояние failure, raid его выбрасывает.

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

Деньги переводить в счёт оплаты купленного RHEL/SLES/SLED/любого другого дистрибутива с техподдержкой и btrfs.

Надеюсь, у тебя ещё будет стимул это сделать. Поделишься потом опытом :)

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

Смарт ставит диск в состояние failure, raid его выбрасывает.

т.е. zfs сам смотрит в смарт, верно?
а ситуации типа возрастающего кол-ва CKSUM, я так понимаю, надо отслеживать самому?

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

Не надейся. Я умею писать код руками.

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

т.е. zfs сам смотрит в смарт, верно?

Не смотрит он в смарт, raid zfs, как и любой другой raid, в случае отказа диска просто перестает его видеть и падает в degraded.
Вот здесь обсуждали давеча:
mdadm [я просто оставлю это здесь] (комментарий)

а ситуации типа возрастающего кол-ва CKSUM, я так понимаю, надо отслеживать самому?

Не надо самому отслеживать, hdd пригодный для массивов, сделает всё сам. Десктопные hdd без поддержки SСT в массив совать не надо.

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

у raid запросили данные находящиеся в блоках (a1,b2,c3,d4)
вопрос тебе повторю: нахера ему считывать кластер a1-4, затем b1-4 и т.д., если он может параллельно считать только то что нужно?

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

Вот здесь обсуждали давеча

спасибо за инфу, пригодится

Десктопные hdd без поддержки SСT в массив совать не надо.

да я и не совал...

# smartctl -a /dev/ada0 | grep SCT
SCT capabilities: 	       (0x303f)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

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

Даже если десктопные засунуть, то всё равно zfs выкидывает его из массива с предложением «выкинут, а то ошибок много, надо бы заменить. Ну или на свой страх и риск clear делайте»

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

Даже если десктопные засунуть, то всё равно zfs выкидывает его из массива

Не знал, круто, с mdadm таки фокусы не проходят.

King_Carlo ★★★★★
()
Ответ на: комментарий от intelfx
With SUSE Linux Enterprise 12, the default file system in new installations was changed from Ext3 to Btrfs for the root system partition. XFS is the default file system for the /home partition and other data partitions.

Стесняются они на btrfs данные размещать, только root system partition, где ничего интересного нет и не жалко.

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

А в чем собственно спор состоит? Ты не веришь, что есть люди, которые заплатили деньги и им этот баг на пофиксили? Или что?

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

ты (или не ты):

Никто этот адский трэш не поддерживает, btrfs поставляется as is и никто не даёт гарантий явных или подразумеваемых.

я:

4.2, в SLES/SLED 12 btrfs по умолчанию

[а SLES/SLED имеет платную техподдержку]

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

извините, началось всё с того, что я привёл ссылку на известную проблему, ибо такова была просьба топикстартера. После этого меня обозвали упырём и предложили заплатить денег. Текущее утверждение состоит в том, что если заплатить SUSE деньги с предложением пофиксить тот баг, то получишь всего лишь сообщение, что «над вашей проблемой работают». Будем продолжать?

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

Всё началось с того, что ты попытался спровоцировать флейм, приведя проблему, не соответствующую контексту исходного вопроса, и прокомментировав её в провокативной и нелогичной форме. Дальше продолжать?

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

приведя проблему, не соответствующую контексту исходного вопроса

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

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

Стесняются они на btrfs данные размещать, только root system partition, где ничего интересного нет и не жалко.

Неа, не поэтому. У них в zipper интегрирована поддержка снэпшотов для быстрого отката изменений если что-то пошло не так.

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

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

То есть, если вдруг ENOSPC, то надо откатить с надеждой, что потом будет всё нормально?

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

На клипере шкипер, у шкипера zipper

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

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

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

Мне за тебя погуглить? Если ты не понимаешь что raid5=raid0+checksum это твои проблемы.

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

ЕМНИП, перед началом установки пакетов zipper делает snapshot и если установка прошла с ошибкой откатывает фс обратно, могу ошибаться, давно читал про это, а сусю 11 только юзал, до 12 не дожил сервачок:)

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

Ну, понятно. zipper со снапшотами у них анонсирован на первой странице, а о проблемах с btrfs скромненько так упомянули, еле найти :)

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

Дело в том, что меня волнуют проблемы не с надёжностью, а с производительностью. Загнётся — не страшно, раскатаю из бэкапа и зарепорчу баг. Чай не пять девяток.

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

Правильно понимаешь за исключением одного момента - минимальная единица обмена с диском для контроллера это размер страйпа.

Кстати, почему ты страйп чанком называешь? Хотя… в этой области достаточно запутанная терминология (strip, stripe, stride)

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

Более того, даже сам чанк читать не нужно сначала, а достаточно
именно те блоки читать, где есть нужный файл.

А узнать номер блока ? Вопрос в том, как именно построен тот слой абстрации между ФС и железом, который называется RAID. То, что хочешь делать ты, предполагает что-то вроде своей ФС на этом слое. Не многоват оверхед ?

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

Вопрос в том, как именно построен тот слой абстрации между ФС и железом, который называется RAID.

В исходниках посмотреть? Прошивки для контроллеров вряд ли найдёшь, а вот ядро линукса свободно скачаешь.

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

Какой оверхед, если распрелеление блоков идет по одному алгоритму, и жестко задан размер чанка, то всегда можно вычислить где находится тот или иной блок, без каких либо таблиц соответствия, на каком диске, с каким сдвигом, даже на листочке, а диску команда подается не на чтение чанка, а на чтение кокретного блока. И ФС работает не с чанками, а работает так же с блоками. Вот в RAIDZ размер чанка динамический, там все сложней.

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

а диску команда подается не на чтение чанка, а на чтение кокретного блока

+ контроллер даёт команды дискам пачками, а у дисков есть ncq, а ещё кэш 64-128Мб, куда сам диск лупит read ahead. Поэтому рассуждения про параллельное чтение с (N-1) дисков не более чем теоретические рассуждения.

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

Идея не практична, т.к. следом может следовать команда записи соседнего блока, что вызовет цепную реакцию :)

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

Ты наверное, думаешь, что если диск X позиционирует головки на определенный сектор, читает его, то и все остальные диски в RAID-группе непременно должны выполнить то же самое? И вдобавок еще и шпиндели на всех дисках должны быть синхронизированы, ага?
Так что-ли по-твоему работает RAID?
Просто скажи, сильно ржать не будем. Уже все проржались с этого треда, просто хочется найти хоть какую-то логику в твоих сообщениях.

bigbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.