Тупик ввода-вывода Linux после обновления ядра

Использование getconf ARG_MAXдля создания длинного списка xи вызов внешней утилиты с этим аргументом приведет к ошибке «Слишком длинный список аргументов»:

$ /bin/echo $( perl -e 'print "x" x $ARGV[0]' "$(getconf ARG_MAX)" )
/bin/sh: /bin/echo: Argument list too long

Окружающая среда и длина строки /bin/echoбудут включены в то, что вызывает ошибку, поэтому мы можем попытаться найти максимально возможное число, вычитая эти:

$ env
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin

(Я запустил эту оболочку с env -i sh, поэтому в окружении есть только переменная PATH)

$ /bin/echo $( perl -e 'print "x" x ($ARGV[0] - length($ENV{"PATH"}) - length("/bin/echo"))' "$(getconf ARG_MAX)" )
sh: /bin/echo: Argument list too long

Еще слишком долго. Насколько?

i=0
while ! /bin/echo $( perl -e 'print "x" x ($ARGV[0] - length($ENV{"PATH"}) - length("/bin/echo") - $ARGV[1])' "$(getconf ARG_MAX)" "$i" )
do
    i=$(( i + 1 ))
done

Этот цикл завершается для i=8.

Итак, есть четыре байта, которые я не могу сразу объяснить (четыре из восьми должны быть для имени переменной среды PATH). Это нулевые ограничители для четырех строк PATH, значение PATH, /bin/echoи длинная строка из xсимволов.

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


Кроме того, просто чтобы показать эффект большого окружения:

$ export BIG=$( perl -e 'print "x" x $ARGV[0]' "$( getconf ARG_MAX )" )

$ /bin/echo hello
sh: /bin/echo: Argument list too long

$ /bin/echo
sh: /bin/echo: Argument list too long
1
17.06.2020, 11:47
1 ответ

Несмотря на отсутствие ошибок SMART, факт остается фактом: ваш sdjдиск сообщает об ошибках при фактическом использовании, и, похоже, это влияет на ваш том md0p2RAID.

После сообщения

hpsa 0000:05:00.0: scsi 0:0:10:0: resetting physical  Direct-Access     ATA      TP04000GB        PHYS DRV SSDSmartPathCap- En- Exp=1

кажется, что рассматриваемый диск вообще перестал отвечать. Поскольку это ошибка обратной записи, это означает, что ядро ​​кэшировало операцию записи и «обещало» приложению пользовательского пространства, что оно будет записано на диск. Теперь, когда на самом деле запись оказалась невозможной, с RAID 0 не будет другого пути восстановления, кроме как ждать и надеяться, что диск снова начнет отвечать. Альтернативой может быть преднамеренная потеря данных, а это то, что ядро ​​просто не будет делать само по себе .

30 апреля 16 :00 :19 ядро ​​отдало диску команду сброса, чтобы попытаться восстановиться после ошибки, и диск, по-видимому, так и не выполнил эту команду.

Судя по системному журналу, я готов объявить диск мертвым. Время смерти примерно 30 апреля 16 :00 :24.

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

0
18.03.2021, 23:26

Теги

Похожие вопросы