Com registro de dados completo, por que os dados aparecem no diretório imediatamente?

Question

Eu tenho uma pergunta sobre o registro de dados completo em sistemas de arquivos ext3. A página man afirma o seguinte:

data=journal
All data is committed into the journal prior to being written into
the main filesystem.

Parece-me que isso significa que um arquivo é salvo primeiro no diário e depois copiado para o sistema de arquivos.

Eu assumi que, se eu baixar algo, ele deve primeiro ser salvo no diário e, se completo, ser movido para o FS. Mas depois de iniciar o arquivo de download aparece no diretório (FS). O que há de errado nisso?

Editar: Talvez seja errado pensar em "todos os dados" = tamanho total do arquivo? Então, se todos os dados são, talvez, apenas um bloco ou algo mais do que faria sentido e eu não podia ver que as coisas são primeiro escritas para o diário?!

    

Answer 1

Primeiro, você está certo ao suspeitar que "todos os dados" não significam todo o arquivo. Na verdade, essa camada do sistema de arquivos opera em blocos de arquivos de tamanho fixo, não em arquivos inteiros. Nesse nível, é importante manter uma quantidade limitada de dados, portanto, trabalhar em arquivos inteiros (que podem ser arbitrariamente grandes) não funcionaria.

Em segundo lugar, há um equívoco na sua pergunta. O comportamento de registro no diário não é algo que você pode observar observando o conteúdo do diretório com ls , ele funciona em um nível muito mais baixo. Com ferramentas normais, você sempre verá que o arquivo está lá. (Seria catastrófico se a criação de um arquivo não aparecesse, você sabe, crie-o.) O que acontece sob o capô é que o arquivo pode ser armazenado de maneiras diferentes. Primeiramente, os primeiros blocos são salvos no diário. Então, tão logo quanto possível, os dados são movidos para o seu local final. Ainda é o mesmo arquivo no mesmo diretório, apenas armazenado de forma diferente.

A única maneira de observar o comportamento do registro em diário é ver o que o kernel está gravando no disco ou analisar o conteúdo do disco após uma falha. Em operação normal, o diário é um detalhe de implementação: se você pudesse vê-lo em ação (diferente de desempenho), ele seria seriamente quebrado.

Para mais informações sobre os periódicos do sistema de arquivos, eu recomendo começar com o artigo da Wikipedia . Em termos ext3, um data=journal garante que, se o sistema travar, cada arquivo estará em um estado que teve em algum momento antes do travamento (nem sempre é o estado mais recente devido ao armazenamento em buffer). A razão pela qual isso não acontece automaticamente é que o kernel reordena as gravações de disco para eficiência (isso pode fazer uma grande diferença). Isso é chamado de “diário físico” no artigo da Wikipedia. Os outros dois modos ( data=ordered e data=writeback ) são formas de "diário lógico" : eles são mais rápido, mas eles podem levar a arquivos corrompidos. A revista limita o risco de corrupção a alguns arquivos contendo lixo; O ext3 sempre usa um diário completo para metadados. Sem um diário para metadados, os metadados podem se perder, levando a uma grande corrupção do sistema de arquivos. Além disso, sem um diário, a recuperação após uma falha exige uma verificação completa da integridade do sistema de arquivos, enquanto que, com a recuperação de um diário, é necessário repetir algumas entradas no diário.

Note que mesmo com um journal, sistemas de arquivos unix típicos não garantem a consistência global do sistema de arquivos, somente a consistência por arquivo no máximo. Isto é, suponha que você grave no arquivo foo , então você escreve no arquivo bar , então o sistema trava. É possível que bar tenha o novo conteúdo, mas foo ainda tenha o conteúdo antigo. Para ter consistência completa, você precisa de um sistema de arquivos transacional .

    

Answer 2

I assumed that if I download something it should first be saved in the journal and if complete moved to FS.

Você quer dizer que o arquivo deve aparecer somente após ser fechado. Isso se parece com um comportamento opcional do Ext4, veja a opção de montagem chamada auto_da_alloc .

auto_da_alloc|noauto_da_alloc

Many broken applications don't use fsync() when noauto_da_alloc replacing existing files via patterns such as

fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new", "foo")

or worse yet

fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).

If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is commited. This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk.