Problema READ-ONLY no HD btrfs

Estou com 1 SSD de 500gb e 1 HD de 1tb, o ssd esta montado como a / e HD de 1Tb em /home.

A um tempo estou tendo esse problema, estou usando ele normalmente, quando do nada o HD de 1Tb não me deixa escrever nada, e fala que esta em modo read-only:

Até mesmo com o root!

Já o SSD de 500, funciona normalmente:
image


Ambos estão formatados no sistema BTRFS
Estou usando o Zorin OS 16
Kernel x86_64 Linux 5.13.0-41-generic

Meu /etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb1 during installation
UUID=d952e877-f36b-4e79-8061-923331d5f0c4 /               btrfs   defaults,[email protected] 0       1
# /home was on /dev/sda1 during installation
UUID=32b48597-2b8f-4aa8-9229-2d5806bfbf9e /home           btrfs   defaults,[email protected] 0       2
# swap was on /dev/sdb5 during installation
UUID=d5b57a27-1a9f-48d7-83df-f2ceff4fc6f6 none            swap    sw              0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

Momento no /var/log/kern.log em que acho q o disco travou no read-only:

...some logs before...
May 17 09:20:26 jarvis kernel: [ 4749.947077] ata1: soft resetting link
May 17 09:20:26 jarvis kernel: [ 4750.121193] ata1.00: configured for UDMA/33
May 17 09:20:26 jarvis kernel: [ 4750.124457] ata1.01: configured for UDMA/133
May 17 09:20:26 jarvis kernel: [ 4750.124502] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
May 17 09:20:26 jarvis kernel: [ 4750.124507] sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current] 
May 17 09:20:26 jarvis kernel: [ 4750.124511] sd 0:0:0:0: [sda] tag#0 Add. Sense: Scsi parity error
May 17 09:20:26 jarvis kernel: [ 4750.124515] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 55 21 e1 80 00 07 00 00
May 17 09:20:26 jarvis kernel: [ 4750.124518] blk_update_request: I/O error, dev sda, sector 1428283776 op 0x1:(WRITE) flags 0x5800 phys_seg 117 prio class 0
May 17 09:20:26 jarvis kernel: [ 4750.124686] ata1: EH complete
May 17 09:20:26 jarvis kernel: [ 4750.129788] BTRFS: error (device sda1) in btrfs_run_delayed_refs:2163: errno=-5 IO failure
May 17 09:20:26 jarvis kernel: [ 4750.129794] BTRFS info (device sda1): forced readonly
May 17 09:20:26 jarvis kernel: [ 4750.131725] BTRFS warning (device sda1): Skipping commit of aborted transaction.
May 17 09:20:26 jarvis kernel: [ 4750.131768] BTRFS: error (device sda1) in btrfs_sync_log:3347: errno=-5 IO failure
May 17 09:20:26 jarvis kernel: [ 4750.171570] BTRFS warning (device sda1): csum hole found for disk bytenr range [223342219264, 223342223360)
May 17 09:20:26 jarvis kernel: [ 4750.171580] BTRFS warning (device sda1): csum hole found for disk bytenr range [223342223360, 223342227456)
May 17 09:20:26 jarvis kernel: [ 4750.171584] BTRFS warning (device sda1): csum hole found for disk bytenr range [223342227456, 223342231552)
May 17 09:20:26 jarvis kernel: [ 4750.171587] BTRFS warning (device sda1): csum hole found for disk bytenr range [223342231552, 223342235648)
May 17 09:20:26 jarvis kernel: [ 4750.187089] BTRFS warning (device sda1): csum failed root 256 ino 4366277 off 0 csum 0x38fd4371 expected csum 0x00000000 mirror 1
May 17 09:20:26 jarvis kernel: [ 4750.187140] BTRFS warning (device sda1): csum hole found for disk bytenr range [223342219264, 223342223360)
May 17 09:20:26 jarvis kernel: [ 4750.188452] BTRFS warning (device sda1): csum failed root 256 ino 4366277 off 0 csum 0x38fd4371 expected csum 0x00000000 mirror 1
May 17 09:20:32 jarvis kernel: [ 4756.205466] BTRFS warning (device sda1): csum hole found for disk bytenr range [445233070080, 445233074176)
some logs after...

Já cheguei e rodar o comando btrfs check sosinho e com o --repair dando boot em um pendrive externo com o Kali Linux, mas n parece ter resolvido.

Alguma ideia de como resolver?

Cara, por experiência própria, o melhor a fazer quando dá erro tenebroso no btrfs é salvar tudo que tem nele e criar o sistema de arquivos novamente (ou em antigo jargão: formata ele).

Quando o btrfs se perde, geralmente acontece esse caso onde ele fica com acesso somente leitura. É bom porque vc não perde dados e evita de garavar algo em um sistema defeituoso.

Depois de ter salvo os dados, vc pode tentar esses comandos perigosos de recuperação do sistema de arquivos se, e somente se vc quiser aprender mais.

Aliás, dois problemas que eu já tive no btrfs foi 1) algo parecido com o seu, que eu tentei recuperar e estragou de vez, e 2) quando enche o disco e vc não consegue deletar arquivos pra liberar espaço!

É um ótimo sistema de arquivos.

2 curtidas

@Deleterium so para saber, você sabe que o BTRFS ainda esta em desenvolvimento.
Você estava usando ele com tecnologias que ainda estão sendo implementadas e em faze de teste?

1 curtida

No meu uso, com snapshots, ele já me salvou da reinstalação diversas vezes nesses últimos dois anos. Foram umas 5 a 10 vezes, que por causa de erros meus, consegui recuperar a um estado anterior. Já das vezes que tive problemas com ele, foi uma vez há uns 5 anos, e uma vez nesses últimos dois anos que o disco ficou cheio por conta dos logs e tive que fazer uma ginástica pra resolver. Em questão de estabilidade está muito bom (no meu ponto de vista) para esse uso mais básico. Se o usuário quiser usar as funções de RAID, aí sim é bom pesquisar melhor quais dessas características ainda estão instáveis ou não implementadas completamente.

1 curtida

Você viu a pagina de wiki do Btrfs dizendo para usar as versões mais recentes do kernel Linux para o Btrfs.
Eles não recomenda usar versões antigas do Linux veja:

A base de código Btrfs é estável. No entanto, novos recursos ainda estão em desenvolvimento. Todo esforço é feito para garantir que ele permaneça estável e rápido em cada commit. Esse ritmo rápido de desenvolvimento significa que o sistema de arquivos melhora *notavelmente* a cada nova versão do Linux, por isso é *altamente* recomendável que os usuários executem o kernel mais moderno possível.

O btrfs-progs esta na versão v5.17 (abril de 2022)

Outra coisa que eles diz é:

Atenção: Como o Btrfs está em forte desenvolvimento, especialmente o comando btrfs check é altamente recomendado criar um backup e consulte a Documentação do Btrfsck antes de executar btrfs check com o --repair.

Não tente reparar o BTRFS com o “btrfs check --repair” diz o arch que é uma ferramenta imatura.
O BTRFS tem um recurso de se autorreparar durante a montagem, é melhor desmontar e montar se não for corrigido automaticamente, paciência.

https://wiki.archlinux.org/title/Btrfs_(Português)#Verificação_do_Btrfs
https://btrfs.wiki.kernel.org/index.php/Main_Page

2 curtidas