( uid_194 | 2009. 03. 17., k – 13:10 )

"Egy OS fejlesztesenel az a minimum, hogy amennyiben volt elozmenye az kompatibilis legyen valamilyen modon az elodjere irt alkalmazasokkal. Ezt mar szamos OSnel meg tudtak oldani."

Meg tudtak persze. De a kompatibilitast hurcibalni nem mindig eri meg. Csak azert, mert 10 evvel ezelott volt egy hibas elgondolas, es ezt kihasznaltak/workaroundoltak a programok, attol meg nem kene megorizni a kompatibilitast ezzel a hibaval.

Oke, megvan a hatranya is a dolognak: a programokat ujra kell forgatni, esetleg portolni. Nodehat arrol lenne szo, hogy minimum open source programokrol van szo, tehat az esetek tobbsegeben ez nem okoz gondot.

Az elenyeszo kissebbseg ahol ez nem megoldhato, hat az igyjart. Arra valo az emulacio, hogy regebbi rendszerben lehessen futtatni azokat a dolgokat.

Az emberek szeretik felhozni a windowst, mint OSt ami tokelyre (tulzasba?) vitte a kompatibilitast. Probalj meg egy osi dosos programot futtatni XP alatt, el fogsz csodalkozni neha.

Nincs olyan OS, ami tokeletes kompatibilitast tudna nyujtani, legfeljebb az a nehany, amelynek kifejezetten ez a celja. Az osszes tobbi csak tessek-lassek kompatibilis, feltetelezi, hogy az ember elobb-utobb mar nem fogja mult evezredben irt programokat futtatni rajta. Vagy ha megis, majd hasznal emulatort.

"Hibas felfogas, hogy az alkalmazas iroja szinkronizalja az adatokat, ugyanis egyreszt ez egy belso filerendszer muvelet"

BEEP BEEP.

A rendszer ugy van elkepzelve, hogy te megmondod az OSnek, hogy mit tartalmazzon a file. Amig minden processz aki ezt a filet olvassa, azt a tartalmat latja, amit kell, addig a feladat el van vegezve.

Sehol senki nem mondja, hogy close() utan rogton diszkre is fog kerulni a dolog. Csak annyit mondanak, hogy a file allapota konzisztens lesz, es ha egy masik processz megnyitja, akkor azt az allapotot fogja latni, ami close() utan van, fuggetlenul attol, hogy a memoriabol ki lett-e mar irva lemezre.

Kepzeld el mi lenne, ha minden a szinkronizalas ugy tortenne, ahogy te mondod! Adott egy halozatrol mountolt eszkoz, rajta random filesystem. Ennek a sebessege borzalmasan lassu lenne, ha a filesystem mindig syncelne.

"masreszt mas filerendszerekkel valo kompatibilitast csokkenti. Keszitsen a fejleszto kulon alkalmazast minden filerendszerhez?"

Milyen kompatibilitas? fsync()/fdatasync() megfeleloen alkalmazva minden filesystemen mukodik rendesen.

"A filerendszernek az alkalmazasok felol transzparensnek kell lennie. Egy alkalmazasnak megnyitni, irni, olvasni, bezarni kell tudnia a filet. Az osszes tobbi muvelet a filerendszer sara."

Ez igy is van ext4-nel is. Megnyitod, irsz, olvasol, stb - minden rendben van.

A problema nem ebbol jott elo, hanem abbol, hogy mi tortenik amikor az op. rendszer elcrashel. Amikor elcrashel, nyilvan nincs mar lehetosege syncelni.

Tehat, tobb megoldas van:

1) Az op. rendszer X idonkent syncel (ext3 ezt defaultbol 5 masodpercenkent teszi, ext4 kb 1-2 percenkent). A crash bekovetkezesenek idopontjatol fugg, mennyire lesz sulyos az adatvesztes, de valami szinte biztos lesz.

2) Az op. rendszer folyamatosan syncel. Igy szinte kizarhato az adatvesztes, ellenben fortelmesen lassu lesz az egesz.

3) Az applikaciok segitik az op. rendszert, es megmondjak neki, melyik a fontos adat, amelyiknek mindenkepp lemezt kell ernie mihamarabb. Ez kicsit tobb feladatot ro a program irojara, ellenben sokkal inteligensebb megoldas.

Az OS nem azert van, hogy kitalalja az alkalmazasok helyett, mit kene azoknak csinalniuk. A programoknak igenis az is a feladatuk koze tartozik, hogy segitsek az OS-t a kulonbozo dontesek meghozatalaban (kulonben miert lennenek thread priorityk, meg mindenfele egyeb josag?).

"Az alkalmazasnak nem kell tudnia, mi tortenik a hatterben, es mindenfele korok lefutasa nelkul legyen mindig 100%-ig biztos, hogy az elmentett adatai el is lettek mentve."

Ez ahhoz vezetne, hogy a laptopod kb 10 perc alatt lemerulne. Gratula!