On Sat, Jul 08, 2006 at 02:40:56PM +0300, Dmitry Pryanishnikov wrote:
On Sat, 8 Jul 2006, Paul Arakelyan wrote: Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
Попытался на домашней 6.1-STABLE повторить Ваш эксперимент с переполнением свопа и swap-backed md - получается совсем другое поведение. Итак, свопа у меня 1G, готовимся к прострелу ноги:
mdmfs -s 2g md /mnt
То, на чём оно случилось 4.11-STABLE #0: Thu Jan 27 2005 mount_mfs -o noatime -b 32768 -f 4096 -i 131072 -s 131072 /dev/ad0s1b /mfs
В списке процессов никакого mount_mfs не видим; единственное, что видим - системный процесс
0 1131 0 0 -8 0 0 8 mdwait DL ?? 0:00.00 [md0]
Стреляем в ногу:
dd if=/dev/zero of=/mnt/aaa bs=1m симуляция скорее должна выглядеть так: заливаем эдак 100MB в mfs, затем запускаем что-то, что оттуда будет читать в несколько потоков (типа while() с dd if=/mnt/что-то внутри), оставляем так на пару часиков.
Потом создаём кучу процессов, сжирающую память - например while() do dd if=/dev/ad0 of=/dev/null bs=16384000 & done
С другой консоли запускаем top, видим, как своп исчерпывается. Далее ядро по очереди убило все процессы, кроме системных. Я смог опять зайти в систему, увидел, что мой диск и файл на нем - на месте, зато в свопе забит Прикол именно в том, что то, что активно работало и жрало ресурсы - так и продолжило успешно жить и работать.
под завязку. Я издал umount /mnt, mdconfig -du0 - своп освободился. Система работает нормально, вот письмо из нее пишу. Так что, по крайней мере, RELENG_6 с данным видом форс-мажора, я считаю, справилась неплохо. Хотя MFS по идее по-разному реализован в 6.0 и в 4.х, в своё время 5.х вешались при записи в mfs (типа распаковать ports collection - и довольно быстро в процессе всё вешалось). Возможно именно эта разница и спасла. А может - "просто повезло".
конечно, если бы на ней крутилась та же zebra, она бы ее прибила (как прибила syslogd и named). Механизм "неубиваемых" процессов был бы очень полезен, не спорю.
Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message