Как определить, что в simfs на виртуальной машине, которую я использую, работают секретные файловые блокировки POSIX?

Я ищу утилиту командной строки или какой-то другой способ проверить эффективность блокировок файлов, в частности, консультативных блокировок POSIX (не только для POSIX, кстати) в файловой системе Linux.

В частности, я хочу убедиться, что консультативная блокировка POSIX (блокировка файлов) работает правильно в simfs на виртуальной машине Linux/Ubuntu, используемой для непрерывного тестирования интеграции. У нас было повреждение файла, которое происходит только с файлом БД SQLite при одновременной записи 30 процессами. Это используется только в тестировании одним проектом, но мы хотели бы помочь отследить проблему, чтобы другие не столкнулись с ней.

Согласно команде и документации SQLite, одновременные записи поддерживаются только тогда, когда в файловой системе / ОС работают рекомендательные блокировки POSIX. У меня есть тест, который использует SQLite, работает в v3.7.7 SQLite в OS X, но тот же тест повреждает файл DB в 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, я слышал только о тесте пинг-понга, который является частью smbtorture, который проверяет блокировку POSIX с помощью Samba, но в этом случае я не использую Samba, поэтому Я не уверен, что это поможет.

Если тест для командной строки недоступен, как мне проверить, работает ли он, если у меня есть только ограниченный доступ к ВМ (поскольку sudo не требует пароль от моего пользователя, но команды, которые должен выводить что-то с помощью sudo, не работает, так что я думаю, что это переопределено)? Есть ли команды, которые я мог бы запустить администратором виртуальной машины, чтобы собрать больше информации, чтобы помочь решить эту проблему?

Источник

2 ответа

Прежде всего: файловые блокировки и мьютексы 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)

Он пытается заблокировать один и тот же файл в 2 разных процессах. Вторая блокировка неблокирующая, поэтому следует немедленно вызвать ошибку. Ожидаемый результат, если блокировки 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" пытается получить блокировку, то это означает, что этот процесс взаимодействует для обеспечения "сериализации".

Консультативная блокировка будет работать, только если участвующий процесс является кооперативным. Консультативная блокировка иногда также называется "принудительной" блокировкой.

Источник
Другие вопросы по тегам