Linux, filerendszer, Firefox, SQLite, fsync

Mozilla

Linux, filerendszer, Firefox, SQLite, fsync - mi a kapcsolódási pont?

Egyes Firefox 3 / Linux konfigurációk felhasználói felfigyeltek arra kellemetlen viselkedésre, hogy rendszerük bizonyos időközönként átmenetileg "megáll". Elkezdődött a nyomozás és a gyanú a SQLite / fsync párosra terelődött.
A Firefox 3 az SQLite-ot többféle adat tárolására is használja. Ilyan adatok például a böngészési történet, a könyvjelzők, stb. Az SQLite fejlesztői komolyan veszik a teljesítményt és az adatbiztonságot. Az adatbázisok érzékenyek az adatsérülésekre, ezért az SQLite - annak érdekében, hogy biztosítsa az adatok integritását egy esetleges crash esetén - egyebek mellett az fsync függvényt használja. Az fsync mondja meg az operációs rendszernek, hogy "ezt a file-t" biztonságosan lemezre írhatja és várjon addig, amíg ez a művelet be nem fejeződik. A Firefox fejlesztők nem szeretnék, ha a felhasználók adatot veszítenének. Éppen ezért a Firefox 3 RC1-ig bezárólag az SQLite-ot az ajánlott beállítására, azaz "teljes szinkronizációra" állították. A vizsgálatok szerint ez okozza egyes felhasználóknál azt a jelenséget, hogy a Firefox bizonyos időközönként átmenetileg "megáll" és egyben "megállítja" a rendszert. A jelenségről hibabejelentés is született.

De mi a probléma?

Egyes Linux konfigurációkon, például amelyeken "data=ordered" beállítással hajtott ext3 filerendszer használatnak, a meghívott fsync nem csak az aktuális file-t írja a lemezre, hanem üríti az egész filerendszer puffert, azaz az összes gyorsítótárazott adatot lemezre írja. Mivel a lemezműveletek - összehasonlítva a memóriaműveletekkel - meglehetősen lassúak, az operációs rendszerek jelentős mennyiségű adatot is pufferelhetnek. A nagymennyiségű pufferelt adat kiírása viszont "megfoghatja" a rendszert.

Azaz?

A probléma akkor jelentkezik, amikor nagymennyiségű pufferelt adat vár lemezre írásra, miközben a Firefox (SQLite) az fsync-en keresztül kéri egy (darab) file kiírását, de helyette nem csak a file, hanem az egész filerendszer puffer kiírásra kerül. A tesztek szerint nem elképzelhetetlen, hogy ez a folyamat akár hosszú másodpercig is eltarthat. Ez a felhasználó szempontjából szívás. A kérdés az, hogy mi a nagyobb szívás. Ez, vagy az, hogy a könyvjelzői elvesznek egy esetleges crash esetén.

Ez a probléma jól ismert az ext3 filerendszer fejlesztői előtt, és már folyik a munka az ext4 fejlesztése során, hogy ezt a nemkívánatos viselkedést orvosolják. Feltehetően más filerendszerek (a cikk írója a Reiser4-et említi) is szenvednek ebben a "betegségben", és feltehetően azok fejlesztői is rajta vannak, hogy megoldást találjanak.

Mi lehet a megoldás?

Rövidtávon a Firefox patch-elése, hogy szabályozható legyen az fsync "agresszivitása". Középtávon gondoskodni kell az adatbázis-műveletek optimalizálásáról, például a tranzakciók kötegelésével. Hosszútávon várhatóan javulnak az érintett linuxos filerendszerek viselkedései, hiszen a fejlesztők rajta vannak a problémán.

A probléma részletes és pontos leírása itt.

( Oldman (nem ellenőrzött) | 2008. 05. 27., k – 10:55 )

ext3 filerendszer használatnak ->ext3 filerendszert használnak

( nc | 2008. 05. 27., k – 10:58 )

