O disco VMDK tornou-se somente leitura e como evitar esses casos em máquinas rhel

O disco VMDK tornou-se somente leitura e como evitar esses casos em máquinas rhel

temos cluster Kafka com RHEL 7.6, todos Kafka são máquinas VM

em uma das máquinas Kafka, notamos que o disco sdb tornou-se somente leitura (quando sda é o disco do sistema operacional)

 mount | grep sdb
/dev/sdb on /var/data/kafka_DB type ext4 (ro,noatime,data=ordered)

do meu ponto de vista, é um pouco estranho que o DISK VMDK tenha se tornado somente leitura (porque não é um disco mecânico)

do red-hat eu encontro o seguinte

https://access.redhat.com/solutions/1273213

https://access.redhat.com/solutions/35329

mas não tenho certeza se as sugestões acima do redhat são a resposta porque o disco se tornou somente leitura

alguma outra opinião?

nos logs do kernel, podemos ver:

[1642397.157193] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157200] sd 0:0:2:0: [sdb] CDB: Write(10) 2a 00 12 c0 01 00 00 00 08 00
[1642397.157214] blk_update_request: I/O error, dev sdb, sector 314573056
[1642397.157242] Buffer I/O error on dev sdb, logical block 39321632, lost async page write
[1642397.157806] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157808] sd 0:0:2:0: [sdb] CDB: Read(10) 28 00 12 c4 03 58 00 00 08 00
[1642397.157810] blk_update_request: I/O error, dev sdb, sector 314835800
[1642397.157843] sd 0:0:2:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[1642397.157845] sd 0:0:2:0: [sdb] CDB: Read(10) 28 00 12 c4 0b a0 00 00 08 00
[1642397.157847] blk_update_request: I/O error, dev sdb, sector 314837920
[1642578.412306] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c147c189880
[1642924.513605] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c16a4f01880
[1643034.935334] JBD2: Detected IO errors while flushing file data on sdb-8
[1643035.002651] EXT4-fs error (device sdb): __ext4_new_inode:989: comm pool-6-thread-1: failed to insert inode 8126474: doubly allocated?
[1643036.753397] Aborting journal on device sdb-8.
[1643036.754490] EXT4-fs error (device sdb): ext4_journal_check_start:56: Detected aborted journal
[1643036.754496] EXT4-fs (sdb): Remounting filesystem read-only
[1643226.599854] sd 0:0:2:0: [sdb] task abort on host 0, ffff8c14a4bd3800
[1694249.598258] EXT4-fs (sdb): error count since last fsck: 17
[1694249.598269] EXT4-fs (sdb): initial error at time 1629844995: ext4_find_entry:1312: inode 656236
[1694249.598273] EXT4-fs (sdb): last error at time 1630003886: ext4_journal_check_start:56
[1780756.527074] EXT4-fs (sdb): error count since last fsck: 17
[1780756.527086] EXT4-fs (sdb): initial error at time 1629844995: ext4_find_entry:1312: inode 656236
[1780756.527088] EXT4-fs (sdb): last error at time 1630003886: ext4_journal_check_start:56

o que pensamos fazer é atualizar o /sys/block/nome base /dev/sdb/device/timeout

por exemplo, o valor padrão é 180

e estamos pensando em definir o novo valor de atualização como

echo 3600 > /sys/block/`basename /dev/sda`/device/timeout

queremos saber se estamos na direção certa com a solução acima?

informação relacionada