Como determinar se os bloqueios do arquivo de aviso POSIX estão funcionando em simfs na VM que estou usando?

2

Estou procurando um utilitário de linha de comando ou alguma outra maneira de testar a eficácia dos bloqueios de arquivos , especificamente < a href="https://computing.llnl.gov/tutorials/pthreads/#MutexLocking"> bloqueios de aviso POSIX (que não são apenas para POSIX, btw) em um sistema de arquivos Linux.

Especificamente, quero garantir que o bloqueio consultivo POSIX (bloqueio de arquivo) esteja funcionando corretamente em simfs em uma VM Linux / Ubuntu usada para testes de integração contínua. Nós tivemos corrupção de arquivos que ocorre apenas em um arquivo DB SQLite quando há gravações simultâneas por 30 processos. Isso está sendo usado apenas em testes de um projeto, mas gostaríamos de ajudar a rastrear o problema para que outros não colidam com ele.

De acordo com a equipe e a documentação do SQLite, as gravações simultâneas são suportadas apenas quando os bloqueios de aviso do POSIX estão funcionando no sistema de arquivos / sistema operacional. O teste que tenho que usa SQLite funciona na v3.7.7 do SQLite no OS X, mas o mesmo teste corrompe o arquivo DB na v3.7.9 do SQLite no Ubuntu VM fornecido pelo TravisCI (e hospedado pela Blue Box). A equipe do SQLite não indicou que havia problemas de simultaneidade entre essas duas versões, já que a simultaneidade é dependente dos bloqueios do sistema operacional do OS / sistema de arquivos.

Informações adicionais sobre o ambiente que estou tentando investigar:

$ 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)
...

Eu tenho um ingresso com aqueles que fornecem a VM aqui onde eles afirmaram que não estão usando sistemas de arquivos de rede, que geralmente estão associados a problemas relacionados ao bloqueio POSIX devido à complexidade envolvida na implementação de bloqueios POSIX em tais ambientes. Além das informações acima, embora este press release pareça indicar que o OpenStack está sendo usado, o caminho acima mostra 'vz' no monte, fazendo com que pareça OpenVZ está sendo usado.

Quanto a ferramentas para ajudar a diagnosticar falhas de bloqueio POSIX, a única sobre a qual eu ouvi falar é um teste de pingue-pongue que é parte do chamado smbtorture que testa o bloqueio POSIX com o Samba, mas eu não estou usando o Samba neste caso, então não tenho certeza se isso ajudaria.

Se não houver nenhum teste de linha de comando disponível, como eu tentaria testar se tudo o que tenho disponível para mim é acesso limitado à VM (como sudo não requer senha como meu usuário, mas os comandos que devem gerar algo usando o sudo não funcionam, então eu acho que ele foi cancelado)? Existem comandos que eu poderia executar o administrador da VM para coletar mais informações para ajudar a resolver esse problema?

    
por Gary S. Weaver 18.08.2013 / 14:36

2 respostas

3
Primeiro: os bloqueios de arquivos e os mutexes de pthread são bestas completamente diferentes. Os bloqueios de arquivo são usados para aconselhar os processos ou outros atuais que um arquivo não está sendo usado no momento. Mutexes Pthread são usados para coordenar seções críticas entre threads no somente o processo atual .

O bloqueio de arquivos é feito com flock(2) e amigos e, convenientemente, há um wrapper de script de shell para ele. Para testar se os bloqueios de arquivo funcionam, você abre dois terminais e executa isto:

No terminal um:

flock /path/to/lockfile sleep 120

E no outro terminal enquanto o primeiro está segurando o bloqueio:

if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi

Isso deve informar se os bloqueios de arquivos funcionam.

E se você precisar executá-lo em um script, tente o seguinte:

flock /path/to/lockfile sleep 120 &
if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi
kill $!

Outra maneira de bloquear arquivos é a chamada do sistema fcntl . É bastante irritante testar com o ruby, mas esse código em Python deve funcionar:

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)

Ele tenta bloquear o mesmo arquivo em dois processos diferentes. O segundo bloqueio não é bloqueado, portanto, deve imediatamente gerar um erro. A saída esperada, se os bloqueios fcntl estiverem funcionando corretamente, é:

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
    
por 20.08.2013 / 23:30
0

Eu não tenho o openvz vm para fazer um teste, mas acho que você precisa ler esta nota sobre o bloqueio consultivo, o bloqueio do Advisory requer cooperação dos processos participantes. Suponha que o processo “A” adquira um bloqueio de WRITE e ele tenha começado a gravar no arquivo e processe “B”, sem tentar adquirir um bloqueio, ele pode abrir o arquivo e gravá-lo. Aqui o processo “B” é o processo não cooperativo. Se o processo “B” tentar adquirir um bloqueio, significa que este processo está cooperando para garantir a “serialização”.

O bloqueio consultivo funcionará somente se o processo de participação for cooperativo. Bloqueio de aviso, às vezes também chamado de bloqueio "não forçado".

    
por 22.08.2013 / 09:18