Ez az SQLite most felkeltette a figyelmemet, eddig nem is foglalkoztam vele. Basszus, lassan nőzés kizárva :)

( mapee v | 2008. 05. 27., k – 11:19 )

A btrfs már immunis vagy még az is érintett?

Apple MacBook C2D 2.2Ghz 2x1G Intel X3100

( kikke | 2008. 05. 27., k – 11:26 )

data=writeback esetén nem jelentkezik a hiba?
--
the tide is turning

Szerintem ott is jelentkezni fog. Én inkább arra tippelnék, hogy Journal Mode -ban nem jelentkezne ennyire brutálisan, mert ott egyből kiírásra kerül a metadata, így nem lenne akkora a puffer. Vagy rosszul gondolnám? Igaz desktopoon meg kicsit visszavehet az egész rendszer teljesítményéből ez, de biztonságosabb nagyságrendekkel crash esetén, mint a writeback.

--
http://laszlo.co.hu/

Gratulálok. És miért is?

OFF: Ha jól sejtem, akkor windowsupdate-t sem használsz. ;-)

érdekességképpen. secunia idei évi statisztika:
ismertté vált IE 7.x hibák száma 2008
2 javított kritikus, 2 nem javított nemkritikus.
ismertté vált firefox 2.x hibák száma 2008
3 javított kritikus, 1 javított nemkritikus.

Ez alapján a kettő majdnem ugyanaz a kategória.

2 Egyéb böngésző:
Konqueror 3.x
2008 0 db kritikus, 0 db. nemkritikus.
Opera 9.x
2008 1 kritikus, 1 nemkritikus.
Unpatched: 0(!).egyedüliként talán!

--------

Nem a zsömle kicsi, a pofátok nagy...

Akkor most pláne nem értem, hogy miért is baj, ha blalo csak a Firefox letöltésére használja az IE-t...

Egyébként a Safari-t kifelejtetted. Ezért nyaktiló jár! ;P

Üdv,
Dw.

"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."

1. nem mondtam hogy baj, csak mint egységsugarú User nem értem mi értelme egy adott böngészőt lecserélni egy kb. - biztonsági szempontból - ugyanolyanra.

Általában az a megrögzött Anti-IE mániások közötti hit, hogy IE szar, mert nem biztonságos minden szemetet összeszed. Élek az előítélettel :), hogy blalo is ezért firefoxos.

Safarit kifelejtettem és tényleg :))))

Mondjuk ez se jobb ilyen téren mint az IE/Firefox

--------

Nem a zsömle kicsi, a pofátok nagy...

Pedig igen, az IE rosszabb. Ha például nem lenne, akkor a webfejlesztők sem káromkodnának annyit. Nem egyszer előfordult már velem és nyilván másokkal is, hogy firefoxra pikk-pakk kijött minden, aztán IE változatokban megnézve, elment a kedvem az élettől. Mindegyikben máshogy elcsúszva... Vagy éppen nem is úgy jelenik meg. Mert képtelen letérni a "szabvány engem hidegen hagy" útról. Nagy nehezen belekerült, hogy fülek legyenek benne? Meg örülhetek, ha telepítenek egy új IE toolbart, mert elkapkodtam és az "igen"-re nyomtam? És ha IE-ről beszélünk, akkoe windowsról beszélünk és ha windózról beszélünk, akkor kattingatós szerverről, vírusvédelemmel lassított desktopról, átláthatatlan systemről is beszélünk, amit x időnként érdemes legyalulni és újratenni.

akkor kattingatós szerverről",

És? Ha be lehet állítani, akkor nem mindegy, hogy hogyan lesz beállítva?

"vírusvédelemmel lassított desktopról"

Aminek a 3/4-e azért terjed, mert a felhasználók egy része hülye és képtelen felfogni azt, hogy ne kattintson hülyeségre.

"átláthatatlan systemről"

Kinek átláthatatlan? Neked vagy mindenkinek?

