ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Регулярно ломается файл locking.tdb | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Alexey Borovskoy <alb> |
| Component: | samba | Assignee: | 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
Опишите точно процедуру бэкапа. Действительно, есть вероятность, что повреждены данные в /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 (тем более в Сизифной) нет. Если это не так - просьба переоткрыть баг (с возможным перевешиванием на ядро). |
