Bug 22191 - Регулярно ломается файл locking.tdb
: Регулярно ломается файл locking.tdb
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/samba)
: unstable
: all Linux
: P3 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-11-06 03:47 by
Modified: 2010-05-29 01:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-11-06 03:47:47
Поскольку компонента 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 From 2009-11-06 08:33:59 -------
Опишите точно процедуру бэкапа. Действительно, есть вероятность, что повреждены
данные в /var/lib/samba/locking.tdb, поскольку Самба очень чувствительна к
поведению файловой системы. См.
http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html
------- Comment #2 From 2009-11-06 11:12:49 -------
Алгоритм бэкапа

# 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 From 2009-11-06 11:27:30 -------
Почитал блог.

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

/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 From 2009-11-06 11:28:27 -------
Почитал блог.

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

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

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

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

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

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

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