"amit x időnként érdemes legyalulni és újratenni."

Nem lehetne abbahagyni ezt a 10 évvel ezelőtti baromság terjesztését?

"amit x időnként érdemes legyalulni és újratenni."

Nem lehetne abbahagyni ezt a 10 évvel ezelőtti baromság terjesztését?

jó, megértem, hogy szúrja a szemed: nyilván felül is lehet írni legyalulás nélkül:D

btw +1 — hozzátéve, hogy pl ha korlátozott felügyeleti lehetőséged van (4 gépet tartok karban, havi egyszer ülök melléjük), olykor jó dolog nyers erővel legyakni az előzőt:D:D
(mondjuk — kopp-kopp — amióta én törődök velük, nem kellett újrarakni)

—-—-— 

int getRandomNumber() {
return 4;	//szabályos kockadobással választva.
	       //garantáltan véletlenszerű.
}	      //xkcd

Én csak akkor rakok ujra windows-t, ha mar nem indul el egyaltalan, vagy ujra kell vmi miatt particionalni a gepet, es a windows erintett a tema soran. Mondjuk a Vista-mat most ujra kellett tenni, de valamit nagyon elkefelhettem, mert nem igazan lett jo a teljesitmenye. De ez user error, es nincs koze ahhoz, hogy a Windows jo vagy nem.

igazából szerintem rajtad kívül csomó ember gondolta ezeket végig, csak már leírni is kár. mit lehet egy olyan hszre mondani, hogy "mi értelme lecserélni az alap böngészőt"? Az ie szar és kész. Nem kell ezt kifejteni, minek. Aki nem érti, annak úgyis hiába mondod. Az használja azt.

biztonsági hibák között felsorolják, hogy nem követ, vagy rosszúl követ szabványokat? valszeg nem. és bizony ez is lehet választási szempont egy böngészőnél (hogy a személyes preferenciát ne is említsem, hisz más is megtette. azt pl. ne egy cég állítsa be az usernél. az maradjon választhtó :) )

--
xterm

Ha már szabványokról beszélünk. Akkor:

1.) Melyik böngésző az amelyik az összes vélt/valós szabványt betartja? tényleg érdekel, mert szerintem ilyen nincsen.
2.) A weboldalak hány százaléka "szabványos" / megfelel az html, stb. akármilyen "szabványoknak" 100%ban /, és hány "gányolt" ?

Van egyáltalán értelme erről beszélni ? :-))

Én inkább többféle böngészőt használok, valamelyikkel ez a honlap, valamelyikkel az a "honlap" csak megjelenik rendesen...

személyes preferenciát

Ez OK. Ez egy dolog. De akkor mondjuk ezt ködösítés helyett. :-))

----------

Nem a zsömle kicsi, a pofátok nagy...

nem ködösített senki. max nem értetted :) az oldalak szabványossága nem érv a böngészőválasztásban. arról nem tehet a fejlesztő. azt vagy látogatod, vagy nem. mintha azt akarnád elérni, hogy az oldalak tervezői minden böngészőre tervezzenek. érdekükben áll. ha nem teszik, sokaknak nem fog tetszeni (mint akár egy ocsmány weboldal se, nem kell ehhez szabáványmentesnek lennie)

hogy melyik böngésző szabványkövetőbb? ez igyekeznek tesztekkel nézegetni az emberek. ez mérhető érték. de amit te ködösítésnek értékeltél nálam, az az volt, hogy rávilágítottam, hogy a böngészőknél nem az egyetlen jósági szempont, hogy hibákból mennyit tudnak megtalálni és javítani. lehet hibátlan egy böngésző. sőt, lehet full szabványkövető. és mi van ha nem csinálnak szabványos oldalt? attól nem a böngésző a hibás. csak erre akartam felhívni a figyelmet. egy új szempont, ha úgy tetszik. ennyit a ködösítésről ;)

--
xterm

lehet full szabványkövető. és mi van ha nem csinálnak szabványos oldalt? attól nem a böngésző a hibás.

