Перезагрузил Ubuntu, Raid6 деградировал, Raid5 в порядке
Загрузочный диск - это твердотельный накопитель WD емкостью 1 ТБ под управлением Ubuntu 18.04 LTS ...
У меня есть 2 массива, работающих с 1 карты LSI ... 16 x 8 ТБ IronWolf внутри RaidMachine (Raid 6) [мои основные данные] 11 x 10 ТБ Exos внутри SuperMicro (Raid 5) [резервные копии]
Все было хорошо, и уже несколько месяцев. Сделал небольшое обновление BIOS (Asus MB, работающий под управлением Ryzen 1700 с отключенным OPCACHE, был надежным). Перезагрузился, Raid6 UUID отсутствовал. Итак, я закомментировал запись в FSTAB для raid6, которая требуется для загрузки, и вошел в свою систему. Странные вещи показывают Raid6. Может у кого есть идеи, что случилось? И если да, то как можно исправить? У меня 60 ТБ данных, около 50 ТБ было скопировано в массив raid5, который работает нормально.
Моя статистика следующая ... (отредактировано для ясности)
Проверка рейда дает мне следующее ... и, как вы заметите ... там написано raid0, а не raid6 ...
/dev/md126:
Version : 1.2
Raid Level : raid0
Total Devices : 1
Persistence : Superblock is persistent
State : inactive
Working Devices : 1
Name : tbserver:0 (local to host tbserver)
UUID : 3d6402fe:8204e7c2:48b87456:8dc2cc39
Events : 650489
Number Major Minor RaidDevice
- 8 32 - /dev/sdc
Когда я запрашиваю единственный рабочий диск ... я получаю следующее ...
Personalities : [linear] [multipath] [raid6] [raid5] [raid10]
md126 : inactive sdc[16](S)
7813894488 blocks super 1.2
unused devices: <none>
Здесь должно быть 16 приводов. Странно. Если я захожу в ДИСКИ, я вижу все 16 дисков, НО вот что странно ...
15 дисков показывают это ... 
и 1 рабочий диск показывает это ...
Фон ... оба массива были созданы с помощью mdadm. Я НЕ использовал БАССЕЙН или LVM. Все диски одинакового размера и типа для каждого рейда.
Что-то, что я сразу заметил, было ... 15 недостающих дисков показывают раздел Microsoft. Как? На этой машине работает баребонная установка Ubuntu.
Мой FSTAB
#raid6 2019-10-24
UUID=6db81514-82d6-4e60-8185-94a56ca487fe /raid6 ext4 errors=remount-ro,acl 0 1
Раньше это работало. Странно то, что ... UUID больше НЕ существует, и когда я получаю подробную информацию о диске sdc ... единственный, который показывает ... у него другой UUID ... может быть, это UUID отдельного диска?
Я ни в коем случае не эксперт. Я могу делать довольно много вещей и имею 40-летний опыт работы на компьютере в программировании, мастеринге и т.д ... но, прежде чем я начну возиться с этим ... и, может быть, все испортил?!? !!
Кто-нибудь видел такое раньше? Я делал что-нибудь в BIOS этой машины Asus, заставляло ли BIOS писать на какие-либо диски! ??!?! И если да, то почему он не испортил массив Raid5 ?! Лучше меня то, что случилось ... вот журнал ошибок, который у меня был ...
Если изображение плохо читается ...
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/degraded': Failed to open file “/sys/devices/virtual/block/md126/md/degraded”: No such file or directory (g-file-error-quark, 4)
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/sync_action': Failed to open file “/sys/devices/virtual/block/md126/md/sync_action”: No such file or directory (g-file-error-quark, 4)
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/sync_completed': Failed to open file “/sys/devices/virtual/block/md126/md/sync_completed”: No such file or directory (g-file-error-quark, 4)
Какие-либо предложения? Кто-нибудь видел, чтобы что-то подобное происходило неожиданно? Как 15 дисков могли получить 2-й раздел. На этой машине никогда не загружалась никакая ОС Microsoft или что-либо еще.
Единственное, что я сделал после прошивки BIOS (до того, как она загрузится хотя бы один раз), - отключил OPCACHE для стабильности (старые Ryzens нуждались в этом). И я переключил CSM в режим AUTO после того, как пару раз попытался загрузиться (на случай, если он не отключен, но это было не так). Мог ли при включении CSM что-нибудь записать на диски?! ??!?
Я не думаю, что что-нибудь, что я мог бы сделать в BIOS, могло бы записать кучу данных на диск и создать новые разделы! ?? !!?
Большое спасибо за ваше время! Дэвид Перри Перри Компьютерные услуги
РЕДАКТИРОВАТЬ: я предполагаю, что массив уничтожен. Если кто-то видел это раньше, мне было бы очень интересно узнать, как это произошло, или любая информация по этому поводу будет оценена.
РЕДАКТИРОВАТЬ - обновить вопрос, заданный shodanshok .. ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ - До того, как я установил Linux, я возился с Microsoft Storage Spaces, но обнаружил, что они мусор (медленно). Я недавно установил Linux в систему и создал массивы с MDADM примерно в сентябре 2019 года, и с тех пор все работало отлично с тех пор ... так что я не знаю, что произошло ... почему появились места для хранения «внезапно», когда я не видел их целую вечность. Все диски на ДИСКАХ выглядели как sdc на картинках выше ... до сбоя рейда никогда не было разделов 1 и 2 ... так, очень странно ...
david@tbserver:~$ sudo mdadm -E /dev/sda
/dev/sda:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
david@tbserver:~$ sudo mdadm -E /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3d6402fe:8204e7c2:48b87456:8dc2cc39
Name : tbserver:0 (local to host tbserver)
Creation Time : Thu Oct 24 18:44:30 2019
Raid Level : raid6
Raid Devices : 16
Avail Dev Size : 15627788976 (7451.91 GiB 8001.43 GB)
Array Size : 109394518016 (104326.74 GiB 112019.99 GB)
Used Dev Size : 15627788288 (7451.91 GiB 8001.43 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=688 sectors
State : clean
Device UUID : bfe3008d:55deda2b:cc833698:bfac79c3
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Jun 27 11:08:53 2020
Bad Block Log : 512 entries available at offset 40 sectors
Checksum : 631761e6 - correct
Events : 650489
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAAAAAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
david@tbserver:~$ sudo mdadm -D /dev/sdc
mdadm: /dev/sdc does not appear to be an md device
И для дополнительной информации - я добавил это ...
david@tbserver:~$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 15628053168 sectors, 7.3 TiB
Model: ST8000VN0022-2EL
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 42015991-F493-11E9-A163-04D4C45783C8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 8-sector boundaries
Total free space is 655 sectors (327.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 34 32767 16.0 MiB 0C01 Microsoft reserved ...
2 32768 15628052479 7.3 TiB 4202 MyPool
ОБНОВЛЕНИЕ: 27.06.2020 - 21:05 EST - Мы думаем, что произошло какое-то повреждение, и когда Ubuntu попыталась автоматически восстановить массив, он обнаружил некоторые СТАРЫЕ данные о разделах рейда Microsoft и каким-то образом сделал их активными разделами или что-то в этом роде. Которая затопила весь НАСТОЯЩИЙ рейд MDADM. Странно ... почему 15 дисков из 16? Кроме того, зачем ему делать это «самостоятельно», не спрашивая подтверждения! ??!
Мы не протираем эти диски прямо сейчас. Заберу свою резервную копию от 12 июня 2020 года - я потерял около 10 ТБ данных. Я использую R-Studio для восстановления удаленных данных с другой машины, чтобы уменьшить влияние потерянных 10 ТБ. С этого момента я буду делать резервные копии до любых обновлений программного обеспечения Ubuntu или любых обновлений BIOS в будущем. И хотя мы не протирали диски, когда я впервые покупал их, чтобы проверить на наличие битых секторов и «прикоснуться» ко всей поверхности, я не протер их при установке Linux в свежем виде после тестирования и возни с Microsoft Spaces, у которых было приличное READ производительность, но было ужасно писать. Кроме того, я подумал, что MDADM более надежен ... У меня такое чувство, что это просто случайность, и теперь, когда я обнуляю эти диски, этого, вероятно, никогда не повторится. Как еще этот раздел мог "просто появиться" после 9 месяцев безупречной работы с Linux?!?!? Это должно было быть какое-то программное обеспечение для восстановления в Linux, встроенное для восстановления массива, и оно приняло неправильное решение, потому что оно увидело некоторые СТАРЫЕ структуры на диске и было сбито с толку ...
Это не займет много времени ... он пишет со скоростью 3,5 ГБ / с - примерно 207 МБ на диск.
Если бы кто-нибудь мог пролить свет на это, мне бы очень хотелось услышать, случилось ли то, что со мной произошло, с кем-нибудь еще и верна ли моя теория о том, что произошло.
Я думаю, что в будущем, в качестве урока для всех, если вы играете с другими рейдами или разделами, убедитесь, что не стираете СТАРЫЕ данные рейда с дисков ... это единственное объяснение, которое я могу придумать для того, что произошло ... У меня такое чувство, что это даже не было бы проблемой, если бы Linux не обнаружил, что старые разделы хранилища Microsoft разделят данные на диске. Честно говоря, я шокирован, что он все еще был там ... Я предполагаю, что это из-за очевидной вещи, что MDADM не стирает все, что было помещено туда ранее. Моя вина за то, что я выбрал ярлык и не протер диски нуля. В будущем я всегда буду обнулять весь массив перед повторным созданием любых новых массивов.
ОБНОВЛЕНИЕ: 2020-07-05... Мы почти уверены, что выяснили, ПОЧЕМУ возникла первоначальная проблема (в любом случае, первоначальное повреждение НЕ аварийное восстановление). После обновления биоса, да я знаю, все сбросилось. Я отключил OPCACHE, как и ожидалось, для старого процессора Ryzen 1700, работающего в Linux. Это известная ошибка. Что произошло после того, как я перестроил рейд, я мог копировать файлы в течение нескольких часов без проблем, а затем ... rsync не проявлял активности ... нет сообщений об ошибках, ничего ... Я увеличил напряжение SOC всего на БИТ ... и смогли скопировать терабайты данных за ДНЕЙ без единой проблемы. Поэтому я нахожу довольно неприятным то, что настройки по умолчанию на этой плате Asus не работают как стабильные. Я изменил следующие настройки ...
VDDCR SOC Voltage to OFFSET MODE + 0.02500
VDDCR CPU Load Line Calibration to Level 2
VDDCR SOC Load Line Calibration to Level 2
VDDCR SOC Power Phase Control to Extreme
Система снова скала. Я также разговаривал с другом, у которого на материнской плате B350 работает 3950x, и ему пришлось изменить те же настройки, чтобы он прошел Prime 95 в Linux.
Я не замечаю никакого дополнительного тепла, исходящего от системы из-за этих настроек напряжения. Я все еще использую Ryzen Wraith Prism Fan Air Cooled, что слишком много для 1700, но это красивый и тихий вентилятор. На моей памяти только Crucial DOCP на 2666Mhz на QVL.
Мое восстановление данных наконец закончилось пару дней назад, но я подумал, что все равно должен поделиться своим решением проблемы с коррупцией. Я все еще беспокоюсь о том, чтобы в будущем на дисках оставались старые данные о рейдах. Как упоминалось выше, мы обнули весь массив, поэтому я сомневаюсь, что это когда-нибудь повторится.
Престижность моему давнему другу Дагу Гейлу за то, что он помог мне снова сделать мою систему надежной. Не зная об этих регулировках напряжения, мне пришлось бы перестраивать систему, и кто знает, может быть, проблема снова всплыла бы ... Я также использую блоки питания Crucial Gold Rated на случай, если кому-то интересно ... :) с Cyperpower Двойное резервное копирование 1500 ВА.