nr_hugepages
все еще существует, потому что он дополняет другие ценности, которые вы упомянули. В документации ядра есть все подробности, но в основном /proc/sys/vm/nr_hugepages
показывает количество постоянных огромных страниц размера по умолчанию в пуле огромных страниц ядра (, размер которого показан HugePages_Total
в /proc/meminfo
). nr_hugepages
— это параметр, контролируемый администратором -, определяемый при загрузке с использованием параметра ядра hugepages
и/или во время выполнения путем записи в nr_hugepages
(, если система способна предоставить запрошенное количество огромных страниц ).
Цель nr_hugepages
— сделать огромные страницы доступными для программ пользовательского пространства , черезhugetlbfs
или разделяемую память или mmap
. Количество страниц, выделенных через nr_hugepages
, составляет пул огромных страниц, зарезервированных для этого использования; если позволяют ресурсы системы, могут быть доступны более огромные страницы (до предела, установленного nr_overcommit_hugepages
), но это не гарантируется. Он доступен на всех платформах, поддерживающих огромные страницы. Эти страницы полезны для программ, которые выделяют большие объемы памяти, но они вводят ограничения — в частности, их нельзя выгрузить.
Как упоминалось в , что означает поля HardwareCorrupted, DirectMap4k, DirectMap2M в файле «/proc/meminfo» в Linux? , DirectMap
— детали реализации, специфичные для архитектуры x86 -. Он измеряет использование карт страниц для страниц различных размеров ядром ; это показывает, насколько ядро способно отображать страницы как огромные страницы различных размеров. Это не ограниченоnr_hugepages
:даже в системе без огромных страниц в огромном пуле страниц (для пользовательского пространства ), ядро попытается объединить сопоставления страниц, чтобы уменьшить нагрузку на TLB (, см. try_preserve_large_page
в pageattr.c
).
Трудно ответить на ваш вопрос, и он слишком длинный для комментария, так что просто несколько общих советов.
So now I'm panicking, thinking that the drive 2 was actually still good and now when I readded it, it's resynching, probably destroying the good data it has.
Если нет ошибки ядра, -добавление диска(в той же роли и с тем же смещением, что и до ), не «уничтожает» данные. Он просто повторно -записывает большую часть тех же данных, что уже были, без вреда.
sdx
, когда оно было sdx1
до Основная проблема с выкинутым диском, даже если диск был невиновен, заключается в том, что он больше не является частью массива. Как только массив монтируется в режиме записи, данные на массиве модифицируются, а данные на выкинутом диске не обновляются вместе с ним, поэтому он устаревает и как таковой перестает быть «хорошим».
I checked the drive's health with the disks tool (I think it's from gnome, gnome-disk-tool or something), and it had almost 6000 bad sectors, but apart from that it said it was OK.
Вы не сможете восстановить данные, если у вас проблемы с дисками. Если эти 6000 сбойных секторов не появились за ночь, вы давно должны были заменить этот диск. RAID-массивы умирают, если вы не проводите самопроверку, не отслеживаете и не заменяете как можно скорее любые неисправные диски.
Получите новые диски, используйте ddrescue
, чтобы скопировать все, что можно, со старых дисков, затем используйте копирование -на -напишите оверлеи для экспериментов по восстановлению данных . С оверлеями вы можете писать без изменения оригинала (, поэтому вам не нужно повторно -делать копию на диск и не нужна копия копии, а также ). Но для оверлеев тоже нужны работающие диски, с дисками с ошибками этого не сделаешь.
Это чудо. Каким-то образом я восстановил работоспособность массива. Вот что я сделал:
Я подключил все три диска и перезапустил (снова с живым -сеансом USB ). Оглядываясь назад, можно сказать, что manjaro не был лучшим выбором для среды восстановления, поскольку в нем уже был установлен mdadm, и в результате он уже пытался запустить массив (как /dev/md127 ). Я обнаружил это при попытке вручную запустить массив.
mdadm --assemble --scan
Когда я это сделал, он пожаловался, что уже есть активный массив (или что-то в этом роде ). Я вспомнил, что /dev/md127 иногда запускается автоматически, поэтому я остановил этот массив и попытался вручную запустить свой.
mdadm --stop /dev/md127
mdadm --assemble --scan
Это тоже не сработало. Затем я попытался указать разделы на каждом диске для использования при сборке массива.
mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1
Это сработало! Затем я проверил состояние массива с помощью mdadm --examine /dev/md0
. Как ни странно, он сказал, что массив состоит из 3/3 дисков. Когда я проверил cat /proc/mdstat
, не было никаких указаний на то, что диск 2 массива перестраивался (, помните,изначально диск 2 был исключен из массива после отключения питания ). Произошло какое-то чудо, и диск 2, который восстанавливался в ледяном темпе, когда я выключил компьютер, должен был быть в порядке, и на этот раз mdadm каким-то образом принял его в массив.
Затем я попытался получить доступ к массиву, чтобы скопировать мои данные на новый диск, который я купил. Это не сработало. Простое перечисление содержимого каталога приводило к зависанию команды ls
. В dmesg
снова было множество ошибок ввода-вывода, конкретно относящихся к диску 3 (\dev\sdd ).
Я попытался отменить команду ls
, и мне потребовалось несколько попыток CTRL -C и несколько минут ожидания, прежде чем я снова получил командную строку. В этот момент меня попытались еще раз проверить массив с помощью mdadm --examine /dev/md0
. Затем он распознал диск 3 как аппаратный сбой и исключил его из массива. В массиве теперь только диск 1 (/dev/sdb, полностью исправный диск ), и диск 2 (/dev/sdc, диск, который изначально был выкинут из массива в самом начале всего этого ).
Я еще раз попытался получить доступ к массиву, и теперь это сработало! Я смог просмотреть все свои файлы с помощью ls
и даже с помощью файлового браузера. В этот момент я начал копировать все свои важные файлы на дополнительный диск, который я купил. Я почти закончил этот процесс.
В конце концов, это хорошее напоминание о том, что я регулярно делаю резервные копии своих файлов на отдельном устройстве. У меня была привычка это делать, но последние год или два я проявлял небрежность. Извините, если этот пост получился слишком длинным и не самым конкретным. Я не помню точных результатов каждой команды.
TL;DR Я выключил компьютер и перестал паниковать. Затем у меня было время, чтобы составить план подхода к проблеме. Это хорошее напоминание о том, что необходимо поддерживать резервные копии дат -–-.