Akkor megfordítom hátha így tisztán értjük egymást.

Attól miért is lesz jó egy böngésző ha a "kutya sem használja" szabványt betartja ? :)

Ettől mindjárt "jó" egy böngésző?

Ettől max. átmegy egy akármilyen tesztlapon. Húha! És akko' mivan ? :)

mindjárt ISO-Oscon-001 szabvány szerint bezuhanok a forgószékem alá. :)))

Ehhez a szabványosításhoz már túl késő. Túlságosan sokan szarnak bele magasról a különféle szabványokba már, hogy ebben belátható időben változást lehessen elértni.

---------------------

Nem a zsömle kicsi, a pofátok nagy...

meglehet, de itt nem arról volt szó, hogy a szabvány jó-e, vagy nem. hanem "valaki felvetette, hogy az egyik ilyen jó, a másik olyan jó, mert a sechole-ok felderítési arány ilyen olyan, és ebből kéne levezetni a böngésző preferenciát". semmiképpen nem elégséges szempont egy választásnál a sechole arány a patchekkel összevetve. szükséges, de nem elégséges. de ha gondolod, ess csak be a széked alá ;)

--
xterm

Oscon, kicsit el vagy tajolodva. Nem az a baj, hogy az IE a "kutya sem hasznalja" szabvanyt nem tartja be, hanem hogy a gyakrabban hasznaltakat se igen. a html4-es szabvanynak kabe megfelel, meg fel tudja parsolni a xhtml oldalakat, a megjelenites meg maradt a regi. CSS-ben is eleg sok gyakran hasznalt(!) dolog van, amire az IE nagyivben... khmmm... Az odaig OK, hogy a ritkan hasznalt, hovatovabb ertelmetlen szabvanyokat nem kell betartani, de itt nagyon nem errol folyik a vita.

Sehol. Én a ronda előítéleteimmel feltételeztem róla , és mivel a firefox használók többsége biztonsági okok miatt tér(t) át ezért adta magát a helyzet / . :)

Amúgy meg kiváncsi vagyok milyen racionális indokok rejtőznek egy ilyen mondat mögött:

Az IE-t én max. arra használom, hogy letöltöm vele a Firefoxot. :)

másrészt meg rég volt flame :D

----------

Nem a zsömle kicsi, a pofátok nagy...

rég volt flame? túl sok a flame... racionális okok? az is lehet ok akár (ennél azért pl. nálam több lenne, de ez nyilván nem érdekel, különben nem általánosítanál), hogy neki az jön ben, mert az általa látogatott oldalak csak azzal jók, vagy azzal jobbak. és bizony ez olyan szempont, ami minden mást letartolhat (hiába biztonságos egy böngésző, ha a kedvenc oldalad nem látszik rajta, ugyanis a kérdés a következő adott esetben: mivel nézzem akkor?)

--
xterm

ennek így semmi értelme.. az hogy mennyi rést találnak egy böngészőben az sokat nem mond a biztonságáról. attól mert moondjuk a konquerorban 1-t sem találtak nem feltétlen jelenti hogy nincs, hanem egyszerűen a kutya sem használja, és így emberek nem fognak rajta sebezhetőségek után kutatni..

a másik: firefox: 4ből 4 javított; ie 4-ből 2 javított.. ez neked mikor nagyjából ugyan annyi? nálam ebből az jön le, hogy IE-nél a biztonsági rések felére nagy ívből szarnak..
egyébként a linken: IE 5ből 2 javítva; upatched 37%;; ff: 4ből 4 jav; unpatched 17%..

I hate myself, because I'm not open-source.

firefox: 4ből 4 javított; ie 4-ből 2 javított.. ez neked mikor nagyjából ugyan annyi?

Azért mert a javított hibák közül IDÉN már több volt a súlyosabb hibák száma az FF-hez. A nem kritikusak közül meg IE ben volt több javítatlan. Ez így 1:1 kb. :-)

