» »

Možnost izgube podatkov pri uporabi ext4

Možnost izgube podatkov pri uporabi ext4

Slo-Tech - Kot poročajo na H-online se je v sistemu za beleženje programskih hroščev prihajajočega Ubuntu 9.04 pojavilo večje število poročil o težavah pri uporabi ext4 datotečnega sistema.

Ubuntu Linux 9.04 je še v razvoju, izšel pa naj bi prihodnji mesec. Privzeto bo uporabljal preizkušen datotečni sistem ext3, na voljo pa je tudi novi ext4. Žal pri tem prihaja do nekaterih težav.

Uporabniki namreč poročajo o sesutjih neposredno po nalaganju namizja KDE 4, posledica katerega je izguba vseh ustvarjenih datotek, vključno s konfiguracijskimi.

Kot je pojasnil razvijalec ext4 Theodore Ts'o je težava v tem, da ext4 zaradi optimizacije zapisovanja uporablja zakasnjeno pisanje podatkov na disk. Zakasnitve pa so lahko tudi do 60 sekundne. Če v tem času pride do sesutja sistema, pride do izgube podatkov. Enake težave se lahko pojavljajo tudi pri drugih sodobnih datotečnih sistemih, npr. XFS in Btrfs.

Dolgoročna rešitev je, da razvijalci aplikacij le-te napišejo tako, da bodo upoštevali lastnosti ext4 datotečnega sistema, kratkoročno rešitev v obliki popravna Linux jedra pa lahko pričakujemo v jedru 2.6.30.

34 komentarjev

Brane2 ::

Tso najbrž ni neumen tip ampak ta njegova pojasnila so medla.

Štekam, da ext4 buncha podatke, ni mi pa čisto jasno, zakaj bi zaradi tega moralo prihajati do izgub.

Razumem, da lahko izgubiš podatke, če prazgodaj izklopiš mašino.

Ne štekam pa, kako ti lahko izginjajo ali se kvarijo deli datotek ali kar cele datoteke in to ni posledica slabega FS.

Če ti uporabljaš legalne operacije, stvar ne sme škripnit.

Meni je,kar nekajkrat, dokler nisem vnesel patchev.

Čudno je to, da so ext4 razglašali za "production ready", nato pa se pokažejo taki bugi, ki bi morali biti odkriti in odpravljeni davno...
On the journey of life, I chose the psycho path.

BigWhale ::

Ce ugasnes masino sredi zapisovanja na disk, torej pol filetka je v journalo, pol pa ze na disku, potem bos tisto polovico, ki se ni na disku izgubil. Makes perfect sense.

Nevem sicer kako se zapisujejo podatki in v kaksnem vrstnem redu ampak vmes je se disk cache in zaradi vsega skupaj ti lahko izgine cel file. Journal se zapise in za filesystem je stvar zakljucena, a na disku se ni nicesar, ker je se v disk cache-u samega diska. Ce masino takrat ugasnes, bos ostal z corrupted file systemom.

Men se to zdi cist normalno. Ce ces imet hiter caching filesystem zraven pridejo dolocene omejitve, shit happens. 150 sekund preden se zapise file na disk? Kar preracunaj koliko je lahko to podatkov. Precej! :)

zee ::

To pa malo sux...na najnovejsem clustru uporabljamo ext4 in je tako "na uc" precej hitrejsi od ReiserFS3.
zee
Linux: Be Root, Windows: Re Boot
thorin: Dual Xeon E5-2630v3, 32 GB RAM, Dual Tesla K40

Brane2 ::

Ce ugasnes masino sredi zapisovanja na disk, torej pol filetka je v journalo, pol pa ze na disku, potem bos tisto polovico, ki se ni na disku izgubil. Makes perfect sense.


Seveda. Le da ni šlo za to. Mašina mi je bila vklopljena po več dni skupaj in dogajalo se je, da se je filesistemu zabluzilo med delom. Kar naenkrat je izginil kak bistven del neke sistemske knjižnice recimo. Ko sem stvar restartal, je zazijalo maljon lukenj v sistemu, FS check je pa našel full enih smeti, s katerimi ji je zafilal "lost+found".

Nikoli nisem izgubil nič res kritičnega, le stvari, ki so grenile življenje- partisoč od miljona konfiguracijskih datotek itd, ki jih je rabil firefox in thunderbird, deli Gnomea itd.

Ext4 je imel napake, zaradi katerih je izgubljal stvari _med_delom_ .

Stvari so se nehale ob zadnjem patchu vanilla kernela, ki je imel kup ext4 popravkov - patch-2.6.28.7

Tega sem prečesal in iz uporabnih zadev zrolal svoj patch, s katerim sem zaflikal gentoo-sources kernel.

Nanovo scompilani kernel dela s popravljenim ext4 zaenkrat super.

Tso ima mogoče prav glede tega časa, vendar je bila masa prijavljenih napak zaradi bugov v driverju.

Če ti ugasneš mašino normalno, potem nima veze kaj počne FS z batchanjem dostopov. Ma da pospravi za seboj.
Če se ti stroj ugasne ke je zmanjkalo štroma, je druga pesem. Ampak tudi takrat bi morali podatki, ki so poslani na disk dolgo nazaj, biti zapisani, pa se to ni dogajalo.


