Názory k článku
Ext4 a Android 2.3
-
rda (neregistrovaný)
A neni to spis poruseni zasad atomicnosti na nizsi urovni? Kdybych napsal driver co posila 512B sektor nadvakrat, a rozhodilo to vyssi vrstvy, ktere ocekavaji ze 512B je atomickych, tak koho je to vina? Samozrejme te nizsi vrstvy, ktera nedodrzuje pravidla. Takze ty flashky prosim opravte.. D.
-
rewtrw (neregistrovaný)
Problemy s "nedodrziavanim pravidiel" sa bohuzial prejavuju aj pri vacsine spotrebnych diskov, ktore vratia stav zapisu ako uspesny uz pred dokoncenim, a pokracuju v zapise asynchronne. To prinasa 2 problemy:
a) spotrebne disky nemaju zalohovane napajanie, takze pri vypadku su nezapisane data stratene (pritom bolo vyssim vrstvam oznamene, ze su zapisane uspesne)
b) vyssia vrstva nema ako vediet, ze bola oklamana. nema inu moznost, ako riadit sa predpokladom, ze data boli zapisane.
Okrem toho zurnalovanie zabezpecuje konzistenciu diskovych struktur, nepredchadza strate dat.
-
rda (neregistrovaný)
Ja taky obcas musim restartnout PC natvrdo, ale vzdy nabehl. Ono je treba byt na to pripraven, a Gentoo to ma relativne dobre zvladnuto - jako /boot vyhradne readonly ext2, takze grub to natahne vzdy, a v initrd je slusny minisystem, se kterym lze opravit v pripade nutnosti hlavni. Bez potreby pouzivat live distro. Jednou jsem to vyuzil, kdyz jsem nedbal na hlasku o nekompatibilite noveho udev se starsim jadrem :)
-
Lukas (neregistrovaný)
Vzhledem k tomu ze google nepouziva journal ani na svych serverech bych rekl ze se bude chtit vyhnout journalu u v Androidu.
Mimoto, to co popisujes neni tak uplne pravda. Rec byla o ztrate dat a ne o nekonzistenci filesystemu. Journalovani te neochrani pred ztratou dat pokud dojde k vypnuti pred commitem.
-
Adam Štrauch se bohužel zase snaží zasvěceně psát o něčem, o čem mnoho neví (tzn. o Androidu). Na tom, že ext4 není souborový systém pro flash paměti, vůbec nezáleží, protože na zařízeních, na kterých bude ext4 v Gingerbreadu nasazen (např. Nexus S), jsou specifika práce s flash pamětí vyřešena nízkoúrovňově prostřednictvím vrstvy zvané Flash Translation Layer, která umožňuje používat na takových zařízeních v zásadě libovolný filesystém pro block devices (a mimo jiné obstarává například i wear leveling funkce, které mají souborové systémy, určené pro low-level flash přístup, jako třeba YAFFS, implementovány v sobě).
Takovou konfiguraci už v současné době používá například Galaxy S, telefon, od kterého je Nexus S s drobnými změnami odvozen, stejně jako další telefony od Samsungu. Na "obvyklých" Android zařízeních funguje práce s NAND pamětí ve vrstvách NAND - YAFFS2 - soubory. Na Galaxy S a podobných je v současné době užíván systém NAND - FTL - RFS - soubory (kde RFS je Robust File System firmy Samsung, proprietární souborvý systém, který je zjednodušeně řečeno FAT32 s dobastleným žurnálem a dokonce se jako FAT32 dá i namountovat). Po změnách, avízovaných v článku, dojde zkrátka jen k posunu na NAND - FTL - ext4 - soubory, čili kromě pozitivních změn, plynoucích z přechodu na ext4, se jinak nezmění vůbec nic.
Strašit čtenáře "možnými pernými chvilkami při náhlém vypnutí telefonu" je nekompetentní a nezodpovědné. Nemluvě o tom, že i v případě, že by tato situace nebyla jakkoliv ošetřena, je potenciální ztráta dat v Android systému v případě výpadku naprosto zanedbatelná - ten systém je jakožto systém pro mobilní zařízení pro zvládnutí takové situace zkrátka od základu navržený. Ostatně, kdyby nebyl, dávno bychom to všichni mnohokrát poznali.