Tehát ami igaz volt 3-4 éve az IE vs. Firefox meccsen biztonsági téren az ma már nem álja meg a helyét.

Manapság nagyjából ezen a téren mindkettő ugyanolyan teljesítményt nyújt.

--------

Nem a zsömle kicsi, a pofátok nagy...

( snq- | 2008. 05. 27., k – 11:42 )

>> A Firefox 3 az SQLite-ot többféle adat tárolására is használja.

pl 'clear private data' által nem törölt privát adatok tárolására (keywords: moz_places, urlbar dropdown, frecency)

( Husky | 2008. 05. 27., k – 12:18 )

Ez kicsit arra emlékeztet, mint amikor a Vista-ban a médiaplejer leszól a hálókártyának hogy kuss legyen, mert most filmet nézne az ember... 'ombre! ÁLLJ! A Firefox ment!

( Vladi | 2008. 05. 27., k – 12:38 )

Ezaz! Pontosan ezt csinálja Fedora 9-en. Remélem hamar megcsinálják. Vagy akkor megyek ext4-re. Bár még az sincs készen. :(

Fedora is a cutting edge distro that tests new and bleeding edge software.

( uid_14401 | 2008. 05. 27., k – 13:06 )

én is tapasztaltam ReiserFS-el, de igazából nem nagyon érdekel :-)

-----------------------------
Ubuntu 8.04

( nevergone v | 2008. 05. 27., k – 13:07 )

De legalább még az FF 3 hivatalos megjelenése előtt ráfeküdnek a problémára. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( MetaMorfoziS | 2008. 05. 27., k – 13:19 )

<lol>
Az fsync mondja meg az operációs rendszernek, hogy "ezt a file-t" biztonságosan lemezre írhatja és várjon (a crasheléssel) addig, amíg ez a művelet be nem fejeződik [...]
</lol>

________________________________________
2B or not 2B, that is FF. *̡͌l̡*̡̡ ̴̡ı̴̴̡ ̡̡͡|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ ̲|̡̡̡ ̡ ̴̡ı̴̡̡ *̡͌l̡*

( Elbandi v | 2008. 05. 27., k – 13:29 )

magyarul a fsync mukodik szarul: ahelyett hogy csak az adott fajl kenyszeriti ki a winyora, az osszes puffer kiirasra kerul.

Elbandi
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( KoS | 2008. 05. 27., k – 13:37 )

Koszi a cikket trey, en is lattam ezt a jelenseget, kicsit keresgeltem is, de nem talaltam meg a magyarazatot. Most mar legalabb tudom.

( asch v | 2008. 05. 27., k – 13:43 )

A kérdés az hogy csak az újonnan felvett könyvjelzők romlanak-e el vagy az összes.

A többi adatbáziskezelő hogy őrzi meg az integritását? Az ordered mode nem pont arra jó hogy ha log-gal együtt ír egy adatbázis akkor mindenképp visszaállítható legyen egy konzisztens állapot? Ilyen adatbázist kellene alátenni és kész, nem?

( Gabb3r | 2008. 05. 27., k – 13:55 )

Itt jelenleg az a probléma, hogy több disztró is a Firefox 3-al érkezett ami úgy tűnik kicsit elhamarkodott volt.

A probléma akkor jelentkezik bizonyos körülmények közt, ha Firefox 3-at használsz Linux-on. Mivel a Firefox 3-ban került bevezetésre a SQLite. Az nem újdonság, hogy lassú az fsync. PostgreSQL-nél is ismert tuning az fsync letiltása, ha nagyobb teljesítményt akarsz. De nem ennyire (akár 30 sec, miközben egy terheletlen OS-en az fsync általában 20ms, de nem szokott több lenni 200ms-nél). Az egyik probléma, hogy a firefoxos SQLite túlzásba viszi az fsync-elést "biztonság az első!" felkiáltással. A másik a filerendszerek hiányossága. Így egyben ez már gáz.

