В этом примере массив называется md0
и он установлен в / raid1
.
Проверить псевдоним массива:
Предположим, что в массиве находится файл подкачки, нам нужно сначала отключить его. Если это единственная область подкачки в системе, мы можем сделать следующее:
sudo swapoff --all
Массив должен быть размонтирован для правильной проверки:
sudo umount / raid1
После этой подготовки мы можем вызвать скрипт checkarray
, я выбрал быстрый приоритет, но вы можете выбрать любой вариант приоритета:
sudo / usr / share / mdadm / checkarray --fast / dev / md0
Если вы хотите следить за ходом проверки массива каждую секунду:
watch -n 1 cat / proc / mdstat {{1} }
Таким образом, полный bash
проверочный массив псевдоним
расположен, например, в вашем личном файле .bash_aliases
будет выглядеть примерно так:
alias checkarray='sudo swapoff --all && \
sudo umount /raid1 && \
sudo /usr/share/mdadm/checkarray --fast /dev/md0 && \
watch -n 1 cat /proc/mdstat'
Убедитесь, что вы закрыли все открытые файлы в массиве перед его вызовом.
Псевдоним массива After-Check:
Думаю, никаких дополнительных комментариев не требуется:
alias checkarray-after='sudo mount /dev/md0 /raid1 && \
sudo swapon --all'
Возможное объяснение состоит в том, что на сервере есть разрешения, которые NFS не может выразить. Разрешения, передаваемые по сети, не определяют, разрешен ли доступ: решение принимает сервер. Обычно разрешения и решения по управлению доступом основаны на одной и той же информации, и поэтому они непротиворечивы. Однако, если что-то по пути теряет некоторую информацию о разрешениях, то они могут быть несогласованными.
Некоторыми примерами разрешений, которые NFS не может выразить, являются списки управления доступом (вы используете NFSv3, который не всегда поддерживает ACL; а в NFSv4 есть ACL, но они не совсем такие, как в Linux) и безопасность Linux. фреймворки, такие как SELinux и AppArmor.
Если это проблема, то для ее диагностики без доступа к серверу потребуется много догадок. Без помощи администратора сервера вы вряд ли решите эту проблему.