loopback do linux remount-ro, ext4_da_writepages: jbd2_start: 8192 páginas, ino 130135; err-30

Question

Eu tenho um dispositivo de loopback formatado com ext4 (^ has_journal, disablednalnalling).

Durante o desligamento, quando tento forçar a remontagem como somente leitura, o sistema de arquivos montado em loopback. echo "u" > / proc / sysrq-trigger

Eu vejo esses erros ext4 após remodificar ext4_da_writepages: jbd2_start: 8192 páginas, ino 130135; err-30

(err 30 é -EROFS, erro devido a write-back para o sistema de arquivos somente leitura). Como parte do remount, vejo que o linux chama invalidate_bdev (), o que eu acho que não deveria deixar nenhum writeback ocorrer. Não tenho certeza porque vejo esses erros.

Eu não vejo nenhum erro ao formatar o dispositivo de loopback como vfat.

Qualquer ajuda é apreciada.

obrigado

    

Answer 1

É porque o disparador sysrq é apenas de emergência e não tem muita (qualquer) inteligência.

Olhando no código-fonte do kernel, em fs / super.c: do_emergency_remount (), parece que ele irá remontar os sistemas de arquivos readonly pela sua ordem na lista (que é a mesma que você vê quando faz "cat / proc / mounts" por exemplo). Isso é lamentável, pois provavelmente remontará readonly seu sistema de arquivos pai primeiro, e então ele tentará desmontar o filesytem de loopback, o que acionaria a gravação (de superbloco e quaisquer dados / metadados modificados restantes) no sistema de arquivos pai, que já é somente leitura, e, portanto, falha com -EROFS.

A solução é usar ferramentas comuns para desmontar e remontar o R / O em vez do sysrq-trigger, por exemplo, usando:

umount -a

(que desmonta tudo o que pode e remonta o R / O do rootfs)

Ou executando manualmente na ordem correta:

mount -oremount,ro /dev/xxx

Se você precisa usar / proc / sysrq-trigger (por quê?), então você pode tentar fazer o kernel ver a ordenação que você quer (se é que isso é possível, eu não olhei tão fundo) ou modificar o kernel para fazer a ordenação do último para o primeiro (em vez do primeiro para o último). Talvez não seja perfeito (talvez para algumas configurações mais complexas seria errado também), mas seria na maioria (se não todos) casos melhor do que a solução atual. Eu diria que ele pode até entrar no kernel da linha principal se você tentar empurrá-lo, já que caminhar nessa lista em particular nesse local em particular não é crítico para o desempenho, então erros de cache, etc., de andar para trás na lista não são um problema. >

BTW, você não vê os erros do VFAT (se ele não foi modificado ultimamente), porque o VFAT (devido à sua simplicidade) não precisa gravar o superbloco modificado no umount de volta ao disco.