--
trey @ gépház

"A másik a filerendszerek hiányossága."
fsync mindig ilyen szar volt ext3-nal, vagy ez ujekeletu problema ?

Az alkalmazasokat hagyjuk, egyertelmuen kernel problema.

Valamint fsync-nek eleg megvarnia mig HDD memoriaba kerul, vagy azt is meg kell varnia mig tenylegesen kiirodik ?
HDD -knek power fail eseten van eleg idejuk kiirni bufferuket ? (Ugyertem HDD tartalekol -e erre nemi energiat)

"Valamint fsync-nek eleg megvarnia mig HDD memoriaba kerul, vagy azt is meg kell varnia mig tenylegesen kiirodik ?"

Ehhez már hardver doksit kell olvasni. Az fsync man-ja szerint "and waits until the device reports that all parts are on stable storage." Nekem az "all parts are on stable storage" azt jelenti, hogy leírja a lemezre :)

Ha jól emlékszem, a kommentekben utalnak is rá, hogy egyes OS-eknél trükköznek is az fsync-kel, vagyis ott nem várja meg, míg megjön a visszajelzés.

"HDD -knek power fail eseten van eleg idejuk kiirni bufferuket ? (Ugyertem HDD tartalekol -e erre nemi energiat)"

Passz. RAID vezérlőknél nincs ilyen, ott nem véletlenül van BBWC modul, azaz Battery Backed Write Cache. Nem hinném, hogy az ócsó lemezekben erre lenne valami.

--
trey @ gépház

( szdl | 2008. 05. 28., sze – 00:48 )

Ez nagyon durva.. Ahogy egyre bonyolultabbak a böngészők (és egyéb programok), egyre több helyen lehet szívás. Nem tudom mi lesz itt 5-10 év múlva. Egyszerűen képtelenség tesztelni minden kombinációt, még akkor sem, ha a fél világ linux/ff felhasználó..

( joco01 v | 2008. 05. 27., k – 14:28 )

eleve az a gáz, hogy nagyon pufferel. desktop gépen annyira nem gáz, ha kicsit sűrűbben ír lemezre, és könnyebben is előfordulhat pl. egy áramszünet, semmi redundancia, tényleg nagy az adatvesztés veszélye. ez egyáltalán nem a firefox hibája

--
joco voltam szevasz

( mikebela777 | 2008. 05. 27., k – 15:34 )

Ha jól értem, akkor az alábbi panaszom is erről szól (?):
http://hup.hu/node/54262#comment-553025 .
Ha igen, akkor jó, hogy megvan a hiba oka. De azért nagyon izé, hogy eféle hibákkal működő béta programokat erőltetnek alaértelmezett verzióként a disztrók.

Pont hogy nem, sőt...

> > I removed the following fcntl call, rc = fcntl(fd, F_FULLFSYNC, 0);. Performance was back to normal.

> ...
> On MacOS X fsync() behaves the same as it does
> on all Unices. That's not good enough if you really care about data
> integrity and so we also provide the F_FULLFSYNC fcntl. As far as I
> know, MacOS X is the only OS to provide this feature for apps that
> need to truly guarantee their data is on disk.

nem, itt nem arrol van szo, csak arrol, hogy az fsync alapbol - a vinyo miatt - nem ir ki semmit a lemezre, de ki lehet flusholni az egesz cache-t egy opcioval. semmi szo nincs arrol ,hogy a filerendszer mit irna vissza a lemezre fsync-kel opciok nelkul(amit vegul a vinyo nem ir ki feltetlenul).

szerk: de konnyen lehet, hogy a darwin is tul sokat ir vissza fsync-nel, hiszen itt epp sebessegproblemakra panaszkodnak

- Use the Source Luke ! -

( mrev | 2008. 05. 27., k – 17:42 )

