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 :) -
Hozzászólások
Veszelyes jatek ez... Nekem viszont nem volt ekkora szerencsem.
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.
Koszi! Huh, ekkora szopast :D
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.
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.
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.
Rossz memóriánál nem feltételezheted a rendszer komponenseinek bármiféle konzisztenciáját. Legyen ez filerendszer, file, vagy bármi más.
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.
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 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.
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
Az utolsó mondat kiderülhetett volna számodra az itteni blogbejegyzésekből is :D
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."