Поскольку компонента Arc Server для развешивания бага нету, вешаю сюда. # cat /etc/altlinux-release ALT Linux 5.0.0 Ark Server (none) # rpm -qa|grep kernel kernel-image-ovz-smp-2.6.27-alt9 # rpm -qa|grep lvm lvm2-2.02.53-alt1 liblvm2-2.02.53-alt1 # rpm -qa|grep samba samba-common-3.0.37-alt1 samba-client-3.0.37-alt1 samba-client-cups-3.0.37-alt1 samba-client-control-1.2-alt2 samba-3.0.37-alt1 Ежедневно наблюдаю следующее: tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0xd9fee666 at offset=1058708 [2009/11/05 09:57:47, 0] lib/util.c:smb_panic(1633) PANIC (pid 4811): Could not store share mode entry [2009/11/05 09:57:47, 0] lib/util.c:log_stack_trace(1737) BACKTRACE: 11 stack frames: #0 /usr/sbin/smbd(log_stack_trace+0x2d) [0xb7e527dd] #1 /usr/sbin/smbd(smb_panic+0x5d) [0xb7e5292d] #2 /usr/sbin/smbd [0xb7df4389] #3 /usr/sbin/smbd(talloc_free+0x194) [0xb7e37b04] #4 /usr/sbin/smbd(open_file_ntcreate+0xdb9) [0xb7cb75b9] #5 /usr/sbin/smbd(reply_ntcreate_and_X+0xfb5) [0xb7c7c165] #6 /usr/sbin/smbd [0xb7ccb432] #7 /usr/sbin/smbd(smbd_process+0x27f) [0xb7ccd27f] #8 /usr/sbin/smbd(main+0xa31) [0xb7f2ee31] #9 /lib/libc.so.6(__libc_start_main+0xe6) [0xb78bab26] #10 /usr/sbin/smbd [0xb7c4c8a1] [2009/11/05 09:57:47, 0] lib/fault.c:dump_core(181) dumping core in /var/log/samba/cores/smbd После возникновения этой ошибки, с самбы невозможно работать с файлами вообще. Ночью выполняется бэкап путем создания снапшота lvm. Возможно падает из-за lvm. Возможно из-за связки ядра и lvm. Отловить причину не получается. Буду рад любой помощи.
Опишите точно процедуру бэкапа. Действительно, есть вероятность, что повреждены данные в /var/lib/samba/locking.tdb, поскольку Самба очень чувствительна к поведению файловой системы. См. http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html
Алгоритм бэкапа # lvs File descriptor 7 (pipe:[500644]) leaked on lvs invocation. Parent PID 5038: bash LV VG Attr LSize Origin Snap% Move Log Copy% Convert ovz lvm0 -wi-ao 4,97G 1. lvcreate -s -L 1G -n ovz-snapshot /dev/lvm0/ovz 2. mount -o ro /dev/lvm0/ovz-snapshot /mnt/snapshot 3. tar -c /mnt/snapshot -f /mnt/backup/ovz.tar 4. umount /mnt/snapshot 5. lvremove -f /dev/lvm0/ovz-snapshot На ALS 4.0.1 + Updates 4.0 такое работает с момента появления ALS 4.0.0. Самба работает внутри ovz-контейнера. На самом деле томов lvm больше. Они тоже бэкапятся по вышеприведенной схеме. Как вариант, из-за высокой дисковой активности во время бэкапа, в коде самбы не получается залочить файл locking.tdb и нет кода проверки на получение блокировки. И в файл начинают писать два процесса одновременно.
Почитал блог. Раздел мотнируется так: /etc/fstab /dev/lvm0/ovz /var/lib/vz ext3 defaults,data=journal 0 2 #mount /dev/mapper/lvm0-ovz on /var/lib/vz type ext3 (rw,data=journal)
Почитал блог. Раздел монтируется так: /etc/fstab /dev/lvm0/ovz /var/lib/vz ext3 defaults,data=journal 0 2 #mount /dev/mapper/lvm0-ovz on /var/lib/vz type ext3 (rw,data=journal)
Я предполагаю, что это ошибка во взаимодействии simfs и ext3 с lvm. Самба пытается гарантировать осмысленность locking.tdb при записи, а создание снапшота в lvm, видимо, не синхронизировано с ext3/simfs -- в результате не всегда корректно сбрасываются буфера и содержимое отдельных инодов теряется. Высокая нагрузка на дисковую подсистему как раз может провоцировать это поведение. В данном случае проблема не в блокировках как таковых, а в том, что прочитанное с диска состояние записи в locking.tdb не соответствует ожидавшемуся.
> Отловить причину не получается. Буду рад любой помощи. Читали ли Вы данный thread? http://lists.samba.org/archive/samba/2007-August/134395.html
Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd нужно писать и читать из locking.tdb и информация в нем должна быть корректной. Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb, это критическая ситуация для smbd и она обрабатывается должным образом. Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.
(В ответ на комментарий №7) > Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не > smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd > нужно писать и читать из locking.tdb и информация в нем должна быть корректной. > Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации > при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb, > это критическая ситуация для smbd и она обрабатывается должным образом. > > Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему А при переезде содержимое locking.tdb сохраняется? > устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.
locking.tdb -- это временная база данных, которая обнуляется при перезапуске smbd. Поскольку "переезд" на ovz-rhel -- это смена ядра, то ответ очевиден. Насколько я понял Алексея, при повторении процедуры из комментария #2 в случае ovz-rhel порчи данных не происходит. Процедура выполняется по-живому -- при работающем контейнере.
Из обсуждения видно, что ошибки в samba (тем более в Сизифной) нет. Если это не так - просьба переоткрыть баг (с возможным перевешиванием на ядро).
