Google gaat nieuw bestandssysteem toch niet verplichten op Android 13

Google heeft ervoor gekozen om Enhanced Read-Only File System, erofs, toch niet te verplichten voor nieuwe telefoons met Android 13. Het gebruik van ext4 en f2fs blijft mogelijk, zo blijkt uit een nieuwe commit.

Google heeft de vereisten voor het gebruikte bestandssysteem versoepeld, zo zegt het zelf. Het is onduidelijk waarom Google dat gedaan heeft. Degene die de commit heeft gevonden, Mishaal Rahman van Esper, zegt ook niet te weten waarom het bedrijf na maanden van voorbereidingen de vereisten ineens heeft gewijzigd.

De vereiste kwam vorige week naar buiten. Door erofs te gebruiken kunnen fabrikanten ruimte besparen op read-only partities van de firmware van telefoons. Bij sommige toestellen scheelt dat tot 800MB. Het zou bovendien de software sneller laten werken. Het is onbekend welke nadelen er zijn aan gebruik van erofs. Er is een kans dat het gebruik van erofs de processor meer belast en daardoor ook iets meer zou vragen van de accu, maar daar zijn geen cijfers over.

Google heeft niet op de kwestie gereageerd. De vereisten voor Android 13 wijzigen nog, omdat het besturingssysteem in bèta is. De bedoeling was dat erofs verplicht zou zijn voor telefoons die uitkomen met Android 13. Huawei ontwikkelde erofs enkele jaren geleden. Ook OPPO en Xiaomi hebben het al gebruikt op telefoons.

Google Android-broncode: toch geen erofs-verplichting in Android 13

Reacties (15)

[Admiral Freebee]

Door erofs te gebruiken kunnen fabrikanten ruimte besparen op read-only partities van de firmware van telefoons. Bij sommige toestellen scheelt dat tot 800MB. Het zou bovendien de software sneller laten werken. Het is onbekend welke nadelen er zijn aan gebruik van erofs. Er is een kans dat het gebruik van erofs de processor meer belast en daardoor ook iets meer zou vragen van de accu, maar daar zijn geen cijfers over.

De grote reden hiervoor is dat EROFS compressie toepast. Dat spaart uiteraard ruimte maar je kan ook een groter blok uitlezen, uitpakken in het geheugen en daar kleine bestanden gaan zoeken. Zo kan je sneller werken bij opslag die relatief traag is bij random io en kleine bestandsgroottes maar die wel relatief snel is bij sequentieel lezen.

EROFS heeft ook een soort van alfabetische index om het opzoeken van bestanden efficiënter te maken. Dit is makkelijker toe te passen omdat het bestandssysteem specifiek ontwikkeld is geweest voor read only partities. Het nadeel van het systeem is dat je bij elke leesactie moet gaan decomprimeren. EROFS gebruikt een vrij efficiënt algoritme qua rekenkracht (LZ4) maar het is toch een extra stap die merkbaar zou kunnen zijn op het vlak van prestaties en energieverbruik. Het zou interessant zijn om hier cijfers van te hebben maar mogelijk zijn de verschillen te klein om significant meetbaar te zijn.

Overigens nog een interessant weetje: EROFS werd ontwikkeld door Huawei met als specifiek doel om het voor de Linux kernel te gebruiken.

[Reactie gewijzigd door Admiral Freebee op 25 juli 2024 03:59]

[Maurits van Baerle]

Ik weet helemaal niets van EROFS maar ik weet dat voordat Zstandard (Zstd) geïmplementeerd werd in OpenZFS er uitgebreid getest is qua impact op prestaties. Aangezien Zstd krankzinnig snel is (nog sneller dan LZ4, een ouder project van Yann Collet, de man achter Zstd) zijn het de leessnelheden van de SSD die de bottleneck zijn, niet de processorverwerkingssnelheid.

Kortom, aangezien je bij dit soort snelle decompressors voor het decomprimeren dus moet wachten op de SSD voordat die een volgende block data kan leveren zie je dat per saldo de snelheid omhoog gaat door het gebruik van dit soort compressie. Als je 30% minder data moet inladen is dat dus ook grofweg 30% sneller dan als je het ongecomprimeerd zou doen.

Het comprimeren gaat vaak langzamer (bij Zstd bijvoorbeeld 400 MByte/s comprimeren vs 1500MByte/s decomprimeren) dus je ziet dit vooral van toepassing zijn in NAS opslag en dergelijke, of read-only filesystems dus.

[Reactie gewijzigd door Maurits van Baerle op 25 juli 2024 03:59]

[N8w8]

Dat is mss zo, maar los van snelheid kan decompressie ook extra energie kosten.
Lijkt mij dat bijna alle ZFS machines aan netstroom hangen, dan boeit dat veel minder.
Nou ken ik ZFS niet, maar iig bij btrfs kan je alsnog zelf kiezen of en welke compressie je wilt.
Terwijl het in dit geval gaat over machines die primair op accu draaien, en dan de vraag of die allemaal compressie moeten gebruiken.
Daarbij is het meer een afweging tussen snelheid en accuduur lijkt mij.
Tot 800MB op een ROM van tig GB(?) is leuk, maar ook weer niet zo spectaculair.
En het is mss toch al snel genoeg, tenminste, ik hoor niet veel klachten over trage opslag.
Over accuduur hoor ik iig veel meer klachten. Als het accuduur nadeel dan maar groot genoeg is, kan ik me voorstellen dat dat het niet waard is.

[d3burt]

Ik verwacht dat de verminderde I/O meer stroom spaart dan de decompressie kost. Het stroomverbruik van een actieve SSD is aanzienlijk.

[Maurits van Baerle]

Dat is een goed punt inderdaad, je zult in de praktijk moeten kijken hoe het uitpakt. Data uitlezen kost natuurlijk ook stroom dus als je minder data hoeft te lezen bespaart dat. Maar, als het decomprimeren meer energie kost dan de besparing door de verminderde data dan heeft het een netto negatief effect op de accuduur inderdaad.

[Jerie]

Yeah maar SSD (NVMe) is niet van toepassing bij Android 13 apparaten, muv een dev laptop.

[Maurits van Baerle]

Oh vast, maar die alternatieven zullen allemaal langzamer zijn. Dan is de decompressie dus al helemaal de bottleneck niet.

[sapphire]

Zou doordat de opslag en software efficiënter/sneller kunnen werken dat niet het extra vermogen wat nodig is omdat er meer rekenkracht nodig is compenseren?

Ofwel hoger vermogen voor kortere tijd waardoor het netto verbruik hetzelfde of eventueel lager (of juist alsnog hoger) uitkomt? Dit lijkt me interessant om te testen en kan fabrikanten de mogelijkheid geven waar de nadruk te leggen bij een device. Besparen op snellere opslag door EROFS maar wel een zuinigere CPU gebruiken of andersom bijvoorbeeld.

[Admiral Freebee]

Dat zou goed kunnen maar besparen op opslag blijft een moeilijke operatie want dit heeft ook invloed op de snelheid waarmee apps en de rest van je systeem werkt. EROFS wordt namelijk enkel toegepast op de read only systeempartitie en is niet van toepassing op de rest van het bestandssysteem.

[Morkatog]

Thanks! Lijkt mij een mooie voor een verdiepend artikel om nog iets dieper in te duiken.

[CAPSLOCK2000]

EROFS gebruikt een vrij efficiënt algoritme qua rekenkracht (LZ4) maar het is toch een extra stap die merkbaar zou kunnen zijn op het vlak van prestaties en energieverbruik.

Ervaring met andere filesystems suggereert dat het zelfs sneller zou kunnen zijn. Door de compressie hoef je minder data in te lezen en te verplaatsen. Moderne processoren kunnen sneller decomprimeren dan de storage de data kan aanleveren en met al die cores heb je altijd wel ergens een plekje over om het te doen. We hebben inderdaad benchmarks nodig om te zien hoe snel het echt is maar mijn verwachting is dat het met compressie sneller is dan zonder.

[P1nGu1n]

@arnoudwokke Mishaal Rahman werkt al 7 maanden niet meer bij XDA-Developers
Zie: https://twitter.com/MishaalRahman/status/1446492544163004422

[arnoudwokke]

Oh, dat wist ik niet, dank je wel! Aangepast

[beerse]

De efficiëntie is dat er meer software (junk?) op de zelfde opslag van een nieuw systeem kan/past.
Voor een update zou het in theorie ook beter/sneller/makkelijker moeten gaan maar dan moet er wel met een actief/passief systeem gewerkt worden en dat gooit dan meteen de effectiviteit van diskruimte te niet. Bij android zie ik dat nog niet gebeuren, bij chrome-os is dat al wel standaard.

Voor het lezen is het in theorie van disk trager dan vanaf geheugen en daar zou winst gehaald kunnen worden omdat er minder gelezen hoeft te worden. Maar er is wel meer geheugen (buffer) en cpu (decompressie) nodig. Als ik naar de snelheid van de opslag van tegenwoordig kijk, zie ik steeds minder snelheidsvoordeel.

Tel daar bij dat op een mobiel toestel zowel geheugen als cpu ook niet onbeperkt beschikbaar zijn, zie ik ook geen voordeel in de readonly compressie van zo'n filesysteem.

Voor ons tweakers is er wel een nadeel: Het wegwerken van ongewenste zaken wordt wel veel moeilijker...

[oeps]

Op zich mooi/lelijk/humor afhankelijk van je mening, dat Google nu iets van Huawei gaat gebruiken maar de Play store, etc is verbannen van Huawei door US sancties. Huawei zal EROFS wel als open-source hebben ontwikkeld. Uiteraard is Play store niet open-source en dus geen vergelijkbare situatie.
Vraag me af of ze het bij Huawei als humor zien.. of mooi-lelijk!