Adatvesztést okozhat az APFS
A virtuális meghajtók nem jelzik, ha tele a tár, hiba nélkül zárul a sikertelen biztonsági mentés.
Adatvesztéshez vezethet egy hiba az Apple új, APFS fájlrendszerében. A problémát észlelő és leíró Mike Bombich szerint bizonyos körülmények között a rendszer képes a "semmibe" kiírni az adatokat, minden hibajelzés vagy a felhasználó figyelmeztetése nélkül - ezek az adatok pedig később nem olvashatóak már vissza.
Az APFS nagyon frissnek számít a fájlrendszerek között, élesben tavaly mutatkozott be az Apple ökoszisztémában. A fájlrendszer már kimondottan a flash-alapú tárolók világához készült, a hagyományos társaitól eltérően rengeteg NAND-specifikus feladatot natívan tud megoldani. A cég nagy platformjait, az iOS-t és a macOS-t is átállította már APFS-re, mindkét rendszer friss verziói ezt használják már alapértelmezésben. Úgy tűnik azonban, hogy a fejlesztés nincs még gyerekbetegségek nélkül, ahogy ez az új, igen veszélyes példa is mutatja.
A hibát felfedező Mike Bombich a Carbon Copy Cloner fejlesztője, amely egy biztonsági mentéseket készítő szoftver. A probléma tömören így foglalható össze: egy APFS-t használó virtuális kötet (sparsebundle) rosszul kezeli, ha az alap fájlrendszer kifut az elérhető tárhelyből. A tár kifogyásával az írási műveleteket nem állítja le az APFS, hanem továbbra is fogadja az adatokat, majd a művelet lezárását követően sem panaszkodik sikertelenségre.
A sparsebundle virtuális kötet (lemezkép) formátum, amely felcsatolható az operációs rendszerben, ilyenkor hagyományos meghajtóként működik, írható, olvasható, törölhető a fájlrendszere. A formátum sajátossága, hogy a tartalom méretével együtt növekszik, értelemszerűen az alap meghajtón elérhető szabad kapacitásának határáig. A probléma ott jelentkezik, ha az alap partíció megtelik, a sparsebundle-be pedig tovább írnánk az adatot.
Bombich leírása alapján az I/O tevékenységet közvetítő diskimages-helper alkalmazás hibázik, ennek kellene az Apple architektúrájában figyelnie a rendelkezésre álló tárhelyet, és amennyiben ez elfogy, az új írási műveleteket megtagadnia és hibát (szinte bármilyen hibát) dobnia. Az, hogy ez a hibajelzés nem történik meg, nagyon súlyos problémának számít, a fájlrendszer legfontosabb, szent és sérthetetlen feladata pont az ilyen forgatókönyvek elkerülése.
Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?
Az abszurd (vagy nézőpont függvényében humoros) oldala a fenti problémának, hogy a fájlrendszer metaadatait az alkalmazás úgy frissíti, mintha az írási művelet sikeresen lezárult volna. Tehát ha például új fájlokat másolunk a lemezképre, azok meg is jelennek ott, helyes fájlmérettel, névvel, hozzáférési dátummal, így az egyszeri felhasználó számára egyáltalán nem egyértelmű, hogy az írt adatok fizikailag egyszerűen nincsenek ott. Az már Bombich szerint is "bizarr csavar", hogy egyes esetekben ennek ellenére még a tele lemezre írt fájlok ellenőrző összege (checksum) is talál - a fejlesztő szerint ez valószínűleg a gyorsítótárazásnak tudható be, a fantomadatokat a rendszer valahonnan még vissza tudja olvasni, így a művelet tényleg sikeresnek tűnik.
Fontos megjegyezni, hogy a "normál" APFS köteteket a hiba nem érinti, kizárólag a lemezképek, azon belül is a sparsebundle formátum érintett. A .dmg típusú lemezképek ugyanis fix méretűek, ott helyesen kezeli a rendszer, ha betelt az előre kiszabott hely, a rendes, fizikai APFS partíciók esetében ugyanígy helyesen működik minden.