Normalmente, os drivers de dispositivos de bloco informam o tamanho correto do dispositivo e é possível usar todos os blocos "disponíveis". Portanto, o sistema de arquivos sabe o quanto pode gravar nesse dispositivo anteriormente.
Mas em alguns casos especiais, como acontece com dispositivos dm-thinou dm-vdodispositivos, esta afirmação é falsa. Esse tipo de dispositivo de bloco pode retornar ENOSPCerro a qualquer momento, se seu armazenamento subjacente (sobre o qual o FS de nível superior nada sabe) ficar cheio.
Portanto, minha pergunta é: o que acontece nesse cenário: um sistema de arquivos EXT4 está montado r/w, no asyncmodo (que é o padrão), e está fazendo uma grande quantidade de gravações. O cache de disco (memória suja) também é envolvido e, no momento, há muitos dados a serem gravados se o usuário executar o synccomando.
Mas, de repente, o dispositivo de bloco subjacente desse sistema de arquivos EXT4 começa a recusar qualquer gravação devido a "não sobrar espaço". Qual será o comportamento do sistema de arquivos?
Ele imprimirá erros e entrará no r/omodo abortando todas as gravações e possivelmente causando perda de dados? Caso contrário, ele apenas esperará por espaço, repetindo periodicamente as gravações e recusando novas? Nesse caso, o que acontecerá com o enorme cache do disco, se outros processos tentarem alocar muita RAM? (No Linux, a memória suja é considerada Disponível, não é?).
Considerando o pior cenário, se o cache do disco estivesse ocupando a maior parte da RAM no momento do ENOSPCerro (porque o administrador configurouvm.dirty_ratiomuito alto), o kernel pode travar ou travar? Ou apenas fará com que todos os processos que desejam alocar memória esperem/travem? Finalmente, o comportamento difere entre os sistemas de arquivos?
Desde já, obrigado.
Quando o dispositivo de bloco compromete demais sua capacidade de dados disponível, como ao usar provisionamento thin, ou tem outros motivos para não poder aceitar mais gravações, como ter um snapshot cheio, ele precisa enviar uma mensagem para o que está gravando nele. ENOSPC não faria sentido neste contexto, então o erro escolhido geralmente é EIO (Erro de entrada/saída).
ATUALIZAÇÃO: na verdade, o LVM tem um comportamento configurável. Para LV provisionado Thin :
--errorwhenfull n(padrão): bloqueia por até (configurável) 60 segundos, conforme considerado pelo OP, depois erros. A menos que uma ação automática seja executada durante esses 60 anos, é provável que o resultado seja o mesmo que um erro imediato.Observe também que se o tempo limite estiver completamente desativado:
--errorwhenfull y: retorna imediatamente um erroSe o "usuário" for um sistema de arquivos, ele reagirá ao erro de E/S da mesma forma que se fosse causado por um erro de mídia real, possivelmente dependendo das opções de montagem (por exemplo, para ext4 as opções possíveis são
errors={continue|remount-ro|panic}). Não posso dizer com certeza o que acontece com os dados sujos ainda no cache quando uma das opções sem pânico é escolhida. Pode-se imaginar que ele foi deixado no cache ou será perdido, mas deve-se presumir que será perdido de qualquer maneira.Como este é um resultado grave, esse espaço em disco deve ser monitorado ativamente e, uma vez atingido um limite, deve haver liberação de dados ou mais espaço real adicionado para que o espaço supercomprometido nunca fique cheio. O mesmo acontece com os snapshots, especialmente o tipo não-thin-provisionado que utiliza mais espaço ao longo do tempo: deve ser removido quando não for mais necessário. Existem até opções para aumentar automaticamente o espaço de provisionamento dinâmico para emergências (quando a camada que fornece espaço para a camada de provisionamento dinâmico ainda pode fornecer mais).
outras referências:
Depende do sistema de arquivos (e possivelmente das opções de montagem) e do armazenamento subjacente.
Na maioria dos casos, uma falha na gravação em um dispositivo de bloco devido ao excesso de comprometimento do espaço será imediatamente propagada para o driver do sistema de arquivos como um erro de E/S. O LVM tem uma opção para atrasar isso (principalmente para que a funcionalidade de extensão automática tenha tempo de entrar em ação), mas está desabilitada por padrão. O QEMU tem uma opção que controla o comportamento disso com imagens de disco esparsas, mas por padrão ele propagará o erro para o sistema operacional convidado (também pode ser configurado para ignorar o erro ou pausar a VM). A maioria das outras coisas apenas lançará o erro imediatamente no driver do sistema de arquivos.
A partir daí, o que acontece depende do sistema de arquivos. Em quase todos os casos, o erro será propagado para o espaço do usuário, embora quase sempre seja EIO e não ENOSPC (ENOSPC significa que o sistema de arquivos está sem espaço, mas tecnicamente não é isso que está errado aqui, e o sistema de arquivos também geralmente não consegue determinar o que causou o erro de IO obtido da camada inferior, então normalmente não há como saber que é devido à falta de espaço da camada inferior). Por padrão, ext4 não fará nada além disso, embora dependendo das opções de montagem (e das coisas definidas por
tune2fs), ele poderá remontar somente leitura ou poderá desencadear um kernel panic. O BTRFS remontará somente leitura e, em algumas configurações de vários dispositivos, também poderá alternar para o modo degradado. Não tenho certeza sobre outros sistemas de arquivos (embora eu espere que o XFS remonte somente leitura neste caso).