Utilizatorii se plang de coruperea sistemului de fisiere EXT4 pe Linux 4.19

Problema din jurul Kernel Linux 4.19 stabil este o problema de corupere a fisierelor EXT4 care nu a fost înca rezolvata. Problema este activa inca la mijlocul lunii noiembrie - utilizatorii multipli cu diverse configuratii  raportau probleme de corupere ale sistemului de fisiere EXT4.

Pentru unii utilizatori, aceasta problema apare la fiecare boot.

Subject	ext4 file system corruption with v4.19.3 / v4.19.4
From	Guenter Roeck <>
Date	Tue, 27 Nov 2018 06:32:08 -0800
[trying again, this time with correct kernel.org address]
Hi,
I have seen the following and similar problems several times,
with both v4.19.3 and v4.19.4:
Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode size 256)
Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device sdb1-8.
Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): Remounting filesystem read-only
Nov 23 04:32:25 mars kernel: [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode #12602881: comm rm: bad extra_isize 33685 (inode size 256)
...
Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode referenced: 238160407
Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device sda1-8.
Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): Remounting filesystem read-only
...
Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode referenced: 52043796
Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on device sda1-8.
Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): Remounting filesystem read-only

The same systems running v4.18.6 never experienced a problem.

Has anyone else seen similar problems ? Is there anything I can do to help tracking down the problem ?

Thanks,
Guenter

Exista initial o anumita convingere ca s-ar fi putut datora codului de bloc multi-coada (BLK MQ) din Linux 4.19, dar care pare sa fie exclusa.

Managerul sistemului de fisiere EXT4 Ted Ts'o, credea initial ca problema de corupere a fost introdusa în EXT4 între 4.18 si 4.19 . Se pare ca ipoteza lui Ted este ca aceasta problema de corupere a sistemului de fisiere EXT4 vine din afara kernelului - din codului driverului EXT4.

Se pare ca problemele legate de coruptia EXT4 pe Linux 4.19 se datoreaza, de fapt, unei probleme în cadrul de blocuri multi-coada "blk-mq" (blk-mq permite gestionarea mai multor query-uri distribuite între firele CPU) pentru aceasta serie stabila. De asemenea, se pare ca si alte sisteme de fisiere ar putea fi sau sunt afectate, doar ca EXT4 este cel mai frecvent sistem de fisiere si, prin urmare, detine cele mai multe rapoarte.

Pentru kernel-urile cu modul blk-mq care nu sunt activate în mod implicit, acestea pot fi activate la momentul încarcarii cu modificarea: scsi_mod.use_blk_mq = 1 .

Utilizatorii multipli - inclusiv dezvoltatorii kernel-ului - au hoarat ca stabilitatea datelor lor se îmbunatateste odata cu dezactivarea codului MQ.

Speram, ca aceasta problema nu va fi pentru mult timp, având în vedere ca mai multi se confrunta cu problema.

Update  8 Dec 2018

La începutul acestei saptamâni problema legata de coruptia datelor de pe Linux 4.19+ a fost rezolvata si sa dovedit a nu fi o problema EXT4, ci mai degraba o problema cu mecanismul de asteptare pentru blocarea multipla a blocurilor I / O, care ar putea cauza o coruptie a datelor când ruleaza fara un programator I / O. Odata ce a fost dat seama, kernel-ul Linux 4.20 a preluat repede solutiile si acum a fost returnat la versiunea 4.19.8. Deci, mai ales daca utilizati BLK-MQ cu "none" ca selectie de programator I / O, asigurati-va ca treceti la aceasta versiune ulterioara pentru siguranta datelor.