Trata-se de um sistema de arquivos ext4 em um volume lógico gerenciado com LVM em uma criptografia LUKS em um RAID de hardware. O sistema operacional é um Ubuntu 22.04 LTS genérico.
Infelizmente, o RAID falhou recentemente e o sistema de arquivos foi remapeado somente para leitura naquele momento. Depois de interromper a gravação de todos os aplicativos nesse sistema de arquivos, o RAID poderá ser totalmente restaurado com alguma sorte. E, com ainda mais sorte, o sistema de arquivos ainda estará totalmente legível com os dados restaurados! E e2fscknem encontrou erros.
Então está tudo bem? Infelizmente não. Infelizmente, há uma grande quantidade (centenas de Megabytes) de dados não gravados ainda na memória e não sei como transferi-los para o disco. É por isso que ainda não reiniciei e é também por isso que não quero reiniciar, porque reparar todos os arquivos do banco de dados com esses dados ausentes será um trabalho importante. A presença dos dados não escritos pode ser facilmente verificada através de:
sync ; grep Dirty /proc/meminfo
que geralmente rende apenas alguns kilobytes, mas dá centenas de megabytes no meu caso. Infelizmente, não sei em que nível dos vários drivers do kernel os dados estão armazenados: cache do disco físico, um dos grupos de volumes ou o sistema de arquivos real.
Reparos tentados até agora
Minha primeira tentativa foi remontar o sistema de arquivos ainda somente leitura como leitura e gravação por meio de:
mount -o remount /dev/mapper/vg1-data
Infelizmente, isso gera a mensagem de erro:
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
No entanto, o volume real é de leitura e gravação, como pode ser verificado por:
cat /sys/block/dm-*/ro
que fornece o resultado 0para tudo sob o controle do mapeador de dispositivos, incluindo os volumes no topo do RAID. O mesmo se aplica ao sdpróprio dispositivo. Além disso:
dmsetup info vg1-data
relata o estado do volume como ACTIVE. Em vez disso, reportaria o estado como ACTIVE (READ-ONLY), se fosse somente leitura. Da mesma forma, lvsmostra atributos normais de -wi-ao----.
Uma grande pista, que a capacidade de leitura e gravação do sistema de arquivos NÃO é na verdade a origem do problema, está disponível via tune2fs -l. Isto imprime, entre muitas outras estatísticas, esta informação sobre o último erro no sistema de arquivos montado:
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
No momento desse erro, havia esta linha enigmática gravada no syslog:
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
Quando forço explicitamente o volume para o modo somente leitura por meio de:
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
então, novas mounttentativas NÃO atualizam mais o carimbo de data/hora "Hora do último erro", mas produzem a mesma mensagem de erro (e agora obviamente correta). Depois de usar dmsetupnovamente para fazer o volume ler e gravar, novas mounttentativas atualizarão o carimbo de data e hora do último erro novamente e também gravarão no syslog novamente.
Em outra postagem de serverfault, encontrei a dica para definir os volumes do mapeador de disco como somente leitura e depois voltar para leitura-gravação, mas isso também não funcionou:Software Linux RAID 1 - o sistema de arquivos raiz torna-se somente leitura após uma falha em um disco
cryptsetup reloadtambém não conseguiu nada.