As edições de arquivos no Linux são salvas diretamente no disco?

Question

Eu costumava pensar que as alterações de arquivo são salvas diretamente no disco, ou seja, assim que eu fecho o arquivo e decido clicar em / save salvar. No entanto, em uma conversa recente, um amigo meu me disse que geralmente não é verdade; o sistema operacional (especificamente estávamos falando sobre sistemas Linux) mantém as mudanças na memória e tem um daemon que realmente grava o conteúdo da memória no disco.

Ele até deu o exemplo de flash drives externos: eles são montados no sistema (copiados na memória) e, às vezes, a perda de dados acontece porque o daemon ainda não salvou o conteúdo na memória flash; é por isso que desmontamos pen drives.

Eu não tenho conhecimento sobre o funcionamento dos sistemas operacionais e, portanto, não tenho absolutamente nenhuma idéia se isso é verdade e em quais circunstâncias. Minha principal questão é: isso acontece como descrito em sistemas Linux / Unix (e talvez outros sistemas operacionais)? Por exemplo, isso significa que se eu desligar o computador imediatamente depois de editar e salvar um arquivo, minhas alterações provavelmente serão perdidas? Talvez isso dependa do tipo de disco - discos rígidos tradicionais versus discos de estado sólido?

A questão refere-se especificamente a sistemas de arquivos que possuem um disco para armazenar as informações, mesmo que qualquer esclarecimento ou comparação seja bem recebido.

    

Answer 1

if I turn off the computer immediately after I edit and save a file, my changes will be most likely lost?

Eles podem ser. Eu não diria "muito provavelmente", mas a probabilidade depende de muitas coisas.

Uma maneira fácil de aumentar o desempenho das gravações de arquivos é que o sistema operacional armazena apenas os dados em cache, informa a aplicação pela qual a gravação passou e depois faz a gravação mais tarde. Isso é especialmente útil se houver outra atividade de disco acontecendo ao mesmo tempo: o SO pode priorizar leituras e fazer as gravações posteriormente. Ele também pode remover completamente a necessidade de uma gravação real, por exemplo, no caso em que um arquivo temporário é removido rapidamente depois.

O problema de armazenamento em cache é mais pronunciado se o armazenamento for lento. Copiar arquivos de um SSD rápido para um stick USB lento provavelmente envolverá muito cache de gravação, já que o pendrive USB não consegue acompanhar. Mas o comando cp retorna mais rápido, então você pode continuar trabalhando, possivelmente até editando os arquivos que acabaram de ser copiados.

Claro que o cache tem a desvantagem que você nota, alguns dados podem ser perdidos antes de serem salvos. O usuário será ofendido se o editor disser que a gravação foi bem-sucedida, mas o arquivo não estava no disco. É por isso que há a fsync() chamada de sistema , que deve retornar somente depois o arquivo atingiu o disco. Seu editor pode usar isso para garantir que os dados estejam bem antes de relatar ao usuário que a gravação foi bem-sucedida.

Eu disse, "supostamente deveria", já que a própria unidade poderia dizer as mesmas mentiras para o sistema operacional e dizer que a gravação está completa, enquanto o arquivo realmente existe apenas em um cache de gravação volátil dentro da unidade. Dependendo da unidade, pode não haver maneira de contornar isso.

Além de fsync() , há também as chamadas de sistema sync() e syncfs() que solicitam ao sistema que todas as gravações em todo o sistema ou todas as gravações em um determinado sistema de arquivos atinjam o disco. O utilitário sync pode ser usado para chamá-los.

Depois, há também o O_DIRECT sinalizador para open() , que é deveria "tentar minimizar os efeitos de cache do I / O para e deste arquivo." A remoção do cache reduz o desempenho, portanto, é usado principalmente por aplicativos (bancos de dados) que fazem seu próprio armazenamento em cache e desejam controlá-lo. ( O_DIRECT não está isento de problemas, os comentários sobre isso na página man são um pouco divertidos.)