Nevem sicer kako se zapisujejo podatki in v kaksnem vrstnem redu ampak vmes je se disk cache in zaradi vsega skupaj ti lahko izgine cel file. Journal se zapise in za filesystem je stvar zakljucena, a na disku se ni nicesar, ker je se v disk cache-u samega diska. Ce masino takrat ugasnes, bos ostal z corrupted file systemom.


Mislim, da ne. Samo par fileov bo imelo napačno vsebino.


Men se to zdi cist normalno. Ce ces imet hiter caching filesystem zraven pridejo dolocene omejitve, shit happens. 150 sekund preden se zapise file na disk? Kar preracunaj koliko je lahko to podatkov. Precej! :)


Kot sem že rekel, ni šlo (samo) za to.

BTW, se je kdo že poigral z Btrfs ?
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

BigWhale ::

No, jaz sem bolj komentiral novico, kaj se je tebi dogajalo pa ne vem. :) To, da pa stvarem pravijo production ready je pa dandanes boljs tko. Tudi Vista je bila production ready. Pa KDE 4. ;>

jype ::

Zajebano je predvsem če obesiš kernel (kar se pri uporabi modulov "namizne kakovosti" ne zgodi tako redko) - takrat so možnosti, da bufferji ne bodo šli na disk, prevelike.

Saj te parametre se da nastavljat med delovanjem mašine skozi procfs in sysfs - seveda pa pogostejše pisanje manjših kosov pomeni degradacijo zmogljivosti, ker disk več opleta z glavo.

Brane2 ::

A ni eden od "magic sysreq-ov" ( three-finger-salute ) namenjen temu ?

Seveda, če kernel ni dokončno seesut...
On the journey of life, I chose the psycho path.

zee ::

Je ja. Mislim, da je ena kombinacija, ki vkljucuje tipko ScrollLock/Sysreq.
zee
Linux: Be Root, Windows: Re Boot
thorin: Dual Xeon E5-2630v3, 32 GB RAM, Dual Tesla K40

Matevžk ::

PrtSc/SysRq tipka je.

Tipična sekvenca:
Alt+SysRq+U -- emergency remount R/O
Alt+SysRq+S -- emergency sync
Alt+SysRq+B -- emergency reboot
lp, Matevžk

Matthai ::

Hmm, morda bo del rešitve onboard UPS... ampak 150 sekund je odločno preveč. Hudiča a se delaya ne da štelati?
All those moments will be lost in time, like tears in rain...
Time to die.

BaRtMaN ::

Sure, lahko ga nastaviš na 0, tako da filesystem mountaš z opcijo sync. >:D

kriko1 ::

Če se ne motim je to opcija commit.

BaRtMaN ::

Je res, pri npr. ext3:
commit=nrsec
Sync all data and metadata every nrsec seconds. The default value is 5 seconds. Zero means default.

ender ::

Kolikor sem razumel, je eden od problemov to, da če delaš po sistemu "odpri začasno datoteko, zapiši, zapri, preimenuj preko obstoječe datoteke" (torej običajen način zapisovanja datotek, kjer ne bi rad ostal s pokvarjeno datoteko), se lahko zgodi, da ostaneš brez obeh datotek (torej, brez stare in nove datoteke), če ne kličeš fsync, kar je idiotizem.
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Mavrik ::

Jasno, zdaj so aplikacije krive za zajeb v filesystemu. Linux development at it's best :D
The truth is rarely pure and never simple.

Matthai ::

Hja, moje mnenje je, da ect4 odf*** in ostanemo na ext3. Osebno uporabljam tudi Reiserja. Pa žena je tudi še zdrava. :D
All those moments will be lost in time, like tears in rain...
Time to die.

kriko1 ::

Jaz uporabljam ext4 že od prve stabilne različice in ni nobenih težav.
Commit imam pa vedno na 15 sekund.

c0ck4m0u53 ::

Tako / kot /home na ext4, zaenkrat nikakršnih problemov (enako kot prej z ext3). Sodeč po odzivu na arch forumu pa imajo ljudje različne izkušnje, glede zgoraj navedene težave.

R33D3M33R ::

Kaj prinaša ext4 za desktop uporabnika napram ext3?
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:

Brane2 ::

Hitrejši dostop, hitrejše operacije nad veliko fajli naenkrat, večje dovoljene velikosti filea in filesistema, boljše pakiranje datotek, sploh majhnih itd.

Pri ext3 ti pri še tako majhnih fajlih vsak zasede najmanj en blok (4K) in njihova dejanjska velikost na disku je zaokrožena na število blokov. ext4 zna pokombinirati več preostalih koncev več fileov in jih stlačit v en blok.

Kernel sourcei scompilanega kernela so včasih na ext3 vzeli praktično gigabajt, sedaj pa so na ext4 660M.

Brisanje celotnega direktorija z maljardo fajli je znalo trajati, sedaj je praktično trenutno.
On the journey of life, I chose the psycho path.

Poldi112 ::

