Я ищу утилиту командной строки или другой способ проверить эффективность файловые замкив частности Консультативные блокировки POSIX (кстати, не только для POSIX) в файловой системе Linux.
В частности, я хочу убедиться, что консультативная блокировка POSIX (блокировка файлов) работает правильно в simfs на виртуальной машине Linux / Ubuntu, используемой для непрерывного тестирования интеграции. У нас было повреждение файла, которое происходит с файлом базы данных SQLite только при одновременной записи 30 процессами. Это используется только при тестировании одним проектом, но мы хотели бы помочь отследить проблему, чтобы другие не столкнулись с ней.
Согласно команде SQLite и документации, одновременная запись поддерживается только тогда, когда рекомендательные блокировки POSIX работают в файловой системе / ОС. Имеющийся у меня тест, использующий SQLite, работает в версии v3.7.7 SQLite в OS X, но тот же тест повреждает файл базы данных в версии v3.7.9 SQLite в виртуальной машине Ubuntu, предоставленной TravisCI (и размещенной в Blue Box). Команда SQLite не указала, что между этими двумя версиями были устранены какие-либо проблемы с параллелизмом, поскольку параллелизм зависит от работы рекомендательных блокировок POSIX ОС / файловой системы.
Дополнительная информация об окружающей среде, которую я пытаюсь исследовать:
$ sqlite3 -version
3.7.9 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e
$ uname -r
2.6.32-042stab061.2
$ cat /proc/version
Linux version 2.6.32-042stab061.2 (root@rh6-build-x64) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Aug 24 09:07:21 MSK 2012
$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise
(home dir it that is exhibiting the problem is within the / mount.)
$ cat /proc/mounts
/dev/simfs / simfs rw,relatime 0 0
...
$ mount
/vz/private/6062841 on / type simfs (rw)
...
У меня есть билет для тех, кто предоставляет виртуальную машину Вот где они заявили, что не используют сетевые файловые системы, которые обычно связаны с проблемами, связанными с блокировками POSIX, из-за сложности, связанной с реализацией блокировок POSIX в таких средах. В дополнение к приведенной выше информации этот пресс-релиз может показаться, что используется OpenStack, путь выше показывает 'vz' в монтировании, что заставляет OpenVZ используется.
Что касается инструментов, помогающих диагностировать сбои блокировки POSIX, единственное, о чем я слышал, - это тест для пинг-понга, который является частью вызываемого пытка который проверяет блокировку POSIX с помощью Samba, но я не использую Samba в этом случае, поэтому я не уверен, что это поможет.
Если нет доступного теста командной строки, как я могу проверить его работоспособность, если у меня есть все, что у меня есть, это ограниченный доступ к виртуальной машине (поскольку sudo не требует пароля от моего пользователя, но команды, которые должен выводить что-то с помощью sudo, не работает, поэтому я думаю, что это переопределено)? Существуют ли команды, которые я мог бы запустить администратором виртуальной машины для сбора дополнительной информации и решения этой проблемы?
Во-первых: блокировки файлов и мьютексы pthread - это совершенно разные чудовища. Файловые блокировки используются для извещения текущего или другой обрабатывает, что файл в настоящее время не используется. Мьютексы Pthread используются для координации критических секций между потоками в только текущий процесс.
Блокировка файлов сделана flock(2) и друзья, и, что удобно, для этого есть оболочка сценария оболочки. Чтобы проверить, работает ли блокировка файлов, вы открываете два терминала и запускаете это:
В первом терминале:
flock /path/to/lockfile sleep 120
И в другом терминале, пока первый удерживает блокировку:
if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi
Это должно сказать вам, работают ли блокировки файлов.
И если вам нужно запустить его в одном скрипте, попробуйте следующее:
flock /path/to/lockfile sleep 120 &
if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi
kill $!
Другой способ блокировки файлов - это fcntl системный вызов. Тестировать с Ruby довольно неприятно, но этот код Python должен помочь:
import fcntl, os, time
fd = open('/tmp/test.lock', 'w')
if os.fork():
fcntl.lockf(fd, fcntl.LOCK_EX)
os.wait()
else:
time.sleep(0.1)
fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB)
Он пытается заблокировать один и тот же файл в двух разных процессах. Вторая блокировка неблокирующая, поэтому должна немедленно вызвать ошибку. Ожидаемый результат, если блокировки fcntl работают правильно, будет:
Traceback (most recent call last):
File "test.py", line 12, in <module>
fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB)
IOError: [Errno 11] Resource temporarily unavailable
У меня нет openvz vm для проведения теста, но я думаю, вам нужно прочитать это примечание о рекомендательной блокировке. Консультативная блокировка требует сотрудничества со стороны участвующих процессов. Предположим, что процесс «A» получает блокировку WRITE и начал запись в файл, а процесс «B», не пытаясь получить блокировку, может открыть файл и записать в него. Здесь процесс «B» - это не сотрудничающий процесс. Если процесс «B» пытается получить блокировку, это означает, что этот процесс взаимодействует для обеспечения «сериализации».
Консультативная блокировка будет работать, только если участвующие процессы действуют совместно. Консультативная блокировка иногда также называется «принудительной блокировкой».