O que acontece em uma falta de energia também depende do sistema de arquivos. Não são apenas os dados do arquivo com os quais você deve se preocupar, mas os metadados do sistema de arquivos. Ter os dados do arquivo no disco não é muito útil se você não conseguir encontrá-los. Apenas estender um arquivo para um tamanho maior exigirá alocação de novos blocos de dados e eles precisam ser marcados em algum lugar.

Como um sistema de arquivos lida com mudanças de metadados e a ordenação entre metadados e gravações de dados varia muito. Por exemplo, com ext4 , se você definir o sinalizador de montagem data=journal , todas as gravações - até mesmo as gravações de dados - passarão pelo diário e deverão ser bastante seguras. Isso também significa que eles são escritos duas vezes, então o desempenho cai. As opções padrão tentam ordenar as gravações para que os dados estejam no disco antes que os metadados sejam atualizados. Outras opções ou outros sistemas de arquivos podem ser melhores ou piores; Eu nem vou tentar um estudo abrangente.

Na prática, em um sistema com carga leve, o arquivo deve atingir o disco dentro de alguns segundos. Se você estiver lidando com armazenamento removível, desmonte o sistema de arquivos antes de puxar a mídia para certificar-se de que os dados foram realmente enviados para a unidade, e não há mais nenhuma atividade. (Ou faça com que o seu ambiente de GUI faça isso por você.)

    

Answer 2

Existe uma maneira extremamente simples de provar que não é verdade que as edições de arquivos são sempre salvas diretamente no disco, ou seja, o fato de existirem sistemas de arquivos que > não são apoiados por um disco em primeiro lugar . Se um sistema de arquivos não tiver um disco em primeiro lugar, então não é possível gravar as alterações no disco, sempre .

Alguns exemplos são:

• tmpfs , um sistema de arquivos que só existe na RAM (ou mais precisamente, no cache de buffer)
• ramfs , um sistema de arquivos que existe apenas na RAM
• qualquer sistema de arquivos de rede (NFS, CIFS / SMB, AFS, AFP,…)
• qualquer sistema de arquivos virtual ( sysfs , procfs , devfs , shmfs ,…)

Mas mesmo para sistemas de arquivos com suporte a disco, isso geralmente não é verdade. A página Como corromper um banco de dados SQLite tem um capítulo chamado A falta de sincronização que descreve muitas maneiras diferentes pelas quais as gravações (neste caso, se comprometem com um banco de dados SQLite) podem falhar ao chegar no disco. O SQLite também tem um white paper explicando os vários obstáculos que você precisa para garantir Commit Atomic In SQLite . (Note que o Atomic Write é muito mais difícil do que apenas o Write , mas é claro que gravar em disco é um sub-problema da escrita atômica, e você pode aprender muito sobre esse problema, também, a partir deste artigo.) este documento tem uma seção sobre As coisas que podem dar errado , que inclui uma subseção sobre Incomplete Flushes Disk que dar alguns exemplos de meandros sutis que possam impedir que uma gravação chegue ao disco (como o controlador de HDD informando que gravou no disco quando não existe) - sim, existem fabricantes de HDD que fazem isso, e pode até ser legal de acordo com as especificações do ATA, porque é formulado de maneira ambígua a esse respeito).

    

Answer 3

É verdade que a maioria dos sistemas operacionais, incluindo Unix, Linux e Windows, usa um cache de gravação para acelerar as operações. Isso significa que desligar um computador sem desligá-lo é uma má ideia e pode levar à perda de dados. O mesmo acontece se você remover um armazenamento USB antes de estar pronto para ser removido.

A maioria dos sistemas também oferece a opção de tornar as gravações síncronas. Isso significa que os dados estarão no disco antes que um aplicativo receba uma confirmação de sucesso, com o custo de ser mais lento.

Em suma, há um motivo pelo qual você deve desligar seu computador adequadamente e preparar adequadamente o armazenamento USB para remoção.

    