>Jasno, zdaj so aplikacije krive za zajeb v filesystemu. Linux development at it's best :D

A imaš kakšen argument, da gre za zajeb v filesystemu, ali se ti pač zgolj tako zdi?
-------------------------------------------------
Nočem foto avatarja. Hočem risan avatar.
-------------------------------------------------

Brane2 ::

Kaj prinaša ext4 za desktop uporabnika napram ext3?


Evo primerčka:

1. brisanje celotnega drevesa scompilanega kernela:

time rm -Rf linux-2.6.28-gentoo-r3_kopija

real 0m0.672s
user 0m0.008s
sys 0m0.644s
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

Daedalus ::

Ostajam na ext3/reiser. Če se ne bojo pa l00nix developerji malo zmigali okoli tehle prastarih fs-jev in nestabilnih novih, pa šaltam na Opensolaris/Nexento in ZFS. Ext4 je pa production ready not očitno.
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]

Poldi112 ::

A potem tudi xfs ni production ready? Pa ne da bi zagovarjal ext4, ker tudi sam zagovarjam konservativen pristop k novostim v datotečnih sistemih, ampak tile zaključki nekaterih so rahlo smešni. A sploh berete novice, ali samo naslov?
-------------------------------------------------
Nočem foto avatarja. Hočem risan avatar.
-------------------------------------------------

zee ::

XFS imam na mojem diskovju (5TB) in dela ko šus. Sploh v kombinaciji 30+ GB fajli.

/ in ostale manj pomembne mape so na reiserfs zaenkrat.
zee
Linux: Be Root, Windows: Re Boot
thorin: Dual Xeon E5-2630v3, 32 GB RAM, Dual Tesla K40

Zgodovina sprememb…

  • spremenilo: zee ()

Daedalus ::

Če podatki zginjajo/so ogroženi med normalno povsem rabo kište - pol ni za "prodakšn redi". Simpl ko keks.
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]

Poldi112 ::

Ena malo divja - če ti recimo virus pobriše podatke - a je tudi takrat kriv filesystem?

Glede "prodaksn redi" - zadeva (ubuntu, kjer se to pojavlja) je v alpha stanju. In do izdaje stabilne verzije bodo to rešili.
-------------------------------------------------
Nočem foto avatarja. Hočem risan avatar.
-------------------------------------------------

aiko ::

Če smo čisto odkriti..počit ven en nov file system s takimi hibami je idiotizem...

Ni še čas... preveč glupih napak...

Brane2 ::

Idiotizem je predvsem način in intenzivnost testiranja.

Production ready navaja na to, da je bil ekstenzivno in intenzivno testiran na strežnikih v praksi.

Od take zadeve bi človek pričakoval, da na napake ne bo naletel sam, če pa že mogoče bo, da bo šlo za periferne in znane napake.

Nakar mu kup datotek zgine med delom, razvijalec pa nekaj bluzi o featurejih in napačni uporabi.

Biser vsega pa je to, da je ext4 mišljen samo kot vmesni korak do Btrfs in tux3, da imamo torej kaj uporabljati do njihovega pojava.

Btrfs pa je že uradno del kernela 2.6.29. je še v development fazi, a pričakujejo da bo v beta čez recimo 6 mesecev do leta. Tux3 še ni uradno includean v kernel.
On the journey of life, I chose the psycho path.

Brane2 ::

Je pa tako, da od zadnjih patchev vsaj emni zadeva kar nekako dela. Niti ene napakice še ni bilo.

Kot kaže, je flika pokrila vse današnje luknje na tej gumi...
On the journey of life, I chose the psycho path.

Matthai ::

Jah jebiga, jaz bom tu malo bolj konzervativen. Najboljše izkušnje imam z ext3.
All those moments will be lost in time, like tears in rain...
Time to die.

Brane2 ::

IMHO tipu manjka edge. Mogoče bi moral še on počit ženo ali naredit korak dlje in ugasnit še soseda na njej.
Reiser4 sploh ni bil tako slab.
On the journey of life, I chose the psycho path.

R33D3M33R ::

Hitrejši dostop, hitrejše operacije nad veliko fajli naenkrat, večje dovoljene velikosti filea in filesistema, boljše pakiranje datotek, sploh majhnih itd.


Torej v bistvu nič zame -> no, mogoče hitrejši dostop :)
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:

KoKi ::

Tudi meni je XFS delal ko šus. Dokler nisem izgubil vseh podatkov. Ampak do takrat, pa je delal ko šus.
# hackable


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Izbira filesystema(linux)

Oddelek: Operacijski sistemi
311547 (715) zee
»

Izšla Fedora 11

Oddelek: Novice / Ostala programska oprema
102820 (1732) Ted
»

Možnost izgube podatkov pri uporabi ext4

Oddelek: Novice / Ostala programska oprema
343476 (2346) KoKi
»

Hans Reiser spoznan za krivega umora svoje žene

Oddelek: Novice / Varnost
273827 (2466) neboben
»

Nov datotečni sistem ext4 prestopil v fazo testiranja

Oddelek: Novice / Ostala programska oprema
423787 (2398) kekz

Več podobnih tem