Problema READ-ONLY no HD btrfs

mateusfg7 · Maio 17, 2022, 12:59pm

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:

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,subvol=@ 0       1
# /home was on /dev/sda1 during installation
UUID=32b48597-2b8f-4aa8-9229-2d5806bfbf9e /home           btrfs   defaults,subvol=@home 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?

Deleterium · Maio 19, 2022, 12:40am

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.

aguamole · Maio 19, 2022, 3:45pm

@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?

Deleterium · Maio 19, 2022, 4:11pm

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.

aguamole · Maio 19, 2022, 4:32pm

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

mateusfg7 · Agosto 8, 2022, 2:06pm

EDIT:

Ja formatei o disco com o sistema Arch GUI, no mesmo esquema de partições, SSD no / e o suposto HDD no /home com btrfs.

o problema persiste mesmo depois de formatado.

rubenscontato · Agosto 9, 2022, 7:21pm

Testa teu HD/SSD com o programa gsmartcontrol.

No GSmartContro:

1 - Na tela que abrir dê 2 cliques no HD/SSD que quer testar.

2 - Vá na aba Self-Tests.

3 - Em Test type: escolha a duração com as opções: Short, Extended, Conveyance.

4 - Clique em: Executar

romulopb · Agosto 9, 2022, 8:09pm

Mesmo que o teste indicado pelo @rubenscontato passe e dê ok, se eu fosse você eu observaria todas as semanas esse disco no gnome-disk ou qualquer outro programa que mostra dados SMART, verificando os status, alguns HDs vão dando sinais e piorando até morrer de vez.

Se esse for o caso, dai só comprando outro mesmo, você até pode tentar dar uma sobrevida para ele, mas geralmente não tem como usar de forma segura sem outro HDD saudável “dando uma mão” para ele via RAID.