Szvsz a firefoxban nem bír olyan fontos adat lenni, ami igényelné az fsyncet. Különben sincs arról szó, hogy elveszne az összes bookmark, legfeljebb a változások.

Régen (réges régen) a pgsql-ben is ezt az fsyncet csinálták (ez volt az alapbeállítás), amitől piszok lassú volt. Ettől volt lassab, mint a mysql. Felhagytak vele.

Az ff-nél sokkal fontosabb adatoknál sem alkalmaznám az örökös fsyncet. Akinek nem elég megbízható a Linux, használjon Windózt, vagy használjon olyan alkalmazást, ami tud menteni.

"Megoldás" egyébként nincs.
--
CCC3

De van tisztesegesen meg kell irni az fsync -et.

Egyebkent, csak akkor baj, ha sok olyan adat van a pufferben amit egyebkent nem akarnal syncronizalni.

FF -nel valoszinuleg bongeszo cache lenne az, de onmagaban az nem hiszem, hogy olyan sok , hogy megakasztana a rendszert. De mondjuk, ha kozben torrentezel,rsync-elsz,svn co -zol .. ezzerrel problemas lehet.

Most ezek szerint kvazi sync -et hivaja, fsync helyett.

Lehet, mert az csak egy keres, hogy utemezzen be egy kiirast. Es nem fogja a rendszert a megtortenteig.
Lehet fsysnc -et is lehetne kicsit lazabban venni, es egy beutemzos (+azonnal vissztero) valtozatot is lehetne csinalni, ahol csak az garantalt, hogy nem vegez mas I/O -t a diszken amig new_fsync el nem vegezte a dolgat. (Vagy ASYNC modban tolni.)
De egyebkent is, egy fsync miatt nem kene megalnia az eletnek, mas diskre eppen nem varo folyamat futhatna kozben, de ha jol ertem ez sem igy tortenik.
szerk:
aio_fsync van is.

A magasszintű programoknak (amilyenekről itt szó van), rá kellene bízniuk szinkronizálást az os-re. Amikor nem bízzák rá, akkor zavar támad, mint a példa is mutatja. Egyébként az os magától is szinkronizál, amikor ráér. A szinkronizálás erőszakolása legfeljebb az összeomlás előtti egy-két másodpercben keletkezett adatokat mentheti meg. A szinkronizálás közben is bekövetkezhet összeomlás, azért adatbázis konzisztenciát úgy sem lehet rá alapozni.

Tipikus programozói hiba olyan dolgokba beleturkálni, amivel nem kellene foglalkozni (az adott szinten).
--
CCC3

( colos | 2008. 05. 27., k – 19:18 )

hamar ugyis adatbazisban taroljak az adatokat akkor miert nem lehet pl motort valasztani? tudomasom szerint az sqlite csak helyi gepen mukodik. mas motorral tobb helyrol hasznalva lehetne kozponti helyen tarolni az adatokat. eddig ezt csak trukkozesekkel lehetet megoldani es nem volt teljeskoru (konyvjelzo szinkronizalhato, de pl suti, jelszo, plugin stb mar maceras) esetleg vki tud ilyen fejlesztesrol?

udv Zoli

( vomberg | 2008. 05. 28., sze – 01:47 )

Már bocsánat... DE!

1. Ez nem böngésző hiba, felesleges az IE/FF flame ez ügyben.
2. Az 

fsync()

man page szerint:

The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes in an implementation-defined manner.

Magyarul önmagában az fsync() hívásának nem kéne ilyen idióta következményeinek lennie. Ha nem az SQLite van elkaffantva és hozza függőségi helyzetbe a fél világot a létező file descriptorral miközben bekapcsolja a _POSIX_SYNCHRONIZED_IO-t:

If _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall force all currently queued I/O operations associated with the file indicated by file descriptor fildes to the synchronized I/O completion state.

akkor lehet választani, hogy ez fsync() hiba (nem hinném) vagy filerendszer, azaz kernel környéki hiba. De semmi esetre sem a böngészőé.