Bug 22191

Summary: Регулярно ломается файл locking.tdb
Product: Sisyphus Reporter: Alexey Borovskoy <alb>
Component: sambaAssignee: Evgeny Sinelnikov <sin>
Status: CLOSED WONTFIX QA Contact: qa-sisyphus
Severity: blocker    
Priority: P3 CC: aen, aspsk, erthad, sin
Version: unstable   
Hardware: all   
OS: Linux   

Description Alexey Borovskoy 2009-11-06 03:47:47 MSK
Поскольку компонента 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.

Отловить причину не получается. Буду рад любой помощи.
Comment 1 Alexander Bokovoy 2009-11-06 08:33:59 MSK
Опишите точно процедуру бэкапа. Действительно, есть вероятность, что повреждены данные в /var/lib/samba/locking.tdb, поскольку Самба очень чувствительна к поведению файловой системы. См. http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html
Comment 2 Alexey Borovskoy 2009-11-06 11:12:49 MSK
Алгоритм бэкапа

# 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 и нет кода проверки на получение блокировки. И в файл начинают писать два процесса одновременно.
Comment 3 Alexey Borovskoy 2009-11-06 11:27:30 MSK
Почитал блог.

Раздел мотнируется так:

/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)
Comment 4 Alexey Borovskoy 2009-11-06 11:28:27 MSK
Почитал блог.

Раздел монтируется так:

/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)
Comment 5 Alexander Bokovoy 2009-11-06 15:26:16 MSK
Я предполагаю, что это ошибка во взаимодействии simfs и ext3 с lvm. Самба пытается гарантировать осмысленность locking.tdb при записи, а создание снапшота в lvm, видимо, не синхронизировано с ext3/simfs -- в результате не всегда корректно сбрасываются буфера и содержимое отдельных инодов теряется. Высокая нагрузка на дисковую подсистему как раз может провоцировать это поведение.

В данном случае проблема не в блокировках как таковых, а в том, что прочитанное с диска состояние записи в locking.tdb не соответствует ожидавшемуся.
Comment 6 aspsk 2009-11-12 10:56:32 MSK
> Отловить причину не получается. Буду рад любой помощи.

Читали ли Вы данный thread?
http://lists.samba.org/archive/samba/2007-August/134395.html
Comment 7 Alexander Bokovoy 2009-11-12 12:46:50 MSK
Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd нужно писать и читать из locking.tdb и информация в нем должна быть корректной. Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb, это критическая ситуация для smbd и она обрабатывается должным образом.

Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.
Comment 8 aspsk 2009-11-12 12:54:51 MSK
(В ответ на комментарий №7)
> Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не
> smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd
> нужно писать и читать из locking.tdb и информация в нем должна быть корректной.
> Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации
> при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb,
> это критическая ситуация для smbd и она обрабатывается должным образом.
> 
> Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему
А при переезде содержимое locking.tdb сохраняется?

> устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.
Comment 9 Alexander Bokovoy 2009-11-12 13:00:59 MSK
locking.tdb -- это временная база данных, которая обнуляется при перезапуске smbd. Поскольку "переезд" на ovz-rhel -- это смена ядра, то ответ очевиден.

Насколько я понял Алексея, при повторении процедуры из комментария #2 в случае ovz-rhel порчи данных не происходит. Процедура выполняется по-живому -- при работающем контейнере.
Comment 10 Vitaly Kuznetsov 2010-05-29 01:16:00 MSD
Из обсуждения видно, что ошибки в samba (тем более в Сизифной) нет. Если это не так - просьба переоткрыть баг (с возможным перевешиванием на ядро).