Answer 4

1. Armazenamento baseado em Flash

Does it depend upon the disk type (traditional hard drives vs. solid-state disks) or any other variable that I might not be aware of? Does it happen (if it does) only in Linux or is this present in other OSes?

Quando você tem uma opção, não deve permitir que o armazenamento baseado em flash perca energia sem um desligamento normal.

Em armazenamento de baixo custo, como cartões SD, você pode esperar perder blocos de apagamento inteiros (várias vezes maiores que 4KB), perdendo dados que podem pertencer a arquivos diferentes ou a estruturas essenciais do sistema de arquivos.

Alguns SSDs caros podem alegar oferecer melhores garantias em caso de falha de energia. No entanto, testes de terceiros sugerem que muitos SSDs caros não conseguem fazê-lo. A camada que remapeia blocos para "wear leveling" é complexa e proprietária. Possíveis falhas incluem a perda de todos os dados na unidade.

Applying our testing framework, we test 17 commodity SSDs from six different vendors using more than three thousand fault injection cycles in total. Our experimental results reveal that 14 of the 17 tested SSD devices exhibit surprising failure behaviors under power faults, including bit corruption, shorn writes, unserializable writes, metadata corruption, and total device failure.

2017: link

2013: link

2. Fiação de discos rígidos

Os HDDs de fiação têm características diferentes. Por segurança e simplicidade, eu recomendo supor que eles têm a mesma incerteza prática do armazenamento baseado em flash.

A menos que você tenha evidências específicas, o que você claramente não tem. Eu não tenho dados comparativos para HDDs giratórios.

Um HDD pode deixar um setor incompletamente escrito com uma soma de verificação ruim, o que nos dará uma boa falha de leitura mais tarde. De um modo geral, esse modo de falha dos HDDs é inteiramente esperado; sistemas de arquivos nativos do Linux são projetados com isso em mente. Eles visam preservar o contrato de fsync() em face deste tipo de falha de perda de energia. (Nós realmente gostaríamos de ver isso garantido em SSDs).

No entanto, não tenho certeza se os sistemas de arquivos Linux conseguem isso em todos os casos, ou se isso é possível.

A próxima inicialização após esse tipo de falha pode exigir um reparo do sistema de arquivos. Sendo este o Linux, é possível que o reparo do sistema de arquivos faça algumas perguntas que você não entende, onde você pode apenas pressionar Y e esperar que ele seja resolvido.

2.1 Se você não sabe o que o contrato fsync () é

O contrato fsync () é uma fonte de boas e más notícias. Você deve entender as boas novas primeiro.

Boas notícias: fsync() está bem documentado como a maneira correta de gravar dados de arquivos, por exemplo quando você apertar "salvar". E é amplamente entendido que, e. editores de texto devem substituir os arquivos existentes atomicamente usando rename() . Isso serve para garantir que você sempre mantenha o arquivo antigo ou obtenha o novo arquivo (que foi fsync() ed antes da renomeação). Você não quer ficar com uma versão semi-escrita do novo arquivo.

Más notícias: por muitos anos, chamar o fsync () no sistema de arquivos Linux mais popular pode deixar todo o sistema pendurado por dezenas de segundos. Como os aplicativos não podem fazer nada sobre isso, era muito comum usar de forma otimista rename () sem fsync (), que parecia ser relativamente confiável nesse sistema de arquivos.

Portanto, existem aplicativos que não usam fsync () corretamente.

A próxima versão deste sistema de arquivos geralmente evita o travamento do fsync () - ao mesmo tempo em que ele começa a confiar no uso correto do fsync ().

Isso tudo é muito ruim. Entender essa história provavelmente não é ajudado pelo tom de desprezo e invectiva que foi usado por muitos dos desenvolvedores de kernel conflitantes.

A resolução atual é que o atual sistema de arquivos Linux mais popular suporta o padrão rename () sem requerer que o fsync () implemente "compatibilidade bug-para-bug" com a versão anterior. Isso pode ser desativado com a opção de montagem noauto_da_alloc .

Esta não é uma proteção completa. Basicamente, ele libera o IO pendente no horário rename (), mas não aguarda a conclusão do IO antes de renomear. Isto é muito melhor que por exemplo uma janela de perigo de 60 segundos! Veja também a resposta para Quais sistemas de arquivos requerem fsync () para segurança de travamento ao substituir um arquivo existente com renomear ()?

Alguns sistemas de arquivos menos populares não fornecem proteção. O XFS se recusa a fazer isso. E o UBIFS também não implementou, aparentemente pode ser aceito, mas precisa de muito trabalhar para tornar isso possível. A mesma página aponta que o UBIFS tem vários outros problemas "TODO" para integridade de dados, incluindo perda de energia. O UBIFS é um sistema de arquivos usado diretamente no armazenamento flash. Eu imagino que algumas das dificuldades mencionadas pelo UBIFS com o armazenamento em flash podem ser relevantes para os erros do SSD.

    

Answer 5

Em um sistema com carga leve, o kernel permitirá que os dados de arquivo recém-gravados permaneçam no cache de páginas por 30 segundos depois de um write() , antes de liberá-lo no disco, para otimizar o caso onde ele é excluído ou modificado novamente em breve.

O dirty_expire_centisecs do Linux é padronizado para 3000 (30 segundos) e controla quanto tempo até que os dados recém-gravados "expirem". (Veja link ).

Veja o link para ver mais tunables relacionados, e pesquise muito mais no google. (por exemplo, google on dirty_writeback_centisecs ).

O padrão do Linux para /proc/sys/vm/dirty_writeback_centisecs é 500 (5 segundos) , e o PowerTop recomenda configurá-lo para 1500 (15 segundos) para reduzir o consumo de energia.

Write-back atrasado também dá tempo para o kernel ver o tamanho de um arquivo, antes de começar a escrevê-lo em disco. Sistemas de arquivos com alocação atrasada (como o XFS e provavelmente outros atualmente) nem mesmo escolhem onde no disco colocar os dados de um arquivo recém-escrito até que seja necessário, separadamente da alocação de espaço para o próprio inode. Isso reduz a fragmentação, permitindo que eles evitem colocar o início de um arquivo grande em um intervalo de 1 meg entre outros arquivos, por exemplo.

Se muitos dados estiverem sendo gravados, o writeback para o disco pode ser acionado por um limite para a quantidade de dados sujos (ainda não sincronizados em disco) que podem estar no pagecache.

Se você não estiver fazendo muito mais, sua luz de atividade do disco rígido não funcionará por 5 (ou 15) segundos depois de salvar em um arquivo pequeno.

Se o seu editor usou fsync() depois de escrever o arquivo, o kernel irá gravá-lo no disco sem atraso. (E fsync não retornará até que os dados tenham sido enviados ao disco).

O cache de gravação dentro do disco também pode ser uma coisa, mas os discos normalmente tentam submeter seu cache de gravação ao armazenamento permanente o mais rápido possível, diferentemente dos algoritmos de cache de página do Linux. Os caches de gravação de disco são mais de um buffer de armazenamento para absorver pequenos disparos de gravações, mas também para atrasar gravações em favor de leituras, e dar a sala de firmware de discos para otimizar um padrão de busca (por exemplo, fazer duas gravações ou leituras próximas , em seguida, procurando longe, em seguida, buscando de volta.)

Em um disco rotativo (magnético), você pode ver alguns atrasos de busca de 7 a 10 ms cada, antes que os dados de um comando de gravação SATA estejam realmente livres do desligamento, se houver leituras / gravações pendentes antes de sua gravação . (Algumas outras respostas sobre essa questão entram em mais detalhes sobre os caches de gravação de disco e escrevem as barreiras que os fóruns dedicados podem usar para evitar a corrupção.)