Android 13-telefoon heeft meer opslag over door verplicht nieuw bestandssysteem

Een telefoon die uitkomt met Android 13, zal vermoedelijk meer opslagruimte overhebben dan onder Android 12 en eerder het geval was. Google zou het bestandssysteem Erofs willen verplichten, waar Android nu vooral ext4 gebruikt.

Erofs, Enhanced Read-Only File System, bespaart ruimte ten opzichte van ext4 en levert bovendien hogere leessnelheden op. Op de firmware van een telefoon kan dat al tot 800MB schelen, schrijft Esper.

Google heeft nog niet bevestigd dat het Erofs verplicht stelt, maar in de Android-broncode komt het al diverse keren naar voren. In december vorig jaar sprak een engineer al over de verplichting voor Erofs in Android 13 en intussen wordt gewerkt aan de ondersteuning van Erofs. "Erofs moet ext4 gaan vervangen als het bestandssysteem van read-onlypartities."

Erofs zit in Linux 5.4. Onder meer OPPO en Xiaomi maken al gebruik van het bestandssysteem van vorig jaar. Erofs komt uit de stal van Huawei, waar een engineer het maakte. Het was een functie van Emui 9.1, een softwareversie uit 2019. Huawei claimde toen dat het 20 procent sneller werkte dan ext4 en tot 2GB aan opslag zou kunnen besparen.

Reacties (71)

[SRI]

Wat ik me nu afvraag is of er ook nog nadelen zijn/reden zijn waarom een fabrikant dit liever niet zou willen gebruiken?

Er worden mooie voordelen genoemd (sneller en efficiënter met de ruimte). Maar waarom zou de noodzaak er zijn om het te verplichten als het alleen maar beter is?

En waarom is er de noodzaak om het te verplichten? Geeft het dan problemen als bepaalde fabrikanten het niet zouden doen (klagen mensen dat een telefoon standaard te vol is bijvoorbeeld)?

[Grrrrrene]

Wat ik me nu afvraag is of er ook nog nadelen zijn/reden zijn waarom een fabrikant dit liever niet zou willen gebruiken?

Traditioneel is een nadeel dat je gecomprimeerde data eerst moet uitpakken voor je het kunt lezen, dus het zal de CPU/SOC wat zwaarder belasten en je accu daarmee sneller leegtrekken, maar ik weet niet hoe relevant dit nog is. Aan de andere kant hoeft er minder data gelezen te worden, dus daar bespaar je weer wat energie.

Heel vroeger was dit ook een manier om trage harddisks sneller te maken, door een gecomprimeerd bestandsysteem, hoefde er minder dat gelezen te worden. Ik geloof dat mijn 5,25" Quantum Bigfoot hdd op die manier een fractie sneller te maken was, maar dat is echt "Opa vertelt"... Er wordt hier ook 20% snelheidswinst geclaimd, dus misschien werkt dat inderdaad nog steeds?

Er worden mooie voordelen genoemd (sneller en efficiënter met de ruimte). Maar waarom zou de noodzaak er zijn om het te verplichten als het alleen maar beter is?

Waarschijnlijk omdat het voordeel niet 100% bij de fabrikant ligt en deze dus moeite moet doen en deze wijziging uit de weg zou kunnen gaan als het geen financieel voordeel biedt?

En waarom is er de noodzaak om het te verplichten? Geeft het dan problemen als bepaalde fabrikanten het niet zouden doen (klagen mensen dat een telefoon standaard te vol is bijvoorbeeld)?

Ik heb geen flauw idee, misschien dat de support voor oudere standaarden op termijn vervalt en mensen dan een slechte ervaring hebben als hun fabrikant eigenwijs aan een oude standaard heeft vastgehouden?

Ik mis inderdaad erg veel van dat soort informatie in het bericht. Het klinkt nu nogal marketing-achtig, met alleen maar voordelen. Waarom is dit dan niet eerder bedacht? Waarom verplichten als er geen nadelen zijn...? Terechte vragen zonder antwoord.

[Reactie gewijzigd door Grrrrrene op 23 juli 2024 11:24]

[pepsiblik]

Een switch naar een ander file systeem maakt het upgrade process problematischer. Dus je geeft de consument wat extra opslag, maar de extra kosten voor het migratieproces leg je bij de fabrikant. Niet iedere fabrikant zal daar blij mee zijn.

Waarom het verplicht stellen? Kijk wat er gebeurde bij de laatste architectuur wijziging in Android (het project om Android en de OS Schil van elkaar te scheiden, zodat updates makkelijker konden worden uitgerold.). De helft van de fabrikanten ging niet mee, waardoor dezelfde Android versies verschillende mogelijkheden hadden. En al snel hoorde je de klacht dat Google iets beloofd had, wat de consument in de praktijk niet kreeg. Dat zette kwaad bloed, maar het creerde ook problemen aan Google's kant omdat het probleem wat ze hadden (de langzame uitrol van fixes) maar niet opgelost werd.

[Reactie gewijzigd door pepsiblik op 23 juli 2024 11:24]

[Gadget Freak]

Een switch naar een ander file systeem maakt het upgrade process problematischer. Dus je geeft de consument wat extra opslag, maar de extra kosten voor het migratieproces leg je bij de fabrikant.

Extra opslag geven is niet het doel! Het primaire doel is dat het OS op een read only filesystem staat. Het OS kan dus niet zomaar (door malware) worden gepatcht. Dat is veiliger, maar dat houdt ook in dat OS updates complexer worden. Het gaat meer naar de manier hoe Apple z'n iOS updates uitvoert.

Niet iedere fabrikant zal daar blij mee zijn.

Ze moeten dit een eerste keer goed inrichten, en vooral de migratie van ext4 naar Erofs zal een uitdaging zijn. Ik denk dat er vele telefoons op Android 12 zullen blijven steken.

[HuisRocker]

...
Ik denk dat er vele telefoons op Android 12 zullen blijven steken.

De eerste zin van dit artikel geeft aan dat een Erofs verplichting alleen zal zijn voor:

"Een telefoon die uitkomt met Android 13"

Van 'vele telefoons die op Android 12 zullen blijven steken' zal dan ook geen sprake zijn omdat Android 13 uiteraard ook moet kunnen werken op bestaande telefoons (die nog ext4 gebruiken).

[blorf]

Het bestaande systeem kan dat niet? Dat lijkt me ook niet het doel.

[LNDN]

Extra opslag geven is niet het doel! Het primaire doel is dat het OS op een read only filesystem staat. Het OS kan dus niet zomaar (door malware) worden gepatcht. Dat is veiliger, maar dat houdt ook in dat OS updates complexer worden. Het gaat meer naar de manier hoe Apple z'n iOS updates uitvoert.

Erofs gaat alleen gebruikt worden voor de read-only partities van het OS:

Erofs moet ext4 gaan vervangen als het bestandssysteem van read-onlypartities.

RO partitions heb je nu ook al, maar zijn nu nog gewoon ext4.

[The Zep Man]

Een switch naar een ander file systeem maakt het upgrade process problematischer. Dus je geeft de consument wat extra opslag, maar de extra kosten voor het migratieproces leg je bij de fabrikant. Niet iedere fabrikant zal daar blij mee zijn.

Sommige smartphones maken gebruik van een dubbele-partitie layout voor de vendor/system partities, en ik vermoed dat Android 13 dit gaat verplichten. De set waar niet van geboot is wordt bij een update voorzien van een nieuwe versie. Als die weigert te booten, dan is downgraden altijd nog een optie door simpelweg te booten van de andere (vorige) set. Aanwezige versies zijn dus altijd N en N-1. Bij een upgrade wordt de N-1 set verandert naar N+1 tot de volgende boot, waarna het als N gebruikt zal worden.

Een read-only filesystem kan zo opgebouwd worden:

Bestanden uit oud read-only filesystem + nieuwe bestanden = nieuw read-only filesystem

Dus als je twee plaatsen in het flashgeheugen hebt voor het volledige read-only filesystem, kan je alsnog (kleine) updates doorvoeren, en heb je een manier om een versie terug te gaan als een update mislukt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[xFeverr]

Lijkt mij dat het vooral voor nieuwe telefoons zal zijn die uitkomen met Android 13. Tenminste, dat haal ik uit de eerste regel van het artikel:

Een telefoon die uitkomt met Android 13, zal vermoedelijk meer opslagruimte overhebben dan onder Android 12 en eerder het geval was.

Maar dat komt in de rest van het artikel niet zo duidelijk terug. Mijn aanname is dan ook vooral dat: een aanname.

Maar goed, overstappen naar een ander bestandssysteem hebben we toch al vaker gedaan in de geschiedenis?

[RAAF12]

MSDOS 3.3 FAT16 FAT32 NTFS OS/2 zit nu op Windows 11 64 bit. Waar telefoons op draaien hou ik niet zo mee bezig. Ik weet wel dat bij het draaien van chkdsk lost clusters veel voorkwamen maar dat kan ook aan de disk gelegen hebben.

[watercoolertje]

Heel vroeger was dit ook een manier om trage harddisks sneller te maken

Precies, en nog een bekendere manier is denk ik downloads, ook voor snelheid (paar MB minder downloaden kon zo uren schelen, en uitpakken duurde dan misschien 10 minuten langer) en vanuit de server opslag en dataverkeer te besparen.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 11:24]

[supersnathan94]

Windows gebruikt dit standaard voor file transfers. External differential compression. Iets wat ik bij default uitzet omdat het best veel van een CPU vraagt en als die al flink bezig is je dus een enorme hit krijgt op performance. Zeker met externe SSD’s gaat het rap.

[Raphaelo]

Kan je hier wat meer over kwijt? Als ik google op 'External differential compression' vind ik niets. Ben wel nieuwschierig.

[Mayco]

Het is Remote Differential Compression. Zie https://docs.microsoft.co...-differential-compression

[supersnathan94]

Klopt, Ik dact dat ik m'n post ge-edit had gisteren, maar heb ik niet gedaan

[Admiral Freebee]

Erofs gebruikt een compressiemethode die vrij snel werkt bij het uitpakken. Het is een beetje een trade off tussen ruimtegebruik, leessnelheid (van de storage), uitpaksnelheid en energieverbruik.

[jimshatt]

Op oude harddisks was leessnelheid inderdaad een bottleneck maar ik kan me niet voorstellen dat dit op moderne telefoons het geval is. Ik kan me inderdaad nog tools herinneren zoals Stacker, maar ik heb me er nooit aan gewaagd.

Zoals ook vroeger met Stacker, en nu dus met EROFS, kun je met transparant compression niet altijd winst behalen. Bestanden die al uit zichzelf gecomprimeerd zijn of andere data met veel entropie kunnen gewoonweg niet verder gecomprimeerd worden. Nu is het doel van EROFS denk ik om alleen het OS gedeelte te bevatten, en dat is natuurlijk prima haalbaar.

[Aaargh!]

Heel vroeger was dit ook een manier om trage harddisks sneller te maken

Niks heel vroeger. Moderne games doen dit nog steeds om dezelfde reden, alleen in plaats van dat je het hele filesystem comprimeert zijn de files van een game gecomprimeerd.

Zelfs bij supersnelle SSD's is dit een voordeel. De PS5 bijvoorbeeld heeft een SSD die 5.5GB/s kan lezen, maar na (hardware) decompressie lees je effectief 8-9GB/s.

[Anoniem: 57381]

Dat ging toch met het programma Stacker en die was toch vooral bedoeld om je meer schijfruimte te geven door alles te comprimeren? Extra snelheid gaf het volgens mij niet echt.

[ioor]

Idd. Mijn oude hd van 25Mb werd ineens 34 Mb. Briljante tool voor die tijd. Maar voor snelheid had je niks te maken met een 286...hooguit als je turboknop had.

[Anoniem: 57381]

Ach ja, die turbo knop, dat was ook zo'n mooi fenomeen. Ding was bedoelt om programma's te vertragen (turbo uit) die niet gemaakt waren voor 'snelle' computers. Van 24Mhz ging je zo terug naar 12MHz.... #nostalgie

[D-Three]

Heel vroeger was dit ook een manier om trage harddisks sneller te maken, door een gecomprimeerd bestandsysteem, hoefde er minder dat gelezen te worden. Ik geloof dat mijn 5,25" Quantum Bigfoot hdd op die manier een fractie sneller te maken was, maar dat is echt "Opa vertelt"... Er wordt hier ook 20% snelheidswinst geclaimd, dus misschien werkt dat inderdaad nog steeds?

Wow, dit was ik helemaal vergeten. Maar als ik de screenshot van DoubleSpace/DriveSpace zie, dan herken ik het onmiddellijk Al heb ik het nooit gebruikt om mijn drive sneller te maken maar om echt wel meer plaats te hebben.

[jimh307]

In de whitepaper staat dat er gebruik wordt gemaakt van LZ4 compressie; een zeer licht algoritme met zeer vlotte decompressie. LZ4 (Lempel-Ziv 4) zie je ook terug bij ZFS en BTRFS en belast de CPU niet veel.
Elke vorm van compressie heeft een impact op batterijduur, maar de baten moeten gewogen worden versus opslagbesparing en batterijduur. Ook wordt Flash steeds minder belastend voor de batterij omdat er minder energie nodig om Flash uit te lezen.
Het is een read-only bestandssysteem dus kost het nóg minder stroom.
De baten zullen wel aangetoond hebben dat het verlies van kostbare stroom niet opweegt tegen de toegenomen snelheid en opslagruimte.

Zelf ben ik tegen compressie (vooral op NVMe SSD's) en bij NVMe wordt het systeem hoe dan ook trager omdat de CPU de datastroom niet live kan uitpakken. Daar is NVMe te snel voor. In een telefoon zullen de kaarten wellicht anders liggen.

Toch is compressie overal. Foto's, video's, muziek zijn al reeds gecomprimeerd en een telefoon moet daar ook mee omgaan, dus ik verwacht dat het totaalplaatje nauwelijks invloed heeft op de batterijduur. Het lezen is eenmalig bij opstarten.

Windows comprimeert zichzelf als het OS dat nodig acht..

@Grrrrrene De compressie en decompressie op een trage harddisk is sneller omdat de harddisk zo traag was in die tijd. LZ4 is lichter dan LZ77 (DriveSpace, DoubleSpace) en de opslag is veel en veel sneller geworden. In het verleden behaalde resultaten bieden geen garantie voor de toekomst

[DamirB]

OnePlus gebruikt het al een tijdje. Ik heb het via een custom rom ook al een tijdje op mijn toestel. Disk leessnelheid (sequentieel) verdubbeld ten opzichte van een stock OnePlus 7 Pro. Sowieso net stukje vlotter door het hele systeem heen. Heb ook qua batterijduur geen nadeel ondervonden sinds de switch naar erofs. Wat wel zo is is dat de kernel aangepast moet worden. Meeste stock (en zelfs custom) kernels kunnen niet met erofs overweg

[Argantonis]

Wat ik me nu afvraag is of er ook nog nadelen zijn/reden zijn waarom een fabrikant dit liever niet zou willen gebruiken?

Er worden mooie voordelen genoemd (sneller en efficiënter met de ruimte). Maar waarom zou de noodzaak er zijn om het te verplichten als het alleen maar beter is?

En waarom is er de noodzaak om het te verplichten? Geeft het dan problemen als bepaalde fabrikanten het niet zouden doen (klagen mensen dat een telefoon standaard te vol is bijvoorbeeld)?

Een nadeel dat er bijna altijd is, is dat het initieel geld kost om te migreren. Er is ook echt 0 reden voor dat nog zoveel bedrijven op Java 8 zitten, als je ervan uit zou gaan dat men met een schone lei zou kunnen beginnen. De reden is dat de migratie geld kost.

[The Zep Man]

Wat meer technische informatie over EROFS op Wikipedia. Qua werking is het vergelijkbaar met CramFS en SquashFS, waarbij laatstgenoemde o.a. bekend is in de *WRT wereld.

Die extra opslag verkrijgt men via compressie, wat efficiënt te doen is met een bestandssysteem dat je maar éénmaal opbouwt en nooit meer wijzigt. Als je 800 MB kan besparen, dan kan je al nagaan hoeveel bloat er in het OS moet zitten. Om het in vergelijking te plaatsen: LineageOS is gecomprimeerd ongeveer 800 MB, en zonder compressie minder dan 900 MB.

De compressie lijkt mij niet het primaire doel, gezien hoe goedkoop flash geheugen vandaag de dag is.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[robvanwijk]

Die extra opslag verkrijgt men via compressie, wat efficiënt te doen is met een bestandssysteem dat je maar éénmaal opbouwt en nooit meer wijzigt. Als je 800 MB kan besparen, dan kan je al nagaan hoeveel bloat er in het OS moet zitten.

Bloat en comprimeerbaarheid hebben zo ongeveer niets met elkaar te maken. Stel dat een fabrikant een 4k 120 fps animatie gebruikt voor de opstart-video (dat ding dat je vrijwel nooit ziet en de keer dat je het ziet maakt de kwaliteit niet uit. Is dat comprimeerbaar? Nee, want filmpjes worden sowieso al gecomprimeerd opgeslagen, dus daar valt geen verdere winst te behalen. Is dat bloat? Ja, dat denk ik wel. Maar als een fabrikant een uitgebreid help-systeem inpakt (dus met veel tekst), dan comprimeert het prima, maar ik zou het geen bloat noemen.
Als een readonly versie veel kleiner is dan de "gewone" indeling, dan kun je alleen zeggen dat er veel comprimeerbare data in de image zit en/of dat er veel data dubbel inzit (compressie zou meteen de-dupe kunnen doen). Hoe nuttig de data is, daar kun je niets over zeggen.

[Xander2]

De compressie lijkt mij niet het primaire doel, gezien hoe goedkoop flash geheugen vandaag de dag is.

Flash geheugen in smartphones is traag, je haalt aanzienlijke snelheidswinsten met compressie omdat huidige SOCs meer dan snel genoeg zijn, los van de resources dat een sterk versimpeld FS scheelt.

Ik kan me ook voorstellen dat ze hiermee een vorm van beveiliging proberen te maken.

[SilentDecode]

Enhanced Read-Only File System, bespaart ruimte ten opzichte van ext4 en levert bovendien hogere lees- en schrijfsnelheden op.

Ik vind het knap hoe de überhaupt kunnen schrijven op een read-only filesystem.

En ik blijf het dom vinden dat fabrikanten de opslag van een telefoon "ROM" blijven noemen. Het is geen ROM, omdat je er ook naartoe kan schrijven.

[The Zep Man]

Ik vind het knap hoe de überhaupt kunnen schrijven op een read-only filesystem.

Een alleen-lezen bestandssysteem wordt éénmaal opgebouwd. Kennelijk gaat dat vlotter dan een conventioneel bestandssysteem vullen. Men kan ook refereren naar het distribueren van een image met daarin het bestandssysteem, dat direct als blob wordt weggeschreven. Dat is uiteraard vlotter dan op de smartphone individuele bestanden uitpakken en naar een conventioneel bestandssysteem wegschrijven.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[SilentDecode]

Een alleen-lezen bestandssysteem wordt éénmaal opgebouwd

Maar dan spelen ze eigenlijk dus vals. Want als ik het OS update van m'n telefoon, via OTA of anders, zou hij hier dus niet naartoe moeten kunnen schrijven, omdat het zogenaamd een ROM zou zijn.

Ik ben van mening dat we van de naam 'ROM' af moeten bij telefoons, want écht ROM is het niet.
Laten we 'ROM' maar gewoon alleen gebruiken voor de toepassingen waarbij een IC met iets communiceert waarvan de firmware in een ROM staat.

[The Zep Man]

Maar dan spelen ze eigenlijk dus vals. Want als ik het OS update van m'n telefoon, via OTA of anders, zou hij hier dus niet naartoe moeten kunnen schrijven, omdat het zogenaamd een ROM zou zijn.

ROM staat voor read-only memory. Met andere woorden, het opslagmedium is alleen-lezen.

Dit betreft een alleen-lezen bestandssysteem. Het opslagmedium is lezen-schrijven, en je kan een (alleen-lezen) bestandssysteem vervangen met een ander als het opslagmedium het toestaat (en in Android: de beveiliging/de bootloader).

Ik ben van mening dat we van de naam 'ROM' af moeten bij telefoons,

De term wordt soms informeel gebruikt voor hoeveel opslagruimte aanwezig is (RAM/ROM: 8GB/128GB). Ik zie het nauwelijks formeel gebruikt worden. Lijkt mij niet zo'n punt. Maar dit is off-topic, want het gaat niet om het opslagmedium.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[jimshatt]

Ik stel WOROM voor, Write-once read-often memory (eigenlijk storage).

[Skix_Aces]

Dat bestaat al: PROM (Programmable Read-Only Memory). Deze kan je 1x programmeren waarna de contents alleen nog maar te lezen zijn.

Verder heb je EPROM (Erasable Programmable Read-Only Memory) waarbij de contents van de geheugenbanks meestal via een kijkglaasje op de chip verwijderd konden worden als er UV licht op de chip viel. Hierna kon de chip weer hergeprogrammeerd worden.

Tot slot is er EEPROM (Electrically Erasable Programmable Read-Only Memory). Hierbij kunnen alle geheugen adressen elektronisch gewist worden waarna er weer naar geschreven kan worden, eigenlijk wat de opslag van vandaag ook is.

[Zer0]

En flash memory (zoals oa in telefoons en usb-stick zit) is weer een doorontwikkeling van EEPROM.
Flash memory (or simply flash) is a modern type of EEPROM invented in 1984. Flash memory can be erased and rewritten faster than ordinary EEPROM, and newer designs feature very high endurance (exceeding 1,000,000 cycles). Modern NAND flash makes efficient use of silicon chip area, resulting in individual ICs with a capacity as high as 32 GB as of 2007; this feature, along with its endurance and physical durability, has allowed NAND flash to replace magnetic in some applications (such as USB flash drives). NOR flash memory is sometimes called flash ROM or flash EEPROM when used as a replacement for older ROM types, but not in applications that take advantage of its ability to be modified quickly and frequently.

Dus ROM is een juiste benaming voor dat gedeelte van de opslag.

[jimshatt]

Wel cool dat dat in 1984 al ontwikkeld is terwijl wij gewone mensen toen nog met floppies aan het klooien waren.

[uiltje]

Ik zou me daar niet te veel bij voorstellen want die chips hadden bijna geen capaciteit en waren tevens behoorlijk traag. Sowieso bestonden (ROM) cartridges toen allang, en die cartridges waren direct op de memory controller aangesloten en konden ook dingen als accelerators, sound chips etc. bevatten. Merk ook op dat de endurance flink naar beneden is gegaan (dus let op hoe je je memory stick gebruikt, voor herschrijfacties wil je echt een SSD).

[wankel]

Ik stel WOROM voor, Write-only - read-often missed (eigenlijk /dev/null).

Op Aliexpress kun je WOROM-SD-kaartjes krijgen, ze zijn meestal voordeliger dan de reguliere.

[Yveske1966]

Dat geeft dan weer problemen in België want worom betekent waarom in het Brugs dialect.

[captain007]

Je hebt natuurlijk ook programmeerbare ROM. Wat dat betreft is het gewoon een stuk firmware wat in die zin statisch is dat het niet veranderd bij iedere boot of tijdens dat je het device gebruikt, behalve als er een firmware update wordt geïnstalleerd. En echt klassieke ROM's zie je tegenwoordig bijna nooit meer, omdat dat gewoon zeer onhandig is als je bugfixes wilt toepassen. Dat de term ROM dan niet helemaal meer strikt volgens de definitie klopt is dan beetje arbitrair. Ik denk dat er weinig nog klassieke ROM's worden toegepast die helemaal niet bij te werken zijn, zonder dat je een chip fysiek moet vervangen. En dan heb je natuurlijk ook nog de ontwikkeling dat je tegenwoordig SoC's hebt die iets doen wat vroeger in allemaal losse chips werd gedaan. Dus in dat opzicht is er al veel minder sprake van een klassieke ROM wat nog echt als zodanig als losse IC aanwezig is. Met ROM doelt men tegenwoordig gewoon op het feit dat het een stukje geheugen is wat in normale operatie niet te beschrijven is. Mijn inziens is die definitie van ROM prima en duidelijk. Het is geen geheugen waar je even wat naartoe kan schrijven, behalve als je in een speciale update modus zit o.i.d.

[watercoolertje]

Het slaat toch op een laag bovenop de drager van die data (namelijk het bestandssysteem van een partitie op een drager)? Het zegt dus niks over de onderliggende mogelijkheden van de drager.

Ik kan in windows een bestand ook read-only maken, maar kan die actie ook gewoon ongedaan maken! Toch is dat zo lang als ik wil/bepaal read-only.

Read-only in de letterlijke zin is zinloos want dan staat er dus ook geen initiële data op

Volgens mij slaat read-only sowieso meer op het uitgangspunt, dan de letterlijke betekenis, het is (semi) vaste data die niet (of zelden) wordt herschreven. Zola inderdaad je BIOS, of firmware op randapparatuur.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 11:24]

[supersnathan94]

Ook ROM is beschrijfbaar by default. Hoe krijg je anders de data erop?

In alle gevallen is het “write once, read many”

Kunnen we dus beter “WORM” noemen

[Plofkotje]

Moderne ROM's wel, ouderwetsche ROM's (mask ROM's) worden op dezelfde manier gemaakt als andere IC's, met de data erop belicht tijdens de lithografie stap. Daarom komt uit het verleden de term ROM en niet WORM.

[_hennes]

Bij moderne ''ROM'' wel, bij klassieke ROM niet. Toen lag de data vast tijdens het maken van de chip.

Daarna kregen we idd PROMs, EPROMS, EEPROMS, ....

(1x Programmeerbaar, wisbaar met UW licht en (her) programmeerbaar, electrisch wisbaar en weer programmeerbaar)

En we hebben optische media die je een keer kan beschijven... WORM.

[rob12424]

Heeft dat erofs ook een journaal zoals Ext4? Anders zou ik eerder bij Ext4 blijven namelijk.

[beerse]

Een read-only filesysteem heeft in de regel geen wijzigingen. Daarmee heeft ze ook geen transactie-journal nodig.

[pietje63]

Toch bijzonder: Huawei heeft te maken met diverse bans (Google Services, infrastructuur), maar ze besluiten wel over te stappen op een door hen ontwikkeld FS?

NFI en waar het OS ga ik er vanuit dat er voldoende audits op zijn uitgevoerd (hoewel dat bij zeer veel of complexe code ook makkerlijke is gezegd dan gedaan), maar het bevreemd me wel.

[The Zep Man]

Toch bijzonder: Huawei heeft te maken met diverse bans (Google Services, infrastructuur), maar ze besluiten wel over te stappen op een door hen ontwikkeld FS?

Waarom niet? Het is uitgegeven onder de GPLv2, en kennelijk zitten er geen patenten op (of zijn ze vrijgegeven door Huawei). Je kan dus niet spreken over 'handel'. Download en gebruik van software onder een vrije, publieke licentie wordt niet gezien als een transactie en kent daarom geen beperkingen.

Zo is ook bijvoorbeeld Btrfs deels ontwikkeld bij/door Facebook en komt zstd ook bij Facebook vandaan. Laatstgenoemde wordt bijvoorbeeld gebruikt voor compressie van Arch Linux packages. Dat houdt niet in dat Facebook daar ook maar iets over te zeggen heeft, of dat het op een manier (juridisch/economisch) verbonden is met Facebook. Andersom is Facebook niet verantwoordelijk voor (het gebruik van) deze technieken. Hetzelfde met Xiaomi en EROFS.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[boschhd]

Je kunt het hier op github reviewen: https://git.kernel.org/pu...rnel/git/xiang/erofs.git/

[The Zep Man]

Je kunt het hier op github reviewen: https://git.kernel.org/pu...rnel/git/xiang/erofs.git/

Dat is geen GitHub, chief.

[boschhd]

Ok.
Kernel.org dan.
Lieverd?

[Reactie gewijzigd door boschhd op 23 juli 2024 11:24]

[Ikzellef]

Viel mij ook op. Maar hoogstwaarschijnlijk is dat een van de redenen voor de ban, er zitten daar lui die het beduidend beter doen dan de Amerikanen. Niks spionage, alleen markt bescherming. Maar uiteindelijk schieten ze in hun eigen voet.

[DataGhost]

Waarom bespaart simpelweg het wisselen van het type filesystem genoeg ruimte om een nieuwsbericht te rechtvaardigen? Wat is "meer opslagruimte"? Ik zou verwachten dat dit procentueel een single-digit verbetering is. Blijft nog wel het probleem bestaan voor toekomstige updates, die zouden zomaar groter kunnen zijn waardoor die ruimte alsnog gereserveerd moet zijn in de partitietabel, waarmee het hele voordeel vanuit het perspectief van de user weer weg is, die gaat er qua ruimte niet op vooruit. Of zijn er hier meer dingen aan de hand die niet in het artikel genoemd zijn?
Edit: puur vanwege compressie dus. Ik las in eerste instantie de 800MB als 800MB/s omdat het net daarvoor over snelheden ging.

[Reactie gewijzigd door DataGhost op 23 juli 2024 11:24]

[ToolBee]

Kunnen er weer wat meer SMSjes op blijven staan.

[ejabberd]

Voor zover ik weet krijgt Android 13 geen ondersteuning voor de originele Nokia 3310.

[ToolBee]

Gewoon een skin...

Wordt je droid meteen onbreekbaar!

[abusimbal]

Is waar ik aan denk en op dit moment niets over kan vinden.
Hoe zit het als ik mijn S22 wil upgraden van Android 12 naar 13 ?
Als EROFS verplicht wordt, moet dan alles gewist worden omdat je van bestandensysteem veranderd ?
Of kan je wel je data behouden ?

[The Zep Man]

Is waar ik aan denk en op dit moment niets over kan vinden.
Hoe zit het als ik mijn S22 wil upgraden van Android 12 naar 13 ?

Waarschijnlijk geldt de verplichting alleen voor nieuwe toestellen die met Android 13 worden uitgegeven uit de fabriek. Zo ging het in het verleden ook met veel nieuwe Android zaken. Android 13 houdt dus zelf wel gewoon ondersteuning voor het gebruik van ext4 bestandssystemen.

Of je data behouden wordt of niet ligt aan de fabrikant. Vaak kan het bij officiële software van de grote fabrikanten wel.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 11:24]

[beerse]

Er zijn wel vaker filesystem migraties gedaan bij upgrades en updates. Zeker bij een zekere mate van compatibiliteit is dat wel te doen. Je zou het tot op zekere hoogte kunnen vergelijken met het comprimeren van een disk terwijl je er mee bezig bent. Dat gaat op msWindows zelfs on-the-fly.

[Polderviking]

Leuke ontwikkeling op zich, hoop niet dat het al te veel nare consequenties heeft voor homebrew maar ik heb me ook helemaal niet ingelezen hierop verder.

Als je toch met ruimte bezig bent, veto gelijk ingebakken applicaties.

Als die poeha die er op een beetje budgetphone, of zelfs premium phone (hoi Samsung) meegleverd wordt en vervolgens alleen via ADB weer weg krijgt is echt een smet op een andersinds schone android ervaring.

[Sando]

De versleuteling van Android werd tot nu toe gedaan door fscrypt, een ext4 feature in de Linux kernel. Veel Linuxgebruikers hebben het ook geactiveerd op hun Desktop-omgeving met deze gelijknamige tool die wordt onderhouden door Google, omdat het sneller is dan het oude LUKS of het matige ecryptfs dat Ubuntu vroeger gebruikte, en het verschillende gebruikers op de zelfde hardware ondersteund.

Wat gebeurt hiermee? Ah, het is alleen voor read-only partities. Die waren al niet versleuteld.

[Reactie gewijzigd door Sando op 23 juli 2024 11:24]

[Jace / TBL]

Hoe zit dat eigenlijk met die versleuteling op Android, wordt de key daarvan afgeleid uit je pin of unlock code?

Is dat niet makkelijk te brute forcen? Want als je een code van 6 cijfers hebt, heb je hooguit 10⁶ = een miljoen pogingen nodig.

[Sando]

Een pincode is inderdaad de minst veilige optie. Vooral een code van slechts 4 cijfers is onverstandig. Je kunt beter een swipe-patroon maken op een 6x6 grid of meer als je telefoon dat ondersteunt.

Maar het is misschien ook weer niet zo onveilig als je denkt. Niemand gaat een miljoen pogingen doen op de telefoon. Dan kopieert de inbreker liever de versleutelde data om deze op een andere computer te ontsleutelen. Maar nu komt het:

Die data is versleuteld met een 256-bit sleutel. En die sleutel zit in een chip op je telefoon, genaamd eSE (embedded Secure Element), of Secure Enclave op een iPhone. Die chips zijn speciaal ontworpen om niet uitgelezen te kunnen worden.

Tenzij je een goedkope telefoon hebt. Grofweg de 20% goedkoopste smartphones hebben geen eSE. Data op deze telefoons is dan ook vaak niet versleuteld. Het lock screen is hier meer tegen glurende ogen uit je eigen omgeving, maar een gemotiveerde instantie kan alles relatief makkelijk uitlezen.

[Urshurak]

Op mijn Pixel 6 met 13 b2 en 5 mei update staat f2fs (tenminste, volgens DiskInfo). Hoe zit dat dan?

[Reactie gewijzigd door Urshurak op 23 juli 2024 11:24]