[frissítve] btrfs segfault

Ubuntu Linux

hátezmeg?

:~# cat /var/log/kern.log | grep -i btrfs
...
...
Oct 28 15:29:45 king-crimson kernel: [    3.884775] Btrfs loaded, crc32c=crc32c-generic
Oct 28 15:29:45 king-crimson kernel: [    4.493969] BTRFS: device label UBUNTU-SRV devid 6 transid 6085221 /dev/sdb3
Oct 28 15:29:45 king-crimson kernel: [    4.495198] BTRFS: device label UBUNTU-SRV devid 5 transid 6085221 /dev/sda3
Oct 28 15:29:45 king-crimson kernel: [    4.541971] BTRFS info (device sda3): disk space caching is enabled
Oct 28 15:29:45 king-crimson kernel: [    4.542918] BTRFS info (device sda3): has skinny extents
Oct 28 15:29:45 king-crimson kernel: [    4.627802] BTRFS info (device sda3): enabling ssd optimizations
Oct 28 15:29:45 king-crimson kernel: [    5.430067] BTRFS info (device sda3): use lzo compression, level 0
Oct 28 15:29:45 king-crimson kernel: [    5.431829] BTRFS info (device sda3): disk space caching is enabled
Oct 28 15:29:45 king-crimson kernel: [    6.816090] BTRFS: device label MENTÉS devid 1 transid 132 /dev/sdc1
Oct 28 15:29:45 king-crimson kernel: [    7.034057] BTRFS info (device sdc1): use lzo compression, level 0
Oct 28 15:29:45 king-crimson kernel: [    7.034059] BTRFS info (device sdc1): disk space caching is enabled
Oct 28 15:29:45 king-crimson kernel: [    7.034060] BTRFS info (device sdc1): has skinny extents
Oct 28 15:36:06 king-crimson kernel: [    4.012990] Btrfs loaded, crc32c=crc32c-generic
Oct 28 15:36:06 king-crimson kernel: [    4.649547] BTRFS: device label UBUNTU-SRV devid 6 transid 6085230 /dev/sdb3
Oct 28 15:36:06 king-crimson kernel: [    4.650792] BTRFS: device label UBUNTU-SRV devid 5 transid 6085230 /dev/sda3
Oct 28 15:36:06 king-crimson kernel: [    4.697472] BTRFS info (device sda3): disk space caching is enabled
Oct 28 15:36:06 king-crimson kernel: [    4.698450] BTRFS info (device sda3): has skinny extents
Oct 28 15:36:06 king-crimson kernel: [    4.782277] BTRFS info (device sda3): enabling ssd optimizations
Oct 28 15:36:06 king-crimson kernel: [    5.594572] BTRFS info (device sda3): use lzo compression, level 0
Oct 28 15:36:06 king-crimson kernel: [    5.594573] BTRFS info (device sda3): disk space caching is enabled
Oct 28 15:36:06 king-crimson kernel: [    6.963444] BTRFS: device label MENTÉS devid 1 transid 132 /dev/sdc1
Oct 28 15:36:06 king-crimson kernel: [    7.187828] BTRFS info (device sdc1): use lzo compression, level 0
Oct 28 15:36:06 king-crimson kernel: [    7.187830] BTRFS info (device sdc1): disk space caching is enabled
Oct 28 15:36:06 king-crimson kernel: [    7.187831] BTRFS info (device sdc1): has skinny extents
Oct 28 16:17:09 king-crimson kernel: [ 2471.393528] btrfs[4177]: segfault at 7ffce9d4f2a2 ip 0000561b762e6afe sp 00007ffce9c4ea50 error 4 in btrfs[561b762a2000+6c000]
:~#
:~#
:~#
:~# uptime 
 17:27:42 up  1:51,  2 users,  load average: 0,03, 0,02, 0,00

Újraindítottam, fel se bootolt.
Helyesen mondva elindítottam, mert teljesen megállt, annyira hogy ki kellett húzni a 220-ból, és megvárni amíg teljesen lemerül :/

Ki kellett vennem az egyik ramot, akkor elindult, de a segfaultok nem szűntek meg.
lehet hogy az összes ram modul eldurrant?
mindenesetre felbootoltam pendrájvról, és lefuttattam egy 'btrfs check --repair /dev/sdxxx' okosságot, de nem talált semmit.
de az alatt a rövid idő alatt, amíg a pendrájvról futott nem észleltem segfault-ot sem.
Most üzemszerűen megy egy ram modullal, nagyjából másfél-két órája és már megint itt van - bár csak egy - segfault. de hát ez is sok! v. sock?

Muszáj volt visszakapcsolni, mielőtt valaki rákérdez:))

Most várakozó álláspontra helyezkedtem, amíg ki nem derül valami biztos, v végleges hiba. Mert ez a huzavona nem tesz jót az idegeimnek :/

Frissítés

Tehát a ram cseréje megtörtént, ahogy a tesztelésük is.
Ettől függetlenül az alaplap is cserés lesz, már nem tudok bízni benne.

A 2017-ben létrehozott végül ssd-kre cselét, ezzel együtt 3 pár merevlemezt túlélt fájlrendszer folyton ro-ra kapcsolt egy idő után. Ezen többszöri ellenőrzés után, csak egy balance segített. Végül ilyen lett.

$ sudo btrfs filesystem usage /srv
[sudo] ******* jelszava: 
Overall:
    Device size:		 889.58GiB
    Device allocated:		 256.06GiB
    Device unallocated:		 633.52GiB
    Device missing:		     0.00B
    Used:			 250.71GiB
    Free (estimated):		 318.45GiB	(min: 318.45GiB)
    Data ratio:			      2.00
    Metadata ratio:		      2.00
    Global reserve:		 512.00MiB	(used: 0.00B)

Data,RAID1: Size:126.00GiB, Used:124.32GiB (98.66%)
   /dev/sda3	 126.00GiB
   /dev/sdb3	 126.00GiB

Metadata,RAID1: Size:2.00GiB, Used:1.04GiB (52.04%)
   /dev/sda3	   2.00GiB
   /dev/sdb3	   2.00GiB

System,RAID1: Size:32.00MiB, Used:48.00KiB (0.15%)
   /dev/sda3	  32.00MiB
   /dev/sdb3	  32.00MiB

Unallocated:
   /dev/sda3	 316.76GiB
   /dev/sdb3	 316.76GiB

Ha meglesz az új alaplap, - költségkerete :)) - meg a bele való ram azt hiszem cserélem a fájlrendszert is zfs-re.
Az új alaplapon amúgy sem tartom szerencsésnek egy másikon formázott belső lemezt használni.

Egyenlőre ennyi! - Legalábbis remélhetőleg :) -

  • 619 megtekintés

( Ar0n v | 2020. 10. 28., sze – 22:00 )

Veszelyes jatek ez... Nekem viszont nem volt ekkora szerencsem.

de az alatt a rövid idő alatt, amíg a pendrájvról futott nem észleltem segfault-ot sem.

Ez meg nem eleg. Sokminden lehet, tap, alaplap, lehet tenyleg vacak az egyik memoria ... En memtest-et tolnek masik geppel.

Amugy egyformak a RAM modulok (gyarto, sorozat stb..)?

igen, én is tudom hogy sovány az az idő amíg lefutott a btrfs tesztje. szívem szerint én is nyomnék neki egy jó hosszú memtesztet, de nem tudok mit tenni, veszek ramot holnap, és cserélem. akár jó akár nem.

a nagyobb baj, hogy a legtöbb része már olyan öreg, hogy nem is kapható :)

A memtest másik gépen azért nem 100%. Nekem volt olyan ram-párom, ami csak az adott lapban hibázott, igaz elég ritkán (pár óra memtest után, de reprodukálhatóan). SPD-ben, kézi beállításokkal és alacsonyabb órajelen is, mint a gyári. A ramok két másik gépben is tökéletesen mentek több nap memtest-tel és másik ramok pedig jól muzsikáltak ebben az alaplapban.

( iattilagy | 2020. 10. 28., sze – 22:19 )

Amúgy ez nem tudom mi a fene lehet, de nem kernek szintű segfault. Az kinyírná a rendszer. Lehet ez valami userspace cucc ami a kernel logba ír? Nem lenne példa nélküli.

Btw: milyen kernel van rajta? Más hibák is vannak a logban? 

ECC ram legalább vagy sima?

a gazdái mos voltak pár napost gyógyfürdőzésen, ezért most kapott full-upgradet.

:~# uname -a
Linux king-crimson 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

pont ez az egyik oka, hogy ennyire idegesít ez a hiba..
egyébként nem szoktam frissíthetni, viszont livepatchal foltozgatja a kernelt.
ami eddig elég jól bevált.

ecc ramok vannak benne.

( Zs | 2020. 10. 30., p – 12:22 )

Ha csak egy memória modul is hibázik, az fs záros határidőn belül korrupt lesz, mert más került a cache-ba és onnan a memória hiba miatt más íródott ki a lemezre.
A memória cseréje azt a problémát megoldja, hogy új hiba nem keletkezik az fs alatt - de amit már sikerült bevinni, az ott marad és ettől az fs driver szeme kimeredhet.

Megjegyzés: át lehet állni zfs-re, de az is intenzíven használja a memóriát. Ha a memória modul hibázni kezd, akkor a zfs pont ugyanúgy fejre fog állni, mint a btrfs.

Egyetértünk.
Azt szerettem volna kiemelni, hogy ha a hibás memória miatt összeboruló btrfs-t okozta rossz tapasztalat miatt szertene zfs-re váltani a kérdés felvető, akkor azt ugyan megteheti, de a memória hiba ellen a zfs sem véd, az is korrupt lesz, tehát ha csak emiatt cserélné, akkor nem érdemes.

+1 Alapvetoen igy van es ha tudod, hogy vacak a RAM akkor barmi is megtortenhet.

Kiegeszitenem meg annyival, hogy mig mas filerendszerek azzal probalkoznak "vedekezni", hogy van a metaadatrol backup, addig a a btrfs-nel ez ki van kapcsolva, ha SSD-t eszlel az mkfs. Igy ki lehet jelenteni, hogy ebben az esetben, ha btrfs-t hasznal az ember nagyobb az eselye, hogy mindene elvesz.

Ezt azzal magyarazzak, hogy mivel alapbol vegez deduplikaciot az SSD ezert ertelmetlen ketszer tarolni a metadatat, mert valojaban fizikailag kb. azonos helyre kerul. Viszont ebben esetben pont hasznos lenne...

+1, teljes retardáció a BTRFS default SSD-n, szerencsére manuálisan át lehet kapcsolni, de ezt nem sok kezdő tutorialba írják bele...

>ha btrfs-t hasznal az ember nagyobb az eselye, hogy mindene elvesz.

Egyébként tök jó, hogy ezekbe a komplex fájlrendszerekbe mindenféle védelmet belegyúrnak, de a komplexitásukból adódóan ha mégis valami gebasz adódik, amit a beépített eszközök már nem tudnak megoldani, akkor jó eséllyel meg vagy lőve. Kevésbé lesz lokális a probléma és áll tőle fejre az egész fájlrendszer, illetve míg a fapadosabb fájlrendszerek esetén külső toolokkal még egész jól vissza mazsolázhatsz a vackaidból pár dolgot ha azok is beszarnak, ez egy bekapcsolt tömörítéses COW BTRFS-nél kb. a lehetetlen kategória.

Egyébként tök jó, hogy ezekbe a komplex fájlrendszerekbe mindenféle védelmet belegyúrnak, de a komplexitásukból adódóan ha mégis valami gebasz adódik, amit a beépített eszközök már nem tudnak megoldani, akkor jó eséllyel meg vagy lőve.

A működésük a komplex, nem a felépítésük. A tervezésükkor az elsődleges szempont a hiba tolerancia és a helyrehozhatóság biztosítása.
A "külső" toolok a "bonyolut"-aknál is legalább olyan hatékonyak, sőt, ha van duplikált adat, akkor jóval hatékonyabbak.

Igaz ez több éve történt már, de nekem volt csúnya fájlrendszer hibám amikor a BTRFS-es toolok csődöt mondtak (segfaulttal szállt el a többsége), úgyhogy jobb híján ránéztem photorec-kel talán (és/vagy valami hasonlóval), hogy hátha pár fájlt legalább talál, de semmi. Aztán lehet azóta javult a helyzet.

zfs tud egy extrát: https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p2…

ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

( elod v | 2020. 10. 30., p – 20:48 )

zfs helyett én snapraid + mergerfs-t (vagy más union fs-t, nem emlékszem már pontosan) készülök tesztelgetni.

Jó a zfs, de itthon a flexibilitás úgy érzem fontosabb szempont.

( ricsip v | 2020. 10. 30., p – 22:41 )

Szerkesztve: 2020. 10. 30., p – 22:48

Ha mar fajlrendszer sérülés, btrfs, és főleg ZFS: a csoda ECC is megér 1 misét:

https://www.truenas.com/community/threads/the-usefulness-of-ecc-if-we-c…  -> első oldaltól érdemes nekikezdeni, öröm látni hogy évek eltelnek ilyen problémáknál megoldás nélkül

https://serverfault.com/questions/643542/how-do-i-get-notified-of-ecc-e…

Csak Intelen megy, AMD-n nem? Pl. a linuxos MCELOG tool-t intel mérnökök írták még az özönvíz előtt, persze h. AMD-n sehogy nem  funkcionál. Teszt és bizonyítás jelleggel hogy mégiscsak er valamit, ECC hibát beinjektálni megint csak megoldhatatlan feladatnak tűnik. A segszikla (gy.k. Asrock) kamuzik vagy tényleg fingjuk sincs hogyan kell az alaplapon Bios-ban engedélyezni az ECC-t, a most éppen a ryzen miatt ünnepelt amd meg amúgy PONT ugyanolyan faszfej cég mint az intel ha a partnerekkel kell információt megosztani? A pcengines APU2 ECC blogposztomban ugyanez volt a tapasztalat a GX-412 SoC-al kapcsolatban is velük. Ha pedig megvettem a drága felaras ECC RAM modult, a drága feláras szerver alaplapot, drága feláras szerver-grade processzort, és még elvileg az oprendszer is "tudja" az ECC-t, hogyan bizonyosodhatok meg róla? A tűheggyel rövidrezárt RAM foglalat lábakat haggyuk már.. Vagy végül ennek is csak ilyen hitkérdéssé kell degradálódnia; kifizettem a hiszékenységi adót így akkor megnyugszik a lelkem h. RAM hiba nem lehet a gépben mert majd időben elcsípi az ECC varázslat? Amíg ki nem derül, hogy igazából valami értelmetlen buzi bios beállítás nem is volt kipipálva, így a csodaszerver 8-10 évig lényegében mindenféle ECC nélkül futott..

Stricik ês kurvák világa ez az informatika biznisz

A Linux kernelben van lehetőség hiba injektálásra:

https://www.kernel.org/doc/html/latest/firmware-guide/acpi/apei/einj.ht…

AMD esetén:

https://cateee.net/lkddb/web-lkddb/EDAC_AMD64_ERROR_INJECTION.html

Bár én sosem használtam ezeket a lehetőségeket.

 

Az utolsó mondattal kapcsolatban két Auróra szám jut eszembe:

Jönnek a gépek:

https://youtu.be/-EIKVw9SZ2w

EKG:

https://youtu.be/RXfIZkXmzro

 

Illetve egy ráadás szám:

https://youtu.be/eupVx_k8nR0

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."