В чем разница между btrfs raid1 и btrfs -m dup -d dup на одном устройстве

Question 1

Я бы предложил использовать вариант с dupвместо того, чтобы помещать несколько разделов на одно устройство и делать из них рейд. Вариант рейда плох, потому что рейд запрашивает чтение обеих копий во время доступа к данным (это хорошо для обычного рейда с несколькими устройствами, потому что если какое-либо устройство быстрее, данные становятся доступны раньше). С одним вращающимся устройством это приводит к тому, что считывающая головка пропускает разные разделы, поэтому если у вас в очереди несколько запросов (обычный случай), вы получаете действительно плохую производительность. Увеличение глубины очереди и планировщика CFQ может немного снизить общую задержку, но лучше избегать этого беспорядка.

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

Я не уверен в dupреализации, но я бы предположил, что это dupне отдаляет устройство копирования 1/2 от первой копии, поэтому, dupвероятно, также увеличивает производительность записи. С рейдом из одного устройства производительность записи также будет плохой, потому что одна логическая операция записи должна быть записана в двух местах на физическом вращающемся устройстве, и разница всегда составляет 1/2 устройства, поэтому вы в конечном итоге получаете алгоритм, который практически реализует общее поведение наихудшего случая для вращающегося устройства.

Answer

Я бы предложил использовать вариант с dupвместо того, чтобы помещать несколько разделов на одно устройство и делать из них рейд. Вариант рейда плох, потому что рейд запрашивает чтение обеих копий во время доступа к данным (это хорошо для обычного рейда с несколькими устройствами, потому что если какое-либо устройство быстрее, данные становятся доступны раньше). С одним вращающимся устройством это приводит к тому, что считывающая головка пропускает разные разделы, поэтому если у вас в очереди несколько запросов (обычный случай), вы получаете действительно плохую производительность. Увеличение глубины очереди и планировщика CFQ может немного снизить общую задержку, но лучше избегать этого беспорядка.

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

Я не уверен в dupреализации, но я бы предположил, что это dupне отдаляет устройство копирования 1/2 от первой копии, поэтому, dupвероятно, также увеличивает производительность записи. С рейдом из одного устройства производительность записи также будет плохой, потому что одна логическая операция записи должна быть записана в двух местах на физическом вращающемся устройстве, и разница всегда составляет 1/2 устройства, поэтому вы в конечном итоге получаете алгоритм, который практически реализует общее поведение наихудшего случая для вращающегося устройства.

Question 2

Я могу выделить одно различие между DUP и RAID1:

Если у вас (как и у меня) есть SSD-накопители, которые при простое начинают сообщать, что случайные сектора не читаются
Тогда DUP может быть PANIC, так как один из этих нечитаемых секторов в заголовке раздела BTRFS и BTRFS не может смонтировать, прочитать и т. д. что-либо хранящееся на нем. В то время как с RAID1 вы монтируете другой (если нет одного из этих нечитаемых секторов в другом заголовке раздела BTRFS) и выполняете очистку, чтобы перезаписать нечитаемые сектора.
RAID1 подразумевает два раздела, каждый со своим заголовком, поэтому, если один заголовок поврежден (переформатируйте раздел), а заголовок другого раздела правильный, вы можете смонтировать другой раздел и получить доступ в режиме пониженной производительности, а также исправить его (добавить еще один новый раздел, удалить отсутствующий, сбалансировать на уровне RAID1).

Теперь моя личная история с SSD-накопителями KingDian, которые страдают от случайных нечитаемых секторов после длительного периода времени (более восьми дней) без питания; и как BTRFS RAID1 может спасти и позволить использовать такие SSD (до возникновения коллизии из-за нечитаемых секторов).

Во-первых, я хочу поблагодарить BTRFS и его DUP (я протестирую его в ближайшем будущем) и RAID1 (уже протестирован с идеальными результатами); он позволил мне использовать мои SSD от бренда KingDian. Для брендов Yucun и Samsung я пока не вижу проблемы «нечитаемых секторов», которая появляется у всех трех SSD от бренда KingDian. У меня в использовании всего 11 SSD, один KingDian умер, так что сейчас я использую только 10) и один SSD KingDian 1TiB, который я боюсь начинать использовать (я планировал использовать его в FAT32 или NTFS для воспроизведения на ТВ, мои легально купленные DVD конвертированы в H.264/2xAAC).

Проблема с SSD-накопителями KingDian действительно странная, поэтому я расскажу, что я делаю шаг за шагом, чтобы увидеть проблему:

Создайте раздел, занимающий всего 90% дискового пространства, и отформатируйте его. До недавнего времени я использовал Ext4 (Linux) / NTFS (системный раздел Windows). Я действительно ненавижу Windows, но вынужден использовать его.
Установить систему на этот раздел
Используйте систему каждый день --> Проблем не обнаружено
Выключите питание и оставьте его выключенным более чем на восемь дней --> Проблема возникает на устройствах KingDian SS
Чтобы увидеть проблему, я загружаюсь с Live Linux-дистрибутива (DVD / USB и т. д.), я в основном использую SystemRescueCD, но подойдет и любой другой, в котором есть "ntfsclone" / "partclone.*" / "partimage" или просто "dd".
Я делаю клон раздела, сохраняя его как файл (как сохранение системного раздела на носителе BackUp)
Проблема в том, что некоторые сектора (от нескольких до 25 или 30) не читаются.
Я записываю (на бумаге), какие сектора не читаются.
Теперь начинается странная вещь: я правильно выключаю питание и оставляю его выключенным еще на восемь или более дней.
Я повторяю шаги с 4 по 7, чтобы увидеть, какие сектора теперь не читаются. Список сильно меняется, в большинстве случаев в обоих списках нет ничего общего, поэтому все не читающиеся сектора стали читаемыми, а другие, которые теперь читаются, не читаются.
Я могу повторять это много раз (без какой-либо записи на SSD) и все списки нечитаемых секторов, как правило, не содержат общих секторов (иногда один из них находится в двух списках).

Почему эти SSD (только с брендом KingDian) делают такую уродливую и странную вещь? Случайно говорят, что некоторые сектора не читаются после длительного периода (более восьми дней) без питания, а после еще одного периода (более восьми дней) без питания они снова стали читаемыми.

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

Более того, я просматриваю данные SMART, и они говорят, что новых перераспределенных секторов нет (они есть, потому что я когда-то использовал в Windows инструмент для принудительного перераспределения нечитаемых секторов).

Информация SMART также показывает, что ошибок чтения нет, хотя некоторые сектора не читаются, а также показывает, что ошибок записи нет.

Очевидно, что нет никакой ошибки «чтения», ничего «чтения» с «неправильными» данными... это технически отличается от невозможности чтения... и в данных SMART нет поля, которое я мог бы видеть, показывающего количество нечитаемых ошибок... и т. д.

Кстати, если я перезапишу нечитаемые сектора данными, они снова станут читаемыми без перераспределения каких-либо секторов, возможно, потому, что используемые внутренние сектора не являются неисправными (помните, что SSD при записи использует разные места для продления срока службы, SSD использует внутреннюю карту LBA — реальное положение внутри чипов).

Кстати, клонирование раздела с 30 ГБ данных на нем и без этой проблемы заняло меньше минуты (SSD может считывать данные со скоростью 550 МБ/с, поддерживаемой во время клонирования раздела, то есть в основном последовательное чтение); но с 25 нечитаемыми секторами это заняло более 24 часов (если игнорировать такие ошибки, иначе процесс не завершится), и некоторые данные будут «поврежденными» (те, которые не удалось прочитать).

Вот тут-то BTRFS и спас меня:

Во-первых, я использовал два раздела на одном SSD на уровне RAID1 BTRFS для ДАННЫХ и МЕТАДАННЫХ.
Теперь я знаю о DUP вместо RAID1, я буду тестировать с DUP; и это позволит мне избежать запуска двух клонированных разделов резервного копирования каждый раз, а только одного; это было бы здорово (если бы это работало)

Как это стало для меня спасением? Просто: перед тем, как сделать клон на носитель BackUP, я запускаю очистку того, что я хочу клонировать, так что нечитаемые сектора заставят BTRFS перезаписать их другой копией (надеясь, что в обоих копиях в одно и то же время и в одном и том же месте нет нечитаемых секторов).

С двумя разделами все работало нормально (медленно, но работало) и не теряло некоторые сектора клонированных данных; теперь мне нужно протестировать DUP на одном разделе вместо RAID1 на двух разделах одинакового размера.

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

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

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

Отличный BTRFS!!! Теперь подумайте о другой уродливой части (для меня), как сделать что-то подобное для раздела NTFS (системный раздел Windows)? Никак нет, у NTFS нет такой возможности (вспомните версии Windows HOME, а не SERVERS и т. д.).

Так что спасибо BTRFS, Linux намного лучше, чем я думал несколько дней назад... Я являюсь пользователем Linux уже несколько десятилетий... но отказывался пробовать BTRFS из-за всей этой ПЛОХОЙ информации о полном повреждении и т. п.; пока я не столкнулся с проблемой SSD и не понадобилось что-то с избыточностью.

Другой вариант, о котором я думал, был ZFS, гораздо более сложный, не интегрированный в загрузчик GRUB2, не интегрированный в ядро (и, возможно, никогда не будет интегрирован из-за системы лицензирования) и т. д.; поэтому я недавно попробовал (вчера) BTRFS... и какой сюрприз, он кажется действительно стабильным, относительно простым в использовании (предупреждение при добавлении нового диска, он добавляет его в RAID0, а не RAID1, я не использую RAID5/6 и т. д. и не хочу их использовать), легко восстанавливается после катастрофических повреждений (переформатировать один из двух разделов) без потери данных (на SSD не KingDian) и т. д.

Конечно, я не использую подтома, моментальные снимки и т. д., а только как простую файловую систему для корневого раздела Linux "/" в RAID1; как я уже сказал, я должен протестировать DUP вместо RAID1, но боюсь (я большой параноик), что мне придется остаться с ДВУМЯ разделами на одном SSD в RAID1, поскольку нечитаемый сектор в заголовке раздела будет означать, что все BTRFS не подлежат восстановлению/чтению.

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

Answer

Я могу выделить одно различие между DUP и RAID1:

Если у вас (как и у меня) есть SSD-накопители, которые при простое начинают сообщать, что случайные сектора не читаются
Тогда DUP может быть PANIC, так как один из этих нечитаемых секторов в заголовке раздела BTRFS и BTRFS не может смонтировать, прочитать и т. д. что-либо хранящееся на нем. В то время как с RAID1 вы монтируете другой (если нет одного из этих нечитаемых секторов в другом заголовке раздела BTRFS) и выполняете очистку, чтобы перезаписать нечитаемые сектора.
RAID1 подразумевает два раздела, каждый со своим заголовком, поэтому, если один заголовок поврежден (переформатируйте раздел), а заголовок другого раздела правильный, вы можете смонтировать другой раздел и получить доступ в режиме пониженной производительности, а также исправить его (добавить еще один новый раздел, удалить отсутствующий, сбалансировать на уровне RAID1).

Теперь моя личная история с SSD-накопителями KingDian, которые страдают от случайных нечитаемых секторов после длительного периода времени (более восьми дней) без питания; и как BTRFS RAID1 может спасти и позволить использовать такие SSD (до возникновения коллизии из-за нечитаемых секторов).

Во-первых, я хочу поблагодарить BTRFS и его DUP (я протестирую его в ближайшем будущем) и RAID1 (уже протестирован с идеальными результатами); он позволил мне использовать мои SSD от бренда KingDian. Для брендов Yucun и Samsung я пока не вижу проблемы «нечитаемых секторов», которая появляется у всех трех SSD от бренда KingDian. У меня в использовании всего 11 SSD, один KingDian умер, так что сейчас я использую только 10) и один SSD KingDian 1TiB, который я боюсь начинать использовать (я планировал использовать его в FAT32 или NTFS для воспроизведения на ТВ, мои легально купленные DVD конвертированы в H.264/2xAAC).

Проблема с SSD-накопителями KingDian действительно странная, поэтому я расскажу, что я делаю шаг за шагом, чтобы увидеть проблему:

Создайте раздел, занимающий всего 90% дискового пространства, и отформатируйте его. До недавнего времени я использовал Ext4 (Linux) / NTFS (системный раздел Windows). Я действительно ненавижу Windows, но вынужден использовать его.
Установить систему на этот раздел
Используйте систему каждый день --> Проблем не обнаружено
Выключите питание и оставьте его выключенным более чем на восемь дней --> Проблема возникает на устройствах KingDian SS
Чтобы увидеть проблему, я загружаюсь с Live Linux-дистрибутива (DVD / USB и т. д.), я в основном использую SystemRescueCD, но подойдет и любой другой, в котором есть "ntfsclone" / "partclone.*" / "partimage" или просто "dd".
Я делаю клон раздела, сохраняя его как файл (как сохранение системного раздела на носителе BackUp)
Проблема в том, что некоторые сектора (от нескольких до 25 или 30) не читаются.
Я записываю (на бумаге), какие сектора не читаются.
Теперь начинается странная вещь: я правильно выключаю питание и оставляю его выключенным еще на восемь или более дней.
Я повторяю шаги с 4 по 7, чтобы увидеть, какие сектора теперь не читаются. Список сильно меняется, в большинстве случаев в обоих списках нет ничего общего, поэтому все не читающиеся сектора стали читаемыми, а другие, которые теперь читаются, не читаются.
Я могу повторять это много раз (без какой-либо записи на SSD) и все списки нечитаемых секторов, как правило, не содержат общих секторов (иногда один из них находится в двух списках).

Почему эти SSD (только с брендом KingDian) делают такую уродливую и странную вещь? Случайно говорят, что некоторые сектора не читаются после длительного периода (более восьми дней) без питания, а после еще одного периода (более восьми дней) без питания они снова стали читаемыми.

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

Более того, я просматриваю данные SMART, и они говорят, что новых перераспределенных секторов нет (они есть, потому что я когда-то использовал в Windows инструмент для принудительного перераспределения нечитаемых секторов).

Информация SMART также показывает, что ошибок чтения нет, хотя некоторые сектора не читаются, а также показывает, что ошибок записи нет.

Очевидно, что нет никакой ошибки «чтения», ничего «чтения» с «неправильными» данными... это технически отличается от невозможности чтения... и в данных SMART нет поля, которое я мог бы видеть, показывающего количество нечитаемых ошибок... и т. д.

Кстати, если я перезапишу нечитаемые сектора данными, они снова станут читаемыми без перераспределения каких-либо секторов, возможно, потому, что используемые внутренние сектора не являются неисправными (помните, что SSD при записи использует разные места для продления срока службы, SSD использует внутреннюю карту LBA — реальное положение внутри чипов).

Кстати, клонирование раздела с 30 ГБ данных на нем и без этой проблемы заняло меньше минуты (SSD может считывать данные со скоростью 550 МБ/с, поддерживаемой во время клонирования раздела, то есть в основном последовательное чтение); но с 25 нечитаемыми секторами это заняло более 24 часов (если игнорировать такие ошибки, иначе процесс не завершится), и некоторые данные будут «поврежденными» (те, которые не удалось прочитать).

Вот тут-то BTRFS и спас меня:

Во-первых, я использовал два раздела на одном SSD на уровне RAID1 BTRFS для ДАННЫХ и МЕТАДАННЫХ.
Теперь я знаю о DUP вместо RAID1, я буду тестировать с DUP; и это позволит мне избежать запуска двух клонированных разделов резервного копирования каждый раз, а только одного; это было бы здорово (если бы это работало)