[Risolto] Problemi con secondo disco btrfs

[GjMan78]

Sto incontrando un fastidioso problema con un disco formattato con btrfs.

Ho montato sul mio Macbook un secondo disco SSD al posto del masterizzatore utilizzando un caddy.
Inizialmente ha funzionato senza intoppi ma oggi mi sono accorto che se provo a scrivere qualcosa (anche di poco conto, tipo file vuoti) il disco va in read-only.

I dati smart sono Ok, come ci si aspetterebbe da un disco che ha 10 ore di lavoro.

Codice: Seleziona tutto

lsblk -o name,uuid,size,fstype,mountpoints /dev/sdb
NAME   UUID                                   SIZE FSTYPE MOUNTPOINTS
sdb                                         476,9G        
├─sdb1 DB3A-C4ED                              500M vfat   
└─sdb2 bc60eb6c-9da5-490b-a6ed-d2dc907f6f10 429,7G btrfs  /media/Dati

il comando btrfs check restituisce una serie lunghissima di questo

Codice: Seleziona tutto

bad tree block 30523392, bytenr mismatch, want=30523392, have=0
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
bad tree block 30523392, bytenr mismatch, want=30523392, have=0
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
bad tree block 30523392, bytenr mismatch, want=30523392, have=0
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
bad tree block 30523392, bytenr mismatch, want=30523392, have=0
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4

Ho già tentato a forzare la riparazione ma senza esito.

Mi chiedo se sia un problema hardware (magari è il caddy difettoso...) oppure se è un problema del filesystem.

@emanuc Se passi da queste parti potresti darmi la tua opinione?

Grazie a tutti!

[kessler]

Io voto per il caddy difettoso. Anni fa ho avuto un problema identico su un microserver HP in cui avevo montato un SSD tramite caddy. Dava messaggi di errore a gogo, però non avevo Btrfs ma ext4 su Lvm.

Comunque fai la prova: collega termporaneamente il disco al PC senza caddy di mezzo e controlla il journal. Se non escono più errori, sicuramente è il caddy.

[emanuc]

bad tree block 30523392, bytenr mismatch, want=30523392, have=0

Questo sembra un problema che ho visto spesso e la causa è del controller/firmware on altro che mente sulle scritture al filesystem quando i dati sono ancora in memoria.

checksum verify failed on 30523392 wanted 0x00000000 found 0xb6bde3e4

Questo idem anche se a volte questo genere di problema è associato alla ram/cpu..., sembra un bitflip
Si, direi un problema hardware e il filesystem sta facendo il suo lavoro per cui è progettato.

[GjMan78]

Grazie ad entrambi del passaggio.

Domattina provvedo a fare alcune prove escludendo il caddy e vediamo come va.

[GjMan78]

Mi sa che il problema risiede proprio nel disco e non nel caddy.

Nel caddy ho messo un hard disk meccanico e funziona a dovere, il disco SSD btrfs l'ho collegato con un box usb e presenta lo stesso identico difetto.
Se mi limito a leggere funziona, se scrivo nuovi file o ne cancello alcuni passa in modalità read-only.

dmesg

Codice: Seleziona tutto

[  739.797203]  sdc: sdc1 sdc2
[  739.797425] sd 6:0:0:0: [sdc] Attached SCSI disk
[  796.995758] BTRFS: device label Dati devid 1 transid 658 /dev/sdc2 scanned by pool-udisksd (35142)
[  796.997900] BTRFS info (device sdc2): first mount of filesystem bc60eb6c-9da5-490b-a6ed-d2dc907f6f10
[  796.997916] BTRFS info (device sdc2): using crc32c (crc32c-intel) checksum algorithm
[  796.997926] BTRFS info (device sdc2): use zstd compression, level 3
[  796.997929] BTRFS info (device sdc2): using free space tree
[  903.972066] BTRFS error (device sdc2): bad tree block start, mirror 1 want 30523392 have 0
[  903.972650] BTRFS error (device sdc2): bad tree block start, mirror 2 want 30523392 have 0
[  903.972672] BTRFS error (device sdc2: state A): Transaction aborted (error -5)
[  903.972675] BTRFS: error (device sdc2: state A) in __btrfs_free_extent:3243: errno=-5 IO failure
[  903.972679] BTRFS info (device sdc2: state EA): forced readonly
[  903.972680] BTRFS error (device sdc2: state EA): failed to run delayed ref for logical 256442368 num_bytes 16384 type 176 action 2 ref_mod 1: -5
[  903.972684] BTRFS: error (device sdc2: state EA) in btrfs_run_delayed_refs:2248: errno=-5 IO failure

journalctl

Codice: Seleziona tutto

gen 16 18:06:57 macbookpro kernel: BTRFS error (device sdc2): bad tree block start, mirror 1 want 30523392 have 0
gen 16 18:06:57 macbookpro kernel: BTRFS error (device sdc2): bad tree block start, mirror 2 want 30523392 have 0
gen 16 18:06:57 macbookpro kernel: BTRFS error (device sdc2: state A): Transaction aborted (error -5)
gen 16 18:06:57 macbookpro kernel: BTRFS: error (device sdc2: state A) in __btrfs_free_extent:3243: errno=-5 IO failure
gen 16 18:06:57 macbookpro kernel: BTRFS error (device sdc2: state EA): failed to run delayed ref for logical 256442368 num_bytes 16384 type>
gen 16 18:06:57 macbookpro kernel: BTRFS: error (device sdc2: state EA) in btrfs_run_delayed_refs:2248: errno=-5 IO failure

CORREGGO la deduzione precedente.

Con il nuovo SSD ancora collegato nel box USB ho ricreato la tabella delle partizioni e riformattato con btrfs.
Ho scritto e cancellato molti GB di dati senza problemi, nessun errore riscontrato.

Montato nuovamente nel caddy ha ricominciato a dare problemi. Formattato nuovamente il disco, questa volta con ext4 e ora sembra filare tutto liscio.

Possibile che l'adattatore influisca con le operazioni del filesystem btrfs? Giusto per completezza il caddy è questo https://www.ebay.it/itm/313892478572

[emanuc]

Montato nuovamente nel caddy ha ricominciato a dare problemi. Formattato nuovamente il disco, questa volta con ext4 e ora sembra filare tutto liscio.

Possibile che l'adattatore influisca con le operazioni del filesystem btrfs? Giusto per completezza il caddy è questo https://www.ebay.it/itm/313892478572

Ricordati che Btrfs è un filesystem con checksumming sui dati.
Sicuramente su ext4 ti funziona perché non ha nessun controllo d'integrità sui dati e quindi potrebbe man mano corrompere i file silenziosamente.
Come puoi vedere dai log, da quel che posso capire sembra un problema di un interruzione della transazione:

[ 903.972675] BTRFS: error (device sdc2: state A) in __btrfs_free_extent errno=-5 IO failure
[ 903.972679] BTRFS info (device sdc2: state EA): forced readonly

Codici di errore del filesystem: "state A" e "state EA"

EIO (Input/output error)
“Input output error”, typically returned as an error from a device that was unable to read data, or finish a write. Checksum errors also lead to EIO, there isn’t an established error for checksum validation errors, although some filesystems use EBADMSG for that.

https://btrfs.readthedocs.io/en/latest/ ... tput-error

Possibile cause:

The root cause of the error cannot be easily determined, possible reasons are:

- logical bug: filesystem structures haven’t been properly updated and stored

- misdirected write: the underlying storage does not store the data to the exact address as expected and overwrites some other block

- storage device (hardware or emulated) does not properly flush and persist data between transactions so they get mixed up

- lost write without proper error handling: writing the block worked as viewed on the filesystem layer, but there was a problem on the lower layers not propagated upwards

Come hai testato tu stesso su un altro controller il filesystem funziona e quindi escluderei un problema firmware/hardware del disco ma del controller "caddy"

Guarda questo video per un confronto e la differenza di un FS con checksumming e non: https://youtu.be/8XG9LF-vtGc

Se vuoi riprovare con un checksumming più robusto (xxhash), cosi tanto per test, anche se mi aspetto che avrai lo stesso problema:

Codice: Seleziona tutto

sudo mkfs.btrfs --csum xxhash /device

Giusto per informazione, per le nuove formattazioni e con kernel e btrfs-progs recenti (Ubuntu 23.10 >) consiglio di abilitare il block group tree; velocizza il montaggio soprattutto su storage di grandi dimensioni:

Codice: Seleziona tutto

sudo mkfs.btrfs -O block-group-tree /device

Come avviso: su kernel <6.1 il filesystem non può essere montato

[wilecoyote]

,:) Salve, giusto per non lasciare qualche dubbio sul punto, non è che il Btrfs sia troppo recente pel controller del caddy, o viceversa il controller del caddy sia troppo datato pel Btrfs ?

Ciao

[emanuc]

,:) Salve, giusto per non lasciare qualche dubbio sul punto, non è che il Btrfs sia troppo recente pel controller del caddy, o viceversa il controller del caddy sia troppo datato pel Btrfs ?

Ciao

Non c'è niente da supportare, è un semplice adattatore da quel che ho capito, forse un problema nei pin, boh, mai usati.

[GjMan78]

@emanuc Grazie mille, come al solito i tuoi post sono sempre molto interessanti.

Nel frattempo ho ordinato un altro caddy, domani vi farò sapere come si conclude la storia.

[GjMan78]

Il problema era proprio il caddy a quanto pare.
Ne ho preso uno su amazon e a differenza del primo questo ha all'interno un piccolo interruttore che permette di "configurare" l'adattatore per il funzionamento con diverse marche di notebook.



Prima i benchmark non superavano i 300 mega scarsi in lettura/scrittura invece ora se la batte tranquillamente con il samsung evo nello slot principale.



Lascio il link per l'acquisto del secondo caddy, magari può essere utile a qualcuno in futuro.
https://www.amazon.it/dp/B078D732KP?psc ... ct_details

Direi problema risolto.

Grazie a tutti per il supporto, specialmente a @emanuc che è sempre disponibile a risolvere i miei casini con btrfs.

[emanuc]

Ottimo
Alla fine hai lasciato crc32c come hash?
Io ormai vado di xxhash, perché è un hash più robusto e sul mio hardware è più veloce:

Codice: Seleziona tutto

emanu@fedora ~/btrfs-progs-6.5 $ ./hash-speedtest 
CPU flags: 0xff
CPU features: SSE2 SSSE3 SSE41 SSE42 SHA AVX AVX2
Block size:     4096
Iterations:     100000
Implementation: builtin
Units:          CPU cycles

      NULL-NOP: cycles:     62640180, cycles/i      626
   NULL-MEMCPY: cycles:     96005988, cycles/i      960,    14624.248 MiB/s
    CRC32C-ref: cycles:   2964379824, cycles/i    29643,      473.630 MiB/s
     CRC32C-NI: cycles:    172706040, cycles/i     1727,     8129.509 MiB/s
        XXHASH: cycles:    137982096, cycles/i     1379,    10175.358 MiB/s
    SHA256-ref: cycles:   9034492428, cycles/i    90344,      155.407 MiB/s
     SHA256-NI: cycles:   3875966568, cycles/i    38759,      362.237 MiB/s
    BLAKE2-ref: cycles:   2076089760, cycles/i    20760,      676.280 MiB/s
   BLAKE2-SSE2: cycles:   2212788852, cycles/i    22127,      634.502 MiB/s
  BLAKE2-SSE41: cycles:   1437383304, cycles/i    14373,      976.788 MiB/s
   BLAKE2-AVX2: cycles:   1535629032, cycles/i    15356,      914.296 MiB/s

[GjMan78]

Ottimo
Alla fine hai lasciato crc32c come hash?

Mi sto documentando proprio ora, ti faccio sapere quale scelgo alla fine.

edit:

Mi sono bloccato sulla compilazione del tool hash-speedtest.c.

Mi dai una dritta per favore?

Ho clonato il repo e compilato con i classici comandi ma alla fine ha generato tutti gli eseguibili tranne quelli della cartella crypto.

[emanuc]

Ottimo
Alla fine hai lasciato crc32c come hash?

Mi sto documentando proprio ora, ti faccio sapere quale scelgo alla fine.

edit:

Mi sono bloccato sulla compilazione del tool hash-speedtest.c.

Mi dai una dritta per favore?

Ho clonato il repo e compilato con i classici comandi ma alla fine ha generato tutti gli eseguibili tranne quelli della cartella crypto.

Devi compilare con questo flag di conf:

Codice: Seleziona tutto

./configure; make hash-speedtest 

[GjMan78]

Devi compilare con questo flag di conf:

Codice: Seleziona tutto

./configure; make hash-speedtest 

Ari grazie.

Visto il risultato penso mi convenga rimanere con CRC32C, che ne pensi?

Codice: Seleziona tutto

❯ ./hash-speedtest
CPU flags: 0xbf
CPU features: SSE2 SSSE3 SSE41 PCLMUL SSE42 AVX
Block size:     4096
Iterations:     100000
Implementation: builtin
Units:          CPU cycles

      NULL-NOP: cycles:     43072183, cycles/i      430
   NULL-MEMCPY: cycles:     64291615, cycles/i      642,    15130.327 MiB/s
    CRC32C-ref: cycles:   2735903409, cycles/i    27359,      355.571 MiB/s
     CRC32C-NI: cycles:     86682791, cycles/i      866,    11222.029 MiB/s
        XXHASH: cycles:    129103182, cycles/i     1291,     7534.987 MiB/s
    SHA256-ref: cycles:   9522742524, cycles/i    95227,      102.156 MiB/s
     SHA256-NI: no CPU support
    BLAKE2-ref: cycles:   2223387182, cycles/i    22233,      437.534 MiB/s
   BLAKE2-SSE2: cycles:   2247077582, cycles/i    22470,      432.921 MiB/s
  BLAKE2-SSE41: cycles:   1605601001, cycles/i    16056,      605.884 MiB/s
   BLAKE2-AVX2: no CPU support

[emanuc]

Visto il risultato penso mi convenga rimanere con CRC32C, che ne pensi?

Per le prestazioni si, per la robustezza no.
Leggi questa discussione per ulteriori dettagli: https://github.com/kdave/btrfs-progs/issues/548

Certo, può dipendere anche dalle feature della CPU, ad esempio la mia sembra più recente e con un set di istruzione in più:

CPU features: SSE2 SSSE3 SSE41 SSE42 SHA AVX AVX2
v
CPU features: SSE2 SSSE3 SSE41 PCLMUL SSE42 AVX