Доброго времени суток !Проблема заключается в в произвольной перезагрузке OC
FreeBSD 9.1-Release arch amd64
+panic: bad pte
+cpuid = 0
+KDB: stack backtrace:
+#0 0xffffffff808c80f6 at kdb_backtrace+0x66
+#1 0xffffffff8089201e at panic+0x1ce
+#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8
+#3 0xffffffff80b37257 at vmspace_exit+0x157
+#4 0xffffffff8085d599 at exit1+0x379
+#5 0xffffffff8085e46e at sys_sys_exit+0xe
+#6 0xffffffff80bc57f6 at amd64_syscall+0x546
+#7 0xffffffff80bb1157 at Xfast_syscall+0xf7
+Uptime: 8d6h24m54sP.S. Тест RAM производился , ошибок не обнаружено
> +Uptime: 8d6h24m54sТо есть 8 суток работал, а потом в панику! 0|0
> P.S. Тест RAM производился , ошибок не обнаруженоЕсть настойчивые подозрения, что он у Вас тупо перегрелся.
>> +Uptime: 8d6h24m54s
> То есть 8 суток работал, а потом в панику! 0|0
>> P.S. Тест RAM производился , ошибок не обнаружено
> Есть настойчивые подозрения, что он у Вас тупо перегрелся.смотреть железо: память/перегрев/винты
>[оверквотинг удален]
> +#0 0xffffffff808c80f6 at kdb_backtrace+0x66
> +#1 0xffffffff8089201e at panic+0x1ce
> +#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8
> +#3 0xffffffff80b37257 at vmspace_exit+0x157
> +#4 0xffffffff8085d599 at exit1+0x379
> +#5 0xffffffff8085e46e at sys_sys_exit+0xe
> +#6 0xffffffff80bc57f6 at amd64_syscall+0x546
> +#7 0xffffffff80bb1157 at Xfast_syscall+0xf7
> +Uptime: 8d6h24m54s
> P.S. Тест RAM производился , ошибок не обнаруженопопробуйте почитать:
http://lists.freebsd.org/pipermail/freebsd-bugs/2013-March/0...
глобально там два предположения:
- ошибки памяти (pmap.c) которые, кроме soft'овых могут быть связаны с ошибками железа
- разрушены данные на zfs (кстати после перевода на UFS в верхнем обсуждении -
проблема решилась и для ZFS там тоже были патчи)
> - разрушены данные на zfs (кстати после перевода на UFS в верхнем
> обсуждении -
> проблема решилась и для ZFS там тоже были патчи)Вопрос не совсем по теме, помнится в каком-то топике вы настоятельно не советовали использовать UFS с SU и J одновременно.
Если я не собираются использовать dump/restore (проблемы вроде с этим остались), то можно? Как можно добиться проявления проблем?
Дело в том что собираюсь использовать UFS SU+J на сравнительно старых машинках, куда будет установлена x86 версия FreeBSD. На данный момент никаких проблем так и не увидел под VirtualBox. Виртуальная машина была несколько дней нагружена - тут и закачка/обновление портов с исходниками (ZFS тут падала, какие бы я параметры не прикручивал, на amd64 - все ок), сборка из исходников всех необходимых портов, включая тяжелые вроде KDE4, openoffice и libreoffice.
И никаких проблем.
Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС. Получается что уже достаточно надежно?
> Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС.
> Получается что уже достаточно надежно?инсталлер - не показатель, SUJ by default был и в 9.0 и в 9.1 и самое печальное
что для "корня".- dump/restore, snapshot
- бросок питания - требует fsck -fy
- gmirror - fsck -fyмне этого хватило, какое ж это журналирование, если init вызывает fsck -y
тот сообщает что все Ok и потом паника в multiuser и исправляется только
принудительной полной проверкой.Я случайно обнаружил когда попросили сделать продакшн с gmirror на 9.0 с jail'ами.
Стал демонстрировать креш, вытаскивая диски из зеркала и пропадание питания -
и выпал в осадок вместе с зазазчиком (нужно было до сдачи проверить с UFS и UFS+SU
то такого не было, понадеялся...).
Все было замечательно (после пропадания питания), fsck -y отрабатывал
моментально как и должно быть с журналом, а чуть позже - паника.
В списках рассылки ничего не было, разбор паники показал проблемы с SUJ,
добавил -f - все заработало, но смысл журналирования в этом случае потерян.
Send-pr отправлять было некогда, висела сдача, потом в списках рассылки появились
проблемы, хотя вру - проблема со снапшотом была еще до выхода 9.0R, именно она
навела на мысль.
Итог: корень либо UFS, либо UFS+SU, хоть и очень много было исправлений в SUJ и
в 9.1-Stable и в 9.2 у меня на ряде машин SUJ живет без проблем, в продакшене ни
на одной машине у меня нет корня с SUJ.
ясно, спасибо, значит буду выключать, точнее изначально создавать без него.
Еще небольшой вопрос :)
Чем плох SU на root? особенно если предполагается один раздел, как в PCBSD.
> Еще небольшой вопрос :)
> Чем плох SU на root? особенно если предполагается один раздел, как в
> PCBSD.SU хорош и может быть использован и для корня и под один корневой раздел,
по скромным прикидкам, лет за 10 его вылизали, теперь будут вылизывать SUJ :)
если вовсе не забросят при наличии ZFS ;-)Тут в другом дело, последнее время очень популлярно использовать один большой
корневой раздел под все, разумеется грамотно настроив логи, использование /tmp
и /var/tmp, переменные TMP/TMPDIR и тд и тп.
Вопрос в другом, если раздел большой, больше 200GB, ФС без журнала будет проверяться
и подниматься долго.
Как говорят "время - деньги"