O sistema de arquivos pode ficar inconsistente se for interrompido ao mover um arquivo?

Question

Eu tenho duas pastas na mesma partição (EXT2) Se eu mv folder1/file folder2 e alguma interrupção ocorrer (por exemplo, falha de energia), o sistema de arquivos pode acabar sendo inconsistente?

A operação mv não é atômica?

Atualização: Até agora no IRC eu tenho as seguintes perspectivas:

1. é atômico, então inconsistências não podem acontecer
2. primeiro você copia a entrada dir no novo diretório e depois apaga a entrada no diretório anterior, assim você pode ter a inconsistência de ter um arquivo referenciado duas vezes, mas a contagem de referência é 1
3. primeiro apaga o ponteiro e depois copia o ponteiro para que a inconsistência seja que o arquivo tenha referência 0

Alguém pode esclarecer?

    

Answer 1

Primeiro, vamos dissipar alguns mitos.

it is atomic so inconsistencies cannot happen

Mover um arquivo dentro do mesmo sistema de arquivos (ou seja, a rename ) chamada do sistema é atômica em relação ao ambiente de software. Atomicidade significa que qualquer processo que procurar o arquivo irá vê-lo em seu local antigo ou em seu novo local; nenhum processo poderá observar que o arquivo tem uma contagem de links diferente ou que o arquivo está presente no diretório de origem após estar presente no diretório de destino ou que o arquivo está ausente do diretório de destino depois de estar ausente na origem diretório.

No entanto, se o sistema travar devido a um bug, um erro de disco ou uma perda de energia, não há garantia de que o sistema de arquivos seja deixado em um estado consistente, e muito menos que o movimento não seja feito pela metade. O Linux não oferece, em geral, uma garantia de atomicidade em relação aos eventos de hardware.

first you copy the dir entry in the new dir and then erase entry on previous dir, so you may have the inconsistency of having a file referenced twice, but the ref count is 1

Isso se refere a uma técnica de implementação específica. Existem outros.

Acontece que ext2 no Linux (como do kernel 3.16) usa essa técnica em particular. No entanto, isso não implica que o conteúdo do disco passe pela sequência [localização antiga] → [ambos os locais] → [novo local], porque as duas operações (adicionar nova entrada, remover entrada antiga) não são atômicas no nível do hardware : é possível que um deles seja interrompido, deixando o sistema de arquivos em um estado inconsistente. (Espero que o fsck conserte isso.) Além disso, a camada de bloco pode reordenar as gravações, portanto a primeira metade pode ser confirmada no disco logo antes da falha e a segunda metade não teria sido executada.

A contagem de referência nunca será observada como diferente de 1, desde que o sistema não trave (veja acima), mas essa garantia não se estende a um travamento do sistema.

it first erases the pointer and then copy the pointer so the inconsistency is that the file has reference 0

Mais uma vez, isso se refere a uma técnica de implementação específica. Um arquivo pendente não pode ser observado se o sistema não travar, mas é uma conseqüência possível de uma falha do sistema, pelo menos em algumas configurações.

De acordo com um post de Alexander Larsson , o ext2 não oferece garantia de consistência em uma falha do sistema, mas o ext3 faz no modo data=ordered . (Observe que esta postagem do blog não é sobre o rename em si, mas sobre a combinação de gravação em um arquivo e a chamada de rename nesse arquivo.)

Theodore Ts'o, o principal autor dos sistemas de arquivos ext2, ext3 e ext4, escreveu um postagem no blog sobre o mesmo problema . Esta postagem do blog discute atomicidade (com relação ao ambiente de software somente) e durabilidade (que é a atomicidade em relação a falhas mais uma garantia de compromisso, ou seja, sabendo que a operação foi realizada). Infelizmente não consigo encontrar informações sobre a atomicidade em relação a falhas sozinho. No entanto, as garantias de durabilidade fornecidas para o ext4 exigem que rename seja atômico. A documentação do kernel para ext4 indica que ext4 com a opção auto_da_alloc (que é o padrão em kernels modernos), bem como ext4, fornece uma garantia de durabilidade para um write seguido por um rename , o que implica que rename é atômico com relação a travamentos de hardware.

Para o Btrfs, um rename que sobrescreve um arquivo existente é garantido para ser atômico com relação a falhas, mas um rename que não sobrescreve um arquivo pode resultar em nenhum arquivo ou ambos os arquivos existentes.

Em resumo, a resposta à sua pergunta é que não apenas a movimentação de um arquivo não é atômica em relação a travamentos no ext2, mas também não é garantido que ele deixe o arquivo em um estado consistente (apesar de falhas que fsck não é possível reparar são raras) - praticamente nada é, e é por isso que sistemas de arquivos melhores foram inventados. Ext3, ext4 e btrfs fornecem garantias limitadas.

    

Answer 2

A operação renomear é muito rápida em qualquer sistema de arquivos, então é improvável que ela seja interrompida, mas em um sistema de arquivos clássico ela certamente pode ser interrompida - se ela criar o link de destino primeiro, pode deixar dois links em um arquivo - o que é legal, mas o arquivo pensa que ele tem apenas um, o que pode causar problemas se um for excluído posteriormente. Por outro lado, se remover primeiro o link de origem, o arquivo poderá ser perdido. A execução do fsck geralmente detecta e corrige uma das condições, mas se o arquivo for perdido, ele será colocado em um diretório "lost + found" com um nome arbitrário em vez de no local desejado - e se tiver dois links, a contagem de links será simplesmente ser atualizado, para que o arquivo exista em dois locais, se o sistema de arquivos suportar isso.

Se você precisa que um sistema de arquivos seja robusto diante de falhas de energia, você deve usar um sistema de arquivos de registro no diário , como NTFS, EXT3 ou XFS. A maioria dos sistemas modernos usará um sistema de arquivos de registro no diário por padrão, embora você deva estar ciente de que o FAT não é um sistema de arquivos de registro no diário se você usá-lo para unidades externas.

Um sistema de arquivos de registro no diário usa um sistema de "entrada dupla" - ele grava no arquivo de diário o fato de que pretende movê-lo e, em seguida, executa o movimento. Quando o sistema de arquivos é verificado na inicialização, se foi interrompido, ele notará que o movimento não foi concluído e refazerá-lo.

Existem dois tipos de sistemas de arquivos de journaling - journaling de metadados e journaling completo. O registro em diário de metadados significa que ele não controla as alterações no conteúdo dos arquivos no sistema de diário (portanto, você pode perder o conteúdo se estiver gravando em um arquivo), mas ele ainda mantém informações importantes sobre o sistema de arquivos, como o conteúdo do diretório , propriedades de arquivos, etc.

Quando as pessoas falam sobre a operação de renomeação ser atômica, elas significam que ela não pode ser observada no meio da transição por outro processo no sistema, e não pode ser deixada incompleta por meio de, e. interrompendo o comando mv com ^ C . O processo físico de gravar em cada diretório, cujo espaço de armazenamento pode estar em locais amplamente diferentes no disco, não pode ser uma operação verdadeiramente atômica no nível do hardware.

Para completar, observarei que também há algumas operações de E / S incidentais associadas a uma renomeação, além de criar o novo link no diretório de destino e removê-lo no antigo - atualizando o mtime de ambos os diretórios, possivelmente estendendo o tamanho de alocação do diretório de destino, alterando o link .. e as contagens de link dos diretórios-pai, se o arquivo for um diretório. Além disso, não tenho certeza se o atime do arquivo em si é afetado.

    

Answer 3

Esta pergunta foi feita de uma maneira um pouco diferente no Super User . A página da Wikipedia sobre o comando mv também explica bem :

Moving files within the same file system is generally implemented differently than copying the file and then removing the original. On platforms that do not support the rename syscall, a new link is added to the new directory and the original one is deleted. The data of file is not accessed.

O Linux tem o renomear o syscall e, portanto, renomeia o arquivo como um atômico, ou seja, operação ininterrupta. Portanto, não, o sistema de arquivos não pode se tornar inconsistente na situação que você descreveu.