https://www.opennet.ru/openforum/vsluhforumID1/95196.html Доброго времени суток ! <br><br>Проблема заключается в в произвольной перезагрузке OC <br><br>FreeBSD 9.1-Release arch amd64<br><br>+panic: bad pte<br>+cpuid = 0<br>+KDB: stack backtrace:<br>+#0 0xffffffff808c80f6 at kdb_backtrace+0x66<br>+#1 0xffffffff8089201e at panic+0x1ce<br>+#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8<br>+#3 0xffffffff80b37257 at vmspace_exit+0x157<br>+#4 0xffffffff8085d599 at exit1+0x379<br>+#5 0xffffffff8085e46e at sys_sys_exit+0xe<br>+#6 0xffffffff80bc57f6 at amd64_syscall+0x546<br>+#7 0xffffffff80bb1157 at Xfast_syscall+0xf7<br>+Uptime: 8d6h24m54s<br><br>P.S. Тест RAM производился , ошибок не обнаружено <br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#9 Sun, 01 Dec 2013 13:04:03 GMT &gt; Еще небольшой вопрос :) <br>&gt; Чем плох SU на root? особенно если предполагается один раздел, как в <br>&gt; PCBSD.<br><br>SU хорош и может быть использован и для корня и под один корневой раздел,<br>по скромным прикидкам, лет за 10 его вылизали, теперь будут вылизывать SUJ :)<br>если вовсе не забросят при наличии ZFS ;-)<br><br>Тут в другом дело, последнее время очень популлярно использовать один большой<br>корневой раздел под все, разумеется грамотно настроив логи, использование /tmp<br>и /var/tmp, переменные TMP/TMPDIR и тд и тп.<br> Вопрос в другом, если раздел большой, больше 200GB, ФС без журнала будет проверяться<br>и подниматься долго.<br>Как говорят "время - деньги"<br><br><br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#8 Sun, 01 Dec 2013 11:24:59 GMT Еще небольшой вопрос :)<br>Чем плох SU на root? особенно если предполагается один раздел, как в PCBSD.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#7 Sun, 01 Dec 2013 11:22:01 GMT ясно, спасибо, значит буду выключать, точнее изначально создавать без него.<br><br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#6 Sun, 01 Dec 2013 10:58:33 GMT &gt; Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС. <br>&gt; Получается что уже достаточно надежно?<br><br>инсталлер - не показатель, SUJ by default был и в 9.0 и в 9.1 и самое печальное<br>что для "корня".<br><br>- dump/restore, snapshot<br>- бросок питания - требует fsck -fy<br>- gmirror - fsck -fy<br><br>мне этого хватило, какое ж это журналирование, если init вызывает fsck -y<br>тот сообщает что все Ok и потом паника в multiuser и исправляется только<br>принудительной полной проверкой.<br><br>Я случайно обнаружил когда попросили сделать продакшн с gmirror на 9.0 с jail'ами.<br>Стал демонстрировать креш, вытаскивая диски из зеркала и пропадание питания -<br>и выпал в осадок вместе с зазазчиком (нужно было до сдачи проверить с UFS и UFS+SU<br>то такого не было, понадеялся...).<br> Все было замечательно (после пропадания питания), fsck -y отрабатывал<br>моментально как и должно быть с журналом, а чуть позже - паника.<br> В списках рассылки ничего не было, разбор паники показал проблемы с SUJ,<br>добавил -f - все за https://www.opennet.ru/openforum/vsluhforumID1/95196.html#5 Sun, 01 Dec 2013 07:43:50 GMT Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС. Получается что уже достаточно надежно?<br><br><br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#4 Sun, 01 Dec 2013 07:39:00 GMT &gt; - разрушены данные на zfs (кстати после перевода на UFS в верхнем <br>&gt; обсуждении - <br>&gt; проблема решилась и для ZFS там тоже были патчи) <br><br>Вопрос не совсем по теме, помнится в каком-то топике вы настоятельно не советовали использовать UFS с SU и J одновременно. <br>Если я не собираются использовать dump/restore (проблемы вроде с этим остались), то можно? Как можно добиться проявления проблем?<br>Дело в том что собираюсь использовать UFS SU+J на сравнительно старых машинках, куда будет установлена x86 версия FreeBSD. На данный момент никаких проблем так и не увидел под VirtualBox. Виртуальная машина была несколько дней нагружена - тут и закачка/обновление портов с исходниками (ZFS тут падала, какие бы я параметры не прикручивал, на amd64 - все ок), сборка из исходников всех необходимых портов, включая тяжелые вроде KDE4, openoffice и libreoffice. <br>И никаких проблем.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#3 Thu, 21 Nov 2013 07:18:21 GMT &gt;[оверквотинг удален]<br>&gt; +#0 0xffffffff808c80f6 at kdb_backtrace+0x66 <br>&gt; +#1 0xffffffff8089201e at panic+0x1ce <br>&gt; +#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8 <br>&gt; +#3 0xffffffff80b37257 at vmspace_exit+0x157 <br>&gt; +#4 0xffffffff8085d599 at exit1+0x379 <br>&gt; +#5 0xffffffff8085e46e at sys_sys_exit+0xe <br>&gt; +#6 0xffffffff80bc57f6 at amd64_syscall+0x546 <br>&gt; +#7 0xffffffff80bb1157 at Xfast_syscall+0xf7 <br>&gt; +Uptime: 8d6h24m54s <br>&gt; P.S. Тест RAM производился , ошибок не обнаружено <br><br>попробуйте почитать:<br><br>http://lists.freebsd.org/pipermail/freebsd-bugs/2013-March/052007.html<br><br>глобально там два предположения:<br>- ошибки памяти (pmap.c) которые, кроме soft'овых могут быть связаны с ошибками железа<br>- разрушены данные на zfs (кстати после перевода на UFS в верхнем обсуждении -<br>проблема решилась и для ZFS там тоже были патчи)<br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#2 Thu, 21 Nov 2013 03:51:58 GMT &gt;&gt; +Uptime: 8d6h24m54s <br>&gt; То есть 8 суток работал, а потом в панику! 0&#124;0 <br>&gt;&gt; P.S. Тест RAM производился , ошибок не обнаружено <br>&gt; Есть настойчивые подозрения, что он у Вас тупо перегрелся.<br><br>смотреть железо: память/перегрев/винты<br> https://www.opennet.ru/openforum/vsluhforumID1/95196.html#1 Thu, 21 Nov 2013 02:01:05 GMT &gt; +Uptime: 8d6h24m54s <br><br>То есть 8 суток работал, а потом в панику! 0&#124;0<br>&gt; P.S. Тест RAM производился , ошибок не обнаружено <br><br>Есть настойчивые подозрения, что он у Вас тупо перегрелся.<br><br>