@ Peter Villevoye: voor na je Bavaria-moment
...
HFS Plus is een verbeterde versie van het HFS (Hierarchical File System). HFS dateert uit 1985 en kent nogal wat beperkingen, zo kon een bestandsnaam maar 31 tekens bevatten, bestanden hadden een 2 Gb limiet en meer dan 65.000 bestanden op een volume was ook niet echt een succes.
Belangrijke kanttekening: HFS was voor zijn tijd (1985) heel erg modern!
In 1998 introduceerde Apple HFS Plus, de Plus staat (evenals de S in de iPhone 3G) voor een extraatje. Een evolutionaire stap, dat zeker. Maar absoluut geen revolutie.
De belangrijkste verbeteringen ten opzichte van HFS waren het feit dat HFS Plus 32-bits adresseert, gebruik maakt van Unicode, bestandsnamen tot wel 255-tekens ondersteund en sinds 2002 ondersteund HFS Plus het gebruik van een 'journaal'. Middels dit journaal worden 'schijftransacties' eerst in het journaal gemeld voordat deze daadwerkelijk uitgevoerd worden. Het voordeel hiervan is dat als de computer crasht of plots wordt uigezet gemakkelijk nagegaan kan worden welke transacties volbracht hadden moeten worden om deze alsnog uit te voeren (of terug te draaien).
Allemaal prachtige toevoegingen, maar omdat HFS Plus een (enigszins) verbeterde versie van HFS is, gelden veel van de potentieel zwakke plekken voor HFS ook voor HFS Plus.
Door gebruik te maken van een 'Catalog File', 'b-tree' en 'Volume Control Block' blijkt het maar weer dat HFS Plus zijn oorsprong heeft in HFS (en zelfs in MFS (Macintosh File System)).
Waarom is dat slecht?Laten we beginnen met Apple-eigen technieken die nog steeds in MacOS X terug te vinden zijn:
Resource Forks is er zo eentje. Gegevens op de HFS Plus schijf worden opgeslagen in een 'container'. Deze container bestaat uit een deel waar de programma-code, metadata, afbeeldingen en andere bronnen in opgeslagen worden en een deel waar de data wordt opgeslagen (denk aan teksten).
De Resource-Fork (lees: 'container') wordt voor elk bestand gebruikt op HFS Plus. Databestanden, zoals tekstverwerkdocumenten, zullen eerder gebruik maken van het 'data-deel' en programma's maken juist vooral gebruik van het deel waar 'bronnen' worden opgeslagen.
Dit mechanisme is transparant en is niet zondermeer te zien. Ook niet vanuit de terminal. Het vervelende is dat gegevens op bestandsniveau 'ingepakt worden' in een container. Als je het bestand een op een kopieert naar een bestandssysteem dat geen resource-forks ondersteund, neem je de Mac-data mee. Vrij waarschijnlijk kan een systeem anders dan MacOS (X) er helemaal niets mee en herkent het bestand niet. Ook al is het een 'universeel' formaat als .DOC, .ODT of .TIFF. Nu vangen diverse systemen in MacOS X dat af en zorgen automatisch voor de vertaalslag.
Het is belangrijk om te weten dat UNIX een standaard kent, te weten POSIX (Portable Operating-System Interface for uniX), welke verheven is standaard. De meeste UNIX-systemen proberen POSIX-compliant te zijn. Het voordeel hiervan is dat programma's die op een POSIX-gebasseerd systeem gemaakt zijn, ook te compileren zijn op een ander systeem. Het gaat hier overigens wel om POSIX-gecertificeerde software.
Maar, MacOS X is POSIX-compliant. Toch? Ja, MacOS X is POSIX 1003.1-compliant. Maar HFS is dat niet. Sterker nog, een kleine kans dat dit ooit gaat lukken met de huidige implementatie.
Een (1), zo niet DE belangrijkste reden dat Apple het bestandssysteem deels afschermt onder de finder is niet zozeer het gebruiksgemak, je zou immers ook show all en show all + metadata kunnen opnemen in de instellingen. Het is het feit dat MacOS X ongekende truuks uithaalt om enigszins op een UNIX bestandssysteem te gelijken. Sterker nog: het prutsen in "?\x90\x80?\x90\x80?\x90\x80?\x90\x80HFS+ Private Data"-directory leid onherroepelijk tot een overleden bestandssysteem.
Een andere eigenaardigheid is het gebruik van een 'dubbele punt' : als 'path seperator'. Zie hier het verschil.
Linux bestandssysteem (ext2/3):
/home/doctor-apple/Documents/i-love-apple.pdf
MacOS X HFS Plus bestandssysteem:
:Users:doctor-apple:Documents:i-love-apple.pdf
Dit is de reden waarom je geen dubbele-punt in een bestandsnaam kon opgeven. Anderzijds kun je wel een 'forward slash' / opgeven in een bestandsnaam. Als geheel is dit NON-UNIX en NON-POSIX-compliant.
De 'MacOS X document controller' binnen het besturingssysteem vertaalt de dubbele punt 'on-the-fly' naar 'forward slashes'. Aardig, en het werkt nog goed ook, zeker onder de Finder. Maar deze vertaalslag wordt niet overal op toegepast en vanaf de prompt kun je dit omzeilen. Er zijn genoeg toepassingen die niet direct een GUI nodig te hebben (Oracle, PostgreSQL, etc) een CLI volstaan. Sterker nog: als je een POSIX programma naar MacOS X migreert kun je nog voor verassingen komen te staan.
Verder is er een hele meuk aan 'Finder Flags' die niet meer gebruikt worden om nog maar te zwijgen van de overhead. Natuurlijk worden er ook 'flaggetjes gebruikt' als 'hide file extensions'. Maar het merendeel is legacy. Nooit jezelf eens afgevraagd waarom een vers geformatteerde EXT3 of FAT32 schijf slechts een megabyte of 2 tot 4 nodig heeft voor systeemdata en MacOS X soms wel rustig 100 megabyte reserveert? En nee, het journaal niet meegerekend!
Er is nog een A4'tje of drie te schrijven wat er allemaal mis is met HFS en (probeer) van me aan te nemen als ik zeg dat er echt dramatische zwakheden tussenzitten waarvan je je afvraagt waarom Apple niet eerder HFS heeft gedumpt.
ZFS Alternatief?ZFS is een nieuw bestandssysteem. Belangrijke voordelen zijn: eenvoudig beheer, immense schaalbaar, verbeterde data-integriteit en 'ingebouwde timemachine'. ZFS is niet een verbetering van bestaande technologie, maar een fundamentele nieuwe benadering van data managament. ZFS is een storage systeem dat zeer gebruiksvriendelijk is. Belangrijk is ook dat het geen legacy kent zoals HFS of NTFS.
Het bestandssysteem heeft een optie genaamd 'disk scrubbing'. Het is een mechanisme om elke opslag-eenheid op schijf te valideren met een 256-bits checksum en indien mogelijk te repareren. ZFS doet dit terwijl het bestandssysteem gewoon in gebruik is. Unmounten of vanaf een boot-dvd opstarten om het bestandssysteem te checken is niet aan de orde.
Met ZFS kun je ongelimiteerd snapshots maken op het bestandssysteem. Een Snapshot is een read-only kopie van het systeem zoals we dat kennen van TimeMachine. het grote verschil is dat dit op het systeem zelf gebeurt en geen externe schijven voor nodig zijn. Tevens kan ZFS een 'kloon' aanmaken. Een kloon is een schrijfbare kopie van een snapshot. Enigszins vergelijkbaar met een diskimage.
Verder werkt ZFS met een ingebouwde compressie. Vanzelfsprekend niet overal op toepasbaar, maar op veel bestanden zal het prima werken.
ZFS is volledig 128-bit en zou gemakkelijker dan NTFS of HFS Plus zelfs naar de 256-bit kunnen schalen. Op dit moment kan ZFS 16 exabyte adresseren (16 miljoen terabyte).
ZFS is volledig POSIX
Inmiddels is ZFS het standaard bestandssysteem van OpenSolaris waarmee blijk wordt gegeven dat het wel degelijk als standaardbestandssysteem kan dienen van een besturingssysteem. OpenSolaris is er voor servers en desktops.
Apple zou het mogelijk kunnen hebben laten varen in verband met de overname van Sun door Oracle. Anderzijds is ZFS OPEN SOURCE! Apple zou de ontwikkeling hiervan op zich kunnen nemen als Sun het voor gezien houd.
Al met al: vreemd en (weer) een gemiste kans.
Groet,
Doctor
Gast
