[freebsd] перезагрузки сервера после обновления до 9
Здравствуйте. Обновил сервер с 8.2-RELEASE до 9.0-RELEASE. Сначала у меня была проблема с разделами (неправильно изначально создал, но решилось в теме ядро не содержит модуль, который был указан в конфиге за 2012-03-16). Сейчас же я обратил внимание, что сервер довольно часто перезагружается: каждые 30 - 90 минут. Раз протянул часов 5. Сначала думал питание, но оставил его висеть с неработоспособным ядром через nextboot. По питанию не перезагрузился. Перезагрузка происходит как-то очень резко. Время с момента пропадания связи до появления примерно то же, что и при shutdown -r now. Не похоже это на kernel panic, т.к. 09:36[2]hades@firefly:~config -x /boot/kernel/kernel | grep PAN options PANIC_REBOOT_WAIT_TIME=300 и так быстро он бы не перезагрузился. dumpdevice настроен, но в /var/crash/ ничего не появляется. В логах для себя ничего подозрительного не вижу. Как бы мне проверить, в чем дело? P.S. Попробовал переключиться с 9.0-RELEASE на 9.0-STABLE, но это ничего не изменило. Отличия моего конфига от GENERIC: 09:55[2]hades@firefly:/sys/amd64/confdiff GENERIC firefly | grep ^ # $FreeBSD: releng/9.0/sys/amd64/conf/GENERIC 227305 2011-11-07 13:40:54Z marius $ ident firefly maxusers 128 #device fdc deviceses # SCSI Environmental Services (and SAF-TE) #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus ## Added by Hades ### platform independent #options GEOM_MIRROR # Disk mirroring. # 18% # NETWORKING OPTIONS options IPSEC #IP security (requires device crypto) #options IPSEC_FILTERTUNNEL #filter ipsec packets from a tunnel options IPSEC_NAT_T #NAT-T support, UDP encap of ESP # libalias library, performing NAT options LIBALIAS options NETGRAPH# netgraph(4) system options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_SOCKET # IPsec interface. deviceenc options MROUTING# Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT#divert sockets options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_LOOKUP #ipfilter pools #options IPFILTER_DEFAULT_BLOCK #block all packets by default options IPSTEALTH #support for stealth forwarding options DUMMYNET # 32% # FILESYSTEM OPTIONS #options QUOTA #enable disk quotas # 95% # crypto subsystem devicecrypto # core crypto support devicecryptodev # /dev/crypto for access to h/w # 97% # SYSV IPC KERNEL PARAMETERS options PANIC_REBOOT_WAIT_TIME=300
Re: [freebsd] перезагрузки сервера после обновления до 9
26.03.2012 14:21, Alexander Koval пишет: Обновил сервер с 8.2-RELEASE до 9.0-RELEASE. Сначала у меня была проблема с разделами (неправильно изначально создал, но решилось в теме ядро не содержит модуль, который был указан в конфиге за 2012-03-16). Сейчас же я обратил внимание, что сервер довольно часто перезагружается: каждые 30 - 90 минут. Раз протянул часов 5. Сначала думал питание, но оставил его висеть с неработоспособным ядром через nextboot. По питанию не перезагрузился. Перезагрузка происходит как-то очень резко. Время с момента пропадания связи до появления примерно то же, что и при shutdown -r now. Не похоже это на kernel panic, т.к. 09:36[2]hades@firefly:~config -x /boot/kernel/kernel | grep PAN options PANIC_REBOOT_WAIT_TIME=300 и так быстро он бы не перезагрузился. dumpdevice настроен, но в /var/crash/ ничего не появляется. Паники бывают разные, иногда разносит так, что оно мгновенно ребутится, безо всяких завершающих операций. Отличия моего конфига от GENERIC: maxusers 128 Для начала я бы убрал maxusers. Ещё были сообщения о паниках в девяткином IPSEC, оно используется? Если нет - лучше убрать из ядра. Если есть, вернуться на 8.3
Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
25.03.2012 15:56, Mikolaj Golub пишет: On Sun, 25 Mar 2012 07:11:50 +0400 Владимир Друзенко wrote: ВД Тред нашёл: ВД http://lists.freebsd.org/pipermail/freebsd-stable/2011-November/064611.html ВД Но в нём обсуждается другой вопрос - просто о низкой пропускной ВД способности NFS. ВД Указанные там тюнинги увеличили скорость в 1.1-1.4 раза, но скачок при ВД размере буфера 800-900Kb так и остался: ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884983* count=256 ВД 226555648 bytes transferred in 55.568878 secs (*4077024* bytes/sec) ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884982* count=256 ВД 226555392 bytes transferred in 2.931009 secs (*77296040* bytes/sec) ВД Тюнинги на клиенте: nfs опции mount - ВД rw,intr,soft,bg,nfsv3,readahead=4,wsize=65536,rsize=65536,tcp,async. ВД Тюнинги на сервере: zfs set sync=disabled datastorage/documents/ ВД vfs.nfsrv.async/ в 9.0 нет. ВД Патч из треда и для /vfs.nfsrv.async /так же НЕ накладывал. ВД Может ещё какие мысли? Задампить трафик tcpdump-ом для двух случаев и посмотреть в wireshark в чем отличие. Спасибо за наводку. Отфильтровал оба случая по наличию nfs.write.committed: в случае нормальной скорости Committed: UNSTABLE (0), а в случае плохой Committed: FILE_SYNC (2). При копировании 8 блоков вышеуказанных размеров получается чуть более 100 таких строк в каждом случае: V3 WRITE Replay (Call xxx) Len:65536 UNSTABLE и V3 WRITE Replay (Call xxx) Len:65536 FILE_SYNC соответственно. Также в случае медленной скорости было 6 пакетов вида: [RPC duplicate of #4302][TCP Retransmission] V3 WRITE Reply (Call In 4274) Len:65536 FILE_SYNC. Теперь хотя бы понятно кто виноват. Остался вопрос что делать?. Дампы могу выслать, если нужно - оба в архиве 130Kb.
Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
On Mon, Mar 26, 2012 at 11:49:33AM +0400, Владимир Друзенко wrote: 25.03.2012 15:56, Mikolaj Golub пишет: On Sun, 25 Mar 2012 07:11:50 +0400 Владимир Друзенко wrote: ВД Тред нашёл: ВД http://lists.freebsd.org/pipermail/freebsd-stable/2011-November/064611.html ВД Но в нём обсуждается другой вопрос - просто о низкой пропускной ВД способности NFS. ВД Указанные там тюнинги увеличили скорость в 1.1-1.4 раза, но скачок при ВД размере буфера 800-900Kb так и остался: ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884983* count=256 ВД 226555648 bytes transferred in 55.568878 secs (*4077024* bytes/sec) ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884982* count=256 ВД 226555392 bytes transferred in 2.931009 secs (*77296040* bytes/sec) ВД Тюнинги на клиенте: nfs опции mount - ВД rw,intr,soft,bg,nfsv3,readahead=4,wsize=65536,rsize=65536,tcp,async. ВД Тюнинги на сервере: zfs set sync=disabled datastorage/documents/ ВД vfs.nfsrv.async/ в 9.0 нет. ВД Патч из треда и для /vfs.nfsrv.async /так же НЕ накладывал. ВД Может ещё какие мысли? Задампить трафик tcpdump-ом для двух случаев и посмотреть в wireshark в чем отличие. Спасибо за наводку. Отфильтровал оба случая по наличию nfs.write.committed: в случае нормальной скорости Committed: UNSTABLE (0), а в случае плохой Committed: FILE_SYNC (2). При копировании 8 блоков вышеуказанных размеров получается чуть более 100 таких строк в каждом случае: V3 WRITE Replay (Call xxx) Len:65536 UNSTABLE и V3 WRITE Replay (Call xxx) Len:65536 FILE_SYNC соответственно. Также в случае медленной скорости было 6 пакетов вида: [RPC duplicate of #4302][TCP Retransmission] V3 WRITE Reply (Call In 4274) Len:65536 FILE_SYNC. Теперь хотя бы понятно кто виноват. Остался вопрос что делать?. Дампы могу выслать, если нужно - оба в архиве 130Kb. добавить опцию async в параметры монтирования?
Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
26.03.2012 11:51, Slawa Olhovchenkov пишет: On Mon, Mar 26, 2012 at 11:49:33AM +0400, Владимир Друзенко wrote: 25.03.2012 15:56, Mikolaj Golub пишет: On Sun, 25 Mar 2012 07:11:50 +0400 Владимир Друзенко wrote: ВД Тред нашёл: ВД http://lists.freebsd.org/pipermail/freebsd-stable/2011-November/064611.html ВД Но в нём обсуждается другой вопрос - просто о низкой пропускной ВД способности NFS. ВД Указанные там тюнинги увеличили скорость в 1.1-1.4 раза, но скачок при ВД размере буфера 800-900Kb так и остался: ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884983* count=256 ВД 226555648 bytes transferred in 55.568878 secs (*4077024* bytes/sec) ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884982* count=256 ВД 226555392 bytes transferred in 2.931009 secs (*77296040* bytes/sec) ВД Тюнинги на клиенте: nfs опции mount - ВД rw,intr,soft,bg,nfsv3,readahead=4,wsize=65536,rsize=65536,tcp,async. ВД Тюнинги на сервере: zfs set sync=disabled datastorage/documents/ ВД vfs.nfsrv.async/ в 9.0 нет. ВД Патч из треда и для /vfs.nfsrv.async /так же НЕ накладывал. ВД Может ещё какие мысли? Задампить трафик tcpdump-ом для двух случаев и посмотреть в wireshark в чем отличие. Спасибо за наводку. Отфильтровал оба случая по наличию nfs.write.committed: в случае нормальной скорости Committed: UNSTABLE (0), а в случае плохой Committed: FILE_SYNC (2). При копировании 8 блоков вышеуказанных размеров получается чуть более 100 таких строк в каждом случае: V3 WRITE Replay (Call xxx) Len:65536 UNSTABLE и V3 WRITE Replay (Call xxx) Len:65536 FILE_SYNC соответственно. Также в случае медленной скорости было 6 пакетов вида: [RPC duplicate of #4302][TCP Retransmission] V3 WRITE Reply (Call In 4274) Len:65536 FILE_SYNC. Теперь хотя бы понятно кто виноват. Остался вопрос что делать?. Дампы могу выслать, если нужно - оба в архиве 130Kb. добавить опцию async в параметры монтирования? Спасибо Кэп, но уже есть и уже писал об этом в треде...
[freebsd] Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
Могу предложить сделать пару тестов наоборот, т.е. чтение с NFS. Также в том треде про низкую пропускную способность загрузка клиента была высокая, может ли так быть что у вас слишком мощный клиент что визуально не видно разницы в загрузке (load)? Ну и так как уже практически создана площадка с повторяемостью проблемы, то до патча с фиксом почти недалеко вам осталось :) -- Regards, Alexander Yerenkow
Re: [freebsd] Re: ipnat -l
В Mon, 26 Mar 2012 12:48:20 +0400 Slawa Olhovchenkov s...@zxy.spb.ru пишет: В теории, может быть. А на практике хороший нат должен не вносить дополнительных проблем для пользователей. Ну тогда циско иос - ваш выбор. Переплачивайте и нат вам будет красивенько натить фтп. Разницы в переплате к сожалению не хватит на хоть сколько-то приличный слой масла на хлебе: asa5505 по GPL стоит $1000. Ну это же не гигабитное решение, верно? А 150 мегабит при современных тенденциях частенько не хватает -- Close your eyes, look into the dream... Jabber ID : sap...@gmail.com E-mail : sap...@gmail.com
Re: [freebsd] Re: ipnat -l
On Mon, Mar 26, 2012 at 11:49:21AM +0300, Alex Khrenov wrote: В Mon, 26 Mar 2012 12:48:20 +0400 Slawa Olhovchenkov s...@zxy.spb.ru пишет: В теории, может быть. А на практике хороший нат должен не вносить дополнительных проблем для пользователей. Ну тогда циско иос - ваш выбор. Переплачивайте и нат вам будет красивенько натить фтп. Разницы в переплате к сожалению не хватит на хоть сколько-то приличный слой масла на хлебе: asa5505 по GPL стоит $1000. Ну это же не гигабитное решение, верно? А 150 мегабит при современных тенденциях частенько не хватает Гигабитный nat?! Покажите мне где это надо!
Re: [freebsd] Re: ipnat -l
On Mon, Mar 26, 2012 at 11:55:16AM +0300, Sayetsky Anton wrote: 26 марта 2012 г. 11:54 пользователь Slawa Olhovchenkov s...@zxy.spb.ru написал: Гигабитный nat?! Покажите мне где это надо! Инет-провайдер. пользователи убьют провайдера с таким странным natом. более того, если провайдер так не любит своих пользователей, что держит их за natом, то для исправления кармы ему стоит использовать нат с пониманием UPNP хотя бы. если чо, это не cisco, кто из серьезных такое умеет -- я не знаю.
Re: [freebsd] Re: ipnat -l
On Mon, Mar 26, 2012 at 11:54:14AM +0300, Alex Khrenov wrote: В Mon, 26 Mar 2012 12:54:41 +0400 Slawa Olhovchenkov s...@zxy.spb.ru пишет: On Mon, Mar 26, 2012 at 11:49:21AM +0300, Alex Khrenov wrote: В Mon, 26 Mar 2012 12:48:20 +0400 Slawa Olhovchenkov s...@zxy.spb.ru пишет: В теории, может быть. А на практике хороший нат должен не вносить дополнительных проблем для пользователей. Ну тогда циско иос - ваш выбор. Переплачивайте и нат вам будет красивенько натить фтп. Разницы в переплате к сожалению не хватит на хоть сколько-то приличный слой масла на хлебе: asa5505 по GPL стоит $1000. Ну это же не гигабитное решение, верно? А 150 мегабит при современных тенденциях частенько не хватает Гигабитный nat?! Покажите мне где это надо! asa5505 - это только нат? А фаервол нужен везде. фаервол нужен только винде.
Re: [freebsd] Re: ipnat -l
В Mon, 26 Mar 2012 13:01:10 +0400 Slawa Olhovchenkov s...@zxy.spb.ru пишет: Разницы в переплате к сожалению не хватит на хоть сколько-то приличный слой масла на хлебе: asa5505 по GPL стоит $1000. Ну это же не гигабитное решение, верно? А 150 мегабит при современных тенденциях частенько не хватает Гигабитный nat?! Покажите мне где это надо! asa5505 - это только нат? А фаервол нужен везде. фаервол нужен только винде. Ага, ну-ну... :-) Да и акая разница что за фаерволом, если трафа больше 150 мегабит? -- Close your eyes, look into the dream... Jabber ID : sap...@gmail.com E-mail : sap...@gmail.com
Re: [freebsd] Re: ipnat -l
26 марта 2012 г. 12:00 пользователь Slawa Olhovchenkov s...@zxy.spb.ru написал: пользователи убьют провайдера с таким странным natом. более того, если провайдер так не любит своих пользователей, что держит их за natом, то для исправления кармы ему стоит использовать нат с пониманием UPNP хотя бы. 1. Не у всех провайдеров есть адреса на всех своих клиентов. 2. Вы незнакомы с текущим механизмом получения адресов у RIPE? Бумажек там писать очень много.
Re: [freebsd] Re: ipnat -l
On Mon, Mar 26, 2012 at 12:18:54PM +0300, Sayetsky Anton wrote: 26 марта 2012 г. 12:00 пользователь Slawa Olhovchenkov s...@zxy.spb.ru написал: пользователи убьют провайдера с таким странным natом. более того, если провайдер так не любит своих пользователей, что держит их за natом, то для исправления кармы ему стоит использовать нат с пониманием UPNP хотя бы. 1. Не у всех провайдеров есть адреса на всех своих клиентов. это не отменяет того утверждения, что провайдер с натом -- плохой провайдер. это мне даже по ssh домой не зайти было бы. 2. Вы незнакомы с текущим механизмом получения адресов у RIPE? Бумажек там писать очень много. для родных органов бумажек писать еще больше.
Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
26.03.2012 12:51, Alexander Yerenkow пишет: Могу предложить сделать пару тестов наоборот, т.е. чтение с NFS. Создал файл на сервере ~4.5Gb (чтобы весь не влез в кэшь ни сервера, ни клиента). Чтение чуть более 100Mytes/s (это около предела сети GigabitEthernet) любым размером блока от 1k до 16M. Также в том треде про низкую пропускную способность загрузка клиента была высокая, может ли так быть что у вас слишком мощный клиент что визуально не видно разницы в загрузке (load)? Не очень понял о чём речь. Спеки клиента и сервера в первом посте треда: * клиент: i386 Core 2 Duo E7200@3.4GHz 4Gb DDR2 800MHz; * сервер: amd64 Xeon E5030@2.66GHz 2Gb DDR2 FB-DIMM 667MHz; Ну и так как уже практически создана площадка с повторяемостью проблемы, то до патча с фиксом почти недалеко вам осталось :) Угу. Осталось выяснить почему сервер отвечает Committed: UNSTABLE с размером блока до определённой величины, и Committed: FILE_SYNC после. Есть кто, кто разбирался с исходниками NFS сервера FreeBSD? Начал курить сырцы... Плохо, что просто так перегружать сервер не получится - только ночью. -- Regards, Alexander Yerenkow
Re: [freebsd] перезагрузки сервера после обновления до 9
2012-03-26 10:29, Eugene Grosbein написал: Паники бывают разные, иногда разносит так, что оно мгновенно ребутится, безо всяких завершающих операций. Отличия моего конфига от GENERIC: maxusers 128 Для начала я бы убрал maxusers. Ещё были сообщения о паниках в девяткином IPSEC, оно используется? Если нет - лучше убрать из ядра. Если есть, вернуться на 8.3 maxusers убрал но, похоже, это не помогло. IPSEC нужен. Сейчас буду на виртуалке пробовать делать откат на 8.3. Странно, но на машине с i386 все отлично работает 12:10[5]aid@dragonfly:~uname -srm FreeBSD 9.0-RELEASE i386 с maxusers и IPSEC. На другой машине amd64 IPSEC в ядре есть, но не используется, есть maxusers и тоже все отлично. Самое неприятное, что машина, которая перезагружается в другом городе и я не могу посмотреть как происходит перезагрузка. Хоть камкодер просить вешать :)
Re: [freebsd] Re: [freebsd] Проблемы с mtu на роутере
Остается смотреть в сторону net/tcpmssd ? Ибо патчить ipfw на предмет setdf 0 не имею желания... --- Исходное сообщение --- От кого: Виталий Туровец core...@corebug.net Кому: Владислав Продан univers...@ukr.net Дата: 26 марта 2012, 15:18:54 Тема: [freebsd] Re: [freebsd] Проблемы с mtu на роутере 26 марта 2012 г. 15:05 пользователь Владислав Продан univers...@ukr.net написал: Имеем тазик: FreeBSD 8.2-STABLE от Jun 1 00:52:47 EEST 2011 три физических интерфейса: re0 - локальная сеть re1 - uplink#1 re2 - uplink#2 везде выставлено mtu 1500 Частично работает туннель gif1 через re2 Пинги ходят, bgp сессии пашут, но http запросы идут только в одном направлении Выставлении mtu 1400 не помогает... Можно посмотреть в сторону принудительного снятия IP флага DF на проблемных линках, ну и поиграться с TCP MSS. -- Vladislav V. Prodan System Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE
[freebsd] Re: [freebsd] Re: [freebsd] Проблемы с mtu на роутере
26 марта 2012 г. 15:54 пользователь Владислав Продан univers...@ukr.net написал: Остается смотреть в сторону net/tcpmssd ? Ибо патчить ipfw на предмет setdf 0 не имею желания... --- Исходное сообщение --- От кого: Виталий Туровец core...@corebug.net Кому: Владислав Продан univers...@ukr.net Дата: 26 марта 2012, 15:18:54 Тема: [freebsd] Re: [freebsd] Проблемы с mtu на роутере 26 марта 2012 г. 15:05 пользователь Владислав Продан univers...@ukr.net написал: Имеем тазик: FreeBSD 8.2-STABLE от Jun 1 00:52:47 EEST 2011 три физических интерфейса: re0 - локальная сеть re1 - uplink#1 re2 - uplink#2 везде выставлено mtu 1500 Частично работает туннель gif1 через re2 Пинги ходят, bgp сессии пашут, но http запросы идут только в одном направлении Выставлении mtu 1400 не помогает... Можно посмотреть в сторону принудительного снятия IP флага DF на проблемных линках, ну и поиграться с TCP MSS. -- Vladislav V. Prodan System Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE Понимаю, что overkill, но у меня когда-то такая проблема решилась парой дешевых цисок с ebay с 'set ip df 0' в роутмапах. -- ~~~ WBR, Vitaliy Turovets Systems Administrator Corebug.Net +38(093)265-70-55 VITU-RIPE
[freebsd] PF уже умеет SMP или нет?
Интересует как под FreeBSD 9.0 так и под OpenBSD 5.0.
Re: [freebsd] Скорость работы NFS при копировании блоками разного размера
On Mon, 26 Mar 2012 11:49:33 +0400 Владимир Друзенко wrote: ВД 25.03.2012 15:56, Mikolaj Golub пишет: On Sun, 25 Mar 2012 07:11:50 +0400 Владимир Друзенко wrote: ВД Тред нашёл: ВД http://lists.freebsd.org/pipermail/freebsd-stable/2011-November/064611.html ВД Но в нём обсуждается другой вопрос - просто о низкой пропускной ВД способности NFS. ВД Указанные там тюнинги увеличили скорость в 1.1-1.4 раза, но скачок при ВД размере буфера 800-900Kb так и остался: ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884983* count=256 ВД 226555648 bytes transferred in 55.568878 secs (*4077024* bytes/sec) ВД # dd if=/dev/zero of=/mnt/documents/test.zero bs=*884982* count=256 ВД 226555392 bytes transferred in 2.931009 secs (*77296040* bytes/sec) ВД Тюнинги на клиенте: nfs опции mount - ВД rw,intr,soft,bg,nfsv3,readahead=4,wsize=65536,rsize=65536,tcp,async. ВД Тюнинги на сервере: zfs set sync=disabled datastorage/documents/ ВД vfs.nfsrv.async/ в 9.0 нет. ВД Патч из треда и для /vfs.nfsrv.async /так же НЕ накладывал. ВД Может ещё какие мысли? Задампить трафик tcpdump-ом для двух случаев и посмотреть в wireshark в чем отличие. ВД Спасибо за наводку. ВД Отфильтровал оба случая по наличию nfs.write.committed: в случае ВД нормальной скорости Committed: UNSTABLE (0), а в случае плохой ВД Committed: FILE_SYNC (2). ВД При копировании 8 блоков вышеуказанных размеров получается чуть более ВД 100 таких строк в каждом случае: ВД V3 WRITE Replay (Call xxx) Len:65536 UNSTABLE и V3 WRITE Replay (Call ВД xxx) Len:65536 FILE_SYNC соответственно. ВД Также в случае медленной скорости было 6 пакетов вида: [RPC duplicate ВД of #4302][TCP Retransmission] V3 WRITE Reply (Call In 4274) Len:65536 ВД FILE_SYNC. ВД Теперь хотя бы понятно кто виноват. Остался вопрос что делать?. ВД Дампы могу выслать, если нужно - оба в архиве 130Kb. Советую в freebsd-fs@ написать. Есть вероятность что там смогут помочь. По поводу FILESYNC, jhb@ описывал как он наблюдал, но в другой ситуации, при сборке: http://lists.freebsd.org/pipermail/freebsd-fs/2011-August/012265.html Не вчитывался чем закончилось обсуждение, патч есть, но похоже он так и не был закомичен. -- Mikolaj Golub
Re: [freebsd] PF уже умеет SMP или нет?
On Mon, 26 Mar 2012 21:23:21 +0300 skeletor skele...@lissyara.su wrote: Интересует как под FreeBSD 9.0 так и под OpenBSD 5.0. А что в OpenBSD уже прикрутили SMP?
