O 'ln' é atômico e confiável no NFS? O NFS poderia substituir o GFS neste caso de uso?

Question

Eu tenho um cluster com vários servidores com um disco compartilhado contendo um sistema de arquivos global GFS que todos os nós acessam simultaneamente.

Cada nó no cluster executa o mesmo programa (um script de shell é o núcleo principal). O sistema processa arquivos que aparecem em alguns diretórios de entrada e funciona assim:

• o programa percorre os diretórios de entrada.
• para cada arquivo encontrado, verifique a existência de um "arquivo de bloqueio", se o arquivo de bloqueio existir, pule para o próximo arquivo.
• se nenhum arquivo de bloqueio for encontrado, crie um arquivo de bloqueio. Se a criação do arquivo de bloqueio falhou (corrida perdida), pule para o próximo arquivo
• se "nós" for proprietário do bloqueio, processe o arquivo e mova-o para fora quando terminar.

Isso tudo funciona muito bem, mas me pergunto se existem soluções mais baratas (menos complexas) que também funcionariam. Estou pensando em NFS ou SMB, talvez.

Existem dois motivos para o uso do GFS:

1. cada arquivo é armazenado em um único local (com hardware subjacente redundante, é claro)
2. o bloqueio de arquivos funciona de forma confiável

Eu crio o arquivo de bloqueio assim:

date '+%s:'${unid} > ${currlock}.${unid}
ln ${currlock}.${unid} ${currlock}
lockrc=$?
rm -f ${currlock}.${unid}

em que $unid é um identificador de sessão exclusivo e $currlock é /gfs/tmp/lock.${file_to_process}

A beleza de ln é que ela é atômica , por isso falha para todos, menos um que tenta a mesma coisa ao mesmo tempo.

Então, eu acho que o que estou perguntando é: o NFS preencherá minhas necessidades? O ln funciona de maneira confiável da mesma maneira no NFS do que no GFS?

    

Answer 1

A chamada do sistema link() no cliente NFS deve ser mapeada diretamente para a operação LINK do NFS, que o servidor deve implementar usando sua chamada de sistema link() . Portanto, contanto que link() seja atômico no servidor, ele também será atômico nos clientes.