Subnets.ru

Привет всем. Помогите разобраться с одной проблемкой.
Купил себе sata жесткий диск размером 1Тб. Подключил его к фре, выполнил newfs /dev/ad4 и тут началось веселье.
На этот раздел и hdd в целом скидываются файлы статистики + на нем поднят один из ресурсов самбы, который я предоставляю одному человеку. Все бы ничего, но когда в очередной раз, при закачке на хард 16Гб, система начала паниковать - возник вопрос почему вызывается паника ядра?
Загрузка статистики по scpроходит нормально.
Вот содержимое /etc/fstab:

Код: Выделить всё

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ad0s1b             none            swap    sw              0       0
/dev/ad0s1a             /               ufs     rw              1       1
/dev/ad0s1d             /tmp            ufs     rw              2       2
/dev/ad0s1f             /usr            ufs     rw              2       2
/dev/ad0s1e             /var            ufs     rw              2       2
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0
/dev/ad4                /stat           ufs     rw              2       2


Строку

Код: Выделить всё

/dev/ad4                /stat           ufs     rw              2       2

я дописывал сам.

Ткните носом куда смотреть. Предложите варианты решения проблемы.

Заранее благодарен за ответы.

Вопросы:
1. uname -a
2. На каком процессе "вываливается" фря? Если идет паника ядра, то совсем необязательно, что это из-за диска.
3. Делал ли backtrace в kgdb?

1. FreeBSD Monitor.localhost 7.0-RELEASE FreeBSD 7.0-RELEASE
2. Я подозревал какой процесс, но отловить не могу. Читал логи, там сказано это:

Код: Выделить всё

Jun 22 09:08:51 Monitor kernel: WARNING: R/W mount of /stat denied.  Filesystem is not clean - run fsck
Jun 22 09:08:51 Monitor savecore: reboot after panic: vm_fault: fault on nofault entry, addr: d4c29000
Jun 22 09:08:51 Monitor savecore: writing core to vmcore.3


3. Нет. я даже не знаю что это.

Андрей писал(а):1. FreeBSD Monitor.localhost 7.0-RELEASE FreeBSD 7.0-RELEASE

Это вывод не uname -a!

Андрей писал(а):2. Я подозревал какой процесс, но отловить не могу. Читал логи, там сказано это:

Код: Выделить всё

Jun 22 09:08:51 Monitor kernel: WARNING: R/W mount of /stat denied.  Filesystem is not clean - run fsck
Jun 22 09:08:51 Monitor savecore: reboot after panic: vm_fault: fault on nofault entry, addr: d4c29000
Jun 22 09:08:51 Monitor savecore: writing core to vmcore.3


Т.е. корка отложилась - уже хорошо

Андрей писал(а):3. Нет. я даже не знаю что это.

Ну, а погуглить???

Filesystem is not clean - run fsck

ну отмонтируй его и сделай же fsck как он просит
делал ?

Это вывод не uname -a!

Извиняюсь.

Код: Выделить всё

# uname -a
FreeBSD Monitor.localhost 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Fri Apr 10 16:46:25 YEKST 2009     admin@Monitor.localhost:/usr/obj/usr/src/sys/NoKS  i386


Ну а погуглить?

Код: Выделить всё

# kgdb kernel.debug /var/crash/vmcore.3
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: d4c29000
cpuid = 1
Uptime: 5d23h26m13s
Physical memory: 491 MB
Dumping 145 MB: 130 114 98 82 66 50 34 18 2

#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace                                                               
#0  doadump () at pcpu.h:195
#1  0xc078a847 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc078ab09 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc09a26d8 in vm_fault (map=0xc1471000, vaddr=3569520640,
    fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:275
#4  0xc0a7f6fe in trap_pfault (frame=0xd4c2bbdc, usermode=0, eva=3569520640)
    at /usr/src/sys/i386/i386/trap.c:801
#5  0xc0a8010c in trap (frame=0xd4c2bbdc) at /usr/src/sys/i386/i386/trap.c:490
#6  0xc0a6608b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0a7d166 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498
(kgdb) list *0xc078ab09
0xc078ab09 is at /usr/src/sys/kern/kern_shutdown.c:563.
558             /*thread_lock(td); */
559             td->td_flags |= TDF_INPANIC;
560             /* thread_unlock(td); */
561             if (!sync_on_panic)
562                     bootopt |= RB_NOSYNC;
563             boot(bootopt);
564     }
565
566     /*
567      * Support for poweroff delay.
(kgdb) list *0xc09a26d8
0xc09a26d8 is in vm_fault (/usr/src/sys/vm/vm_fault.c:291).
286              * truncation operations) during I/O.  This must be done after
287              * obtaining the vnode lock in order to avoid possible deadlocks.
288              *
289              * XXX vnode_pager_lock() can block without releasing the map lock.
290              */
291             if (fs.first_object->flags & OBJ_NEEDGIANT)
292                     mtx_lock(&Giant);
293             VM_OBJECT_LOCK(fs.first_object);
294             vm_object_reference_locked(fs.first_object);
295             fs.vp = vnode_pager_lock(fs.first_object);
(kgdb) list *0xc0a7f6fe
0xc0a7f6fe is in trap_pfault (/usr/src/sys/i386/i386/trap.c:801).
796             } else {
797                     /*
798                      * Don't have to worry about process locking or stacks in the
799                      * kernel.
800                      */
801                     rv = vm_fault(map, va, ftype, VM_FAULT_NORMAL);
802             }
803             if (rv == KERN_SUCCESS)
804                     return (0);
805     nogo:


ну отмонтируй его и сделай же fsck как он просит
делал ?

Делал. Сразу после жестокого ребута самой оси. Все жесткие диски проверялись.

Андрей писал(а):

Код: Выделить всё

[skip]
#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace                                                               
#0  doadump () at pcpu.h:195
[skip]


Из-за этого случилась паника

Андрей писал(а):

ну отмонтируй его и сделай же fsck как он просит
делал ?

Делал. Сразу после жестокого ребута самой оси. Все жесткие диски проверялись.

Делал в сингл-моде?

Делал в сингл-моде?

Что именно? Проверял или отмонтировал?
После перезагрузки, после паники, раздел был отмонтирован и требовал проверки. Проверку сделал после загрузки и сразу примонтировал.

Из-за этого случилась паника

Что мне надо сделать чтобы не было больше паники? Что это за файл заголовка?

Андрей писал(а):при закачке на хард 16Гб, система начала паниковать

Эти 16Гб состояли из одного файла или из нескольких?
Закачивал этот объем через какой сервис?
Система паникует постоянно или это было один раз?

Андрей писал(а):Что мне надо сделать чтобы не было больше паники? Что это за файл заголовка?

Пока слишком мало инфы для рекомендаций.
какие еще процессы работали в это время?
Хард подключался через SATA или USB?

Эти 16Гб состояли из одного файла или из нескольких?

Из нескольких, наибольшим был файл на 4Гб.

Закачивал этот объем через какой сервис?

Самба.

Система паникует постоянно или это было один раз?

Несколько раз это уже было. В том числе и при закачке по SSH.

какие еще процессы работали в это время?

Самба, mrtg, WildFire, Apache, Mysql.

Хард подключался через SATA или USB?

Sata