btrfs crash

Valahogy éreztem, hogy a múltkori nem volt az utolsó. Olyan szinten szakadt össze az egész fs, hogy a saját repair tooljaival is alig lehetett helyreállítani. Végül második napra sikerült csatolható állapotba hozni, de nem bootol róla a rendszer. Nézegetem, és kiderült, hogy a probléma csupán annyi, hogy a /usr/local subvolume tök üres. Gondoltam, -semmi baj, hát van snapshot. Jah, snapshot van, de abba nincs benne a subvolume tartalma. Úgyhogy ez egy reinstall lesz. De most nagyon gondolkodom, hogy dobom az egész btrfs dolgot, mert eddig csak szívás volt belőle.

( goodbyte v | 2017. 09. 13., sze – 16:52 )

Valamit hallhatunk az összeszakadás körülményeiről ?

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

( hnsz2002 v | 2017. 09. 13., sze – 21:51 )

Épp most készülök kipróbálni. Az új backup szerverre azt raktam :)
--
"Sose a gép a hülye."

( log69 | 2017. 09. 14., cs – 08:29 )

Kicsit félrevezető ahogy írsz. Mi nem volt az utolsó? Egy teljes újratelepítés után ugyanúgy elszállt mint amit itt írtál?

https://hup.hu/node/153743?comments_per_page=9999#comment-2139382

Mert utána nem ezt írod. Lehet hogy a panaszkodás helyett ki kellene dobnod a hardvered a kukába :) Az SSD például milyen? Mert ha occsó, akkor lehet azzal kezdeném, hiába tűnik jónak. Elég rossz tapasztalatom van pár típussal, hiába "jó". Írj pontos típust, kíváncsi vagyok.

Igen, nem igazán konzisztens, amit a két helyen írok, mert ide nem frissítettem utána. De majd ha végeztem és lesz használható gépem, lesz belőle hosszabb blogposzt is, hogy mi volt.
Amikor a kommentet írtam, még nem volt helyreállítva, csak folyamatosan beokádott a "btrfs check repair /devsda"-ra

Ahogy most állok: Újra btrfs-t raktam a rendszer alá, és ismét beszakadt egy kernel pánikolástól, aztán memtest nagy nehezen csak kihozta a memóriát hibásnak.

--
openSUSE 42.2 x86_64

Lehet. De a fő bajom, hogy már nem először szopat meg, és egyébként is egy RO kapcsolóval csatolt subvolume borult meg a legjobban. (A usr/local subvolume úgy volt csatolva, csak a /var/log volt RW, az is megborult, de a logokat helyreraktam belőle.) Az XFS is megborult, azt mégse kezdtem el szidni.

Ennek ellenére még mindig kap lehetőséget, mert úgy gondolom, van értelme nézegetni.

--
openSUSE 42.2 x86_64

Azt el kell fogadni szerintem, hogy mivel sokkal többet tud btrfs, ezért sokkal bonyolultabb is a belső struktúrája és működése és ezért egy mem hiba vagy más hardveres gond sokkal nagyobb eséllyel fog nagyobb kárt tenni benne.

Mentés mindig kell, ahogy zeller szokott rá utalni :)

De en ezeket az elvarasokat nem ertem. Szerintem elvileg lehetetlen olyan szoftvert irni, ami mem hibat toleral. Erre (mem hiba) semmilyen garanciat nem tud egyetlen FS sem adni.
Az az RO flag pedig szinten semmit nem jelent mem hiba eseten. Regen, a kislemezen mikor atkattintottad a pockot RO-ba, na az vedett mem hiba eseten is :)

Nem érted. Hardver hiba esetén bárhol sérülhet az FS (pl. metaadat) és így mindig lehet olyan eset, ami teljesen korrupttá teszi. Honnét tudod hogy nem egy jó idő óta szemeteli a hardvered az FS-t? Tehát ne 1 bit megváltozását képzeld el, hanem például adott szektor adott sávját lecserélem random zajra vagy hasonló. :)

A memóriának kb. 20-25%-a lett hibás. Ez elég nagy, de első nekifutásra mégse jött elő, ami szintén megérne egy anyázást. Miért kellett neki 2 nap, hogy utána folyamatosan elő tudjam varázsolni a hibát.

Ha az FS sérült, de az megvan, hogy mekkora a mérete, melyik blokktól meddig van, akkor esetleg nem el kéne szállnia a repair toolnak, hanem közölni, hogy "akkor most üresre megcsinálom". Ez történt, rendben is van. DE csak 126. nekifutásra volt hajlandó, a sokadik btrfs-zero-log parancsra üres, de végre csatolható subvolt adni nekem. és utána ért a meglepi, hogy a snapshotba nincs benne ennek a tartalma. Tájékozatlanság és félreinformálódás miatt én úgy értelmeztem, hogy belekerül az is és sose ellenőriztem.

Úgy képzelek el egy repair toolt, hogy ha nagy baja is van a fs-nek, akkor akár csak magát a subvolt csinálja újra, elsőre. és itt a problémám továbbra is az, hogy sokadik nekifutásra csinálta meg, nem azzal, hogy mit csinált (leürítette a subvolt). Esetleg tájékoztathat és bekérdezhet, hogy mit is szeretnék kezdeni vele.
A másik, hogy ext4-et RO kapcsolóval lehet fsck-zni, btrfs-t csak akkor, ha lecsatolom. Ez, lévén, hogy a btrfs check parancshoz tartozó mindenség az adott fs-en van, eléggé problémás.

--
openSUSE 42.2 x86_64

Elvi szempontbol teljesen mindegy, hogy a memorianak 1 bitje vagy 25%-a lett-e hibas. Mondjuk elcseszodott 1 bit, pont az, ahova a rendszer betoltotte az FS-drivert. A rossz memcsi miatt az FS driver a kepzeletbeli wirte_block() fuggvenye helyett mashova fog hivni; mondjuk valami hasonlot csinal mint a dd if=/dev/zero of=/dev/sdX. Sok szerencset a repair tool-nak.

Képzeld el úgy, mintha egy DVD lemezt összekarcolnál kedved szerint.

Digitális adat nem analóg. Nincs olyan hogy egy része hiányzik és még vissza lehet állítani. Nem fogja tudni a program hogy hogyan rakja össze. Csak azt látja hogy nem stimmel az ellenőrző összeg.

Vannak erre megoldások, de az extra tárhelybe kerül, pl. raid6 meg különböző algoritmusok (vdm). Ezek úgy duplikálják az adatot, hogy adott részen elveszhet infó, a többiből összefésüli. De neked egy szem disked van sima fájlrendszerrel és hibás hardverrel. De ha még raid-ed lett volna, sajnos a hibás hardver miatt az is simán korrupttá válhat.

ECC memóriával kivédhető a mem hiba. Csak az meg nincs még konzum termékekben tudtommal.