ZFS (Dateisystem)...

[Jochen]

Von oder mit ZFS kann man nicht booten ?

http://www.informationweek.com/news/showArticle.jhtml?articleID=199903525

Stimmt das ?

Weiss jemand was näheres ?

Jochen

[mbs]

Stimmt das ?

Nein. Das ist eine Frage der Computer-Firmware und der Startumgebung.

Es ist richtig, dass im Betriebssystem SUN Solaris 10, das ja sozusagen die "Standardheimat" von ZFS ist, das Booten von ZFS nicht offiziell vom Installer unterstützt wird. Ab Release 12/07 von Solaris 10 soll das aber offiziell gehen und im Moment kann man es auch schon manuell einrichten.

Wie gesagt liegen mögliche Bootprobleme aber weder am ZFS an sich, noch am Betriebssystem, das während des Bootens ja noch gar nicht läuft. Die Frage ist, ob die Firmware des jeweiligen Computermodells ZFS als gültiges Startdateisystem anerkennt. Apple könnte das z.B. problemlos durch ein Firmware-Update realisieren, falls man das wollte...

[Jochen]

Stimmt das ?

Nein. Das ist eine Frage der Computer-Firmware und der Startumgebung.

Danke.

Sehr interessante Antwort eines Insiders.
Damit ist wohl das schon angenommene "gesteved" wahrscheinlicher.

Ach was existiert hier doch für ein Insiderwissen.

Jochen

[Florian]

Wohl eher "geschwarzt".
Der Sun-Chef hat halt Blödsinn erzählt beziehungsweise alle, inklusive mir, haben aus "the file system in Leopard" irgendwie ein "default" gemacht.
Tatsache ist ja wohl, daß ein komplettes Umstellen von HFS+ auf ZFS so aufwendig wäre das Apple sicher nicht mal eben so einen Rückzug machen könnte. Mal davon abgesehen das ZFS seine Stärken in RAID-Systemen ausspielt während dort seine Nachteile nicht so zum Tragen kommen.
Hätte ich mich früher besser informiert wäre mir das auch aufgefallen... so plappert man immer Mist nach den man irgendwo gelesen hat.
Apple verkauft stetig mehr Klapprechner. Die Besitzer werden wohl kaum freudig erregt sein über ein Dateisystem das die CPU mehr fordert und mehr Plattenplatz verbraucht. Mal von einigen ganz anderen Dingen abgesehen, die man wohl Otto Normaluser nicht leicht erklären kann.

In Mac OS X Server machte es dagegen durchaus Sinn und vielleicht meinte Schwartz ja  das.

Was Normalanwender bekommen ist eine Möglichkeit ZFS-Volumes zu lesen. Mehr nicht. Und wahrscheinlich ist das auch besser so.

[mbs]

Es gibt ernst zu nehmende Gerüchte, nach denen registrierte Entwickler neben der Leopard-Preview als davon getrenntes Paket auch eine ZFS-Preview mit vollen Schreib-/Lesefunktionen erhalten werden, die in Leopard nachinstalliert werden kann. In Mac OS X 10.5.0 soll der Schreibzugriff auf ZFS "zunächst" gesperrt werden. (Was wohl heißen soll, ab Mac OS X 10.5.1 steht ZFS möglicherweise uneingeschränkt zur Verfügung.)

Tatsache ist ja wohl, daß ein komplettes Umstellen von HFS+ auf ZFS so aufwendig wäre

Hm, wo wäre denn der Aufwand?

[Florian]

Natürlich könnte Apple einfach auf die an sich fertige Kernel-Extension verzichten.

Aber im Falle eines Default-Systems hätten doch die Entwickler frühzeitig informiert werden müssen und zwar alle, da ZFS doch einige Änderungen mitbringen wird, die mitunter eine Applikation laufunfähig machen, oder Files nicht mehr lesbar. Ist doch so, oder?
Die Metadaten- und Namenskonventionen müssten umgestellt werden, auch weil sonst Fat-Zaps die Platte zumüllen, es sei denn man legt wieder alles in .-Dateien. Wo ist da der Fortschritt?

Ich sage ja nicht, daß es nicht machbar ist, nur kann ich mir nicht vorstellen das Apple so viele Anpassungen vornimmt und dann auch noch wirklich alle User damit "beglücken" will - es dann aber wegen einer Nichtigkeit nicht verwendet.

Also: Dabei schon, ja, so war es wohl immer gemeint. Aber das man das neue Default-System einfach fallen lässt, oder degradiert, ne, nie und nimmer.
Du weißt ja sicher mehr als ich, aber ich denke doch Apple ist nicht mehr die Firma, die so wechselhaft agiert.

[mbs]

Aber im Falle eines Default-Systems hätten doch die Entwickler frühzeitig informiert werden müssen und zwar alle, da ZFS doch einige Änderungen mitbringen wird, die mitunter eine Applikation laufunfähig machen, oder Files nicht mehr lesbar. Ist doch so, oder?

Nein, ich wüsste nicht warum eine Applikation etwas vom Dateisystem wissen muss. Das betrifft höchstens die Entwickler von solchen Tools wie DiskWarrior.

Die Metadaten- und Namenskonventionen müssten umgestellt werden,

Warum? Seit 09.05.2007 besitzt ZFS auch offizielle Unterstützung zum "case-insensitive"-Betrieb.

auch weil sonst Fat-Zaps die Platte zumüllen, es sei denn man legt wieder alles in .-Dateien.

Äh, was sind "Fat Zaps"? Du meinst Forks und Finder-Attribute, oder? Seit Tiger bereits sind alle Entwickler gehalten, von solchen Dingen zu abstrahieren (falls jemand überhaupt so tief ins Dateisystem einsteigen muss). Auf Darwin-Ebene wird ab 10.4 alles über sogenannte "extended attributes" geregelt. Da diese Attribute beliebig lang sein dürfen, sind Forks ein einfacher Spezialfall hiervon.

Das einzige, was für Apple wirklich Aufwand bedeuten würde, wäre, alte Rechner so nachzurüsten, dass sie von ZFS booten können. Das ist, wie in diesem Thread schon diskutiert, ein Firmware-Problem. Da jede Mac-Baureihe eine unterschiedliche Firmware hat, wäre die Aktualisierung für die alte Hardware ganz schon teuer für Apple. Das ist schon eher ein technischer Grund, ZFS nicht als Standard einzusetzen. Realistisch wäre, dass Apple Firmware-Updates nur für EFI-Rechner mit GUID-Partitionstabelle bereitstellt. Mit anderen Worten nur Intel-Macs würden von ZFS booten können.

Du weißt ja sicher mehr als ich,

Nein, mir liegen auch keine Insider-Informationen vor, wie Jochen vermutet. Was ich schreibe, sind Schlussfolgerungen und Spekulationen auf Basis der Tatsachen, die bis jetzt bekannt geworden sind.

[warlord]

Nein, ich wüsste nicht warum eine Applikation etwas vom Dateisystem wissen muss. Das betrifft höchstens die Entwickler von solchen Tools wie DiskWarrior.

Nun ja, eigentlich immer dann, wenn von einer Applikation erwartet wird, dass sie auch die Besonderheiten unterstützt, die ein Filesystem so mitbringt. Das können in meinen Augen nicht nur Programme sein, die direkt etwas am Filesystem werkeln.
Eine ganze Reihe von Datei-APIs, die von Entwicklern so genutzt worden sind, sind ja auch ganz spezifisch HFS-APIs.

[mbs]

Eine ganze Reihe von Datei-APIs, die von Entwicklern so genutzt worden sind, sind ja auch ganz spezifisch HFS-APIs.

Die gesamten HFS-APIs, die per Carbon zur Verfügung stehen, werden in Mac OS X nur "emuliert". In Wirklichkeit muss intern immer alles auf BSD-Aufrufe und BSD-Pfadnamen heruntergebrochen werden. Das zugrundeliegende Darwin-System weiß seinerseits, wie es HFS-spezifische Dinge in fremden Dateisystemen emulieren muss. Wenn Du einen Fork benutzt oder HFS-spezifische Attribute wie Type/Creator-Codes, dann funktioniert das auf jedem Dateisystem. Das System kümmert sich automatisch darum, ohne dass die Applikation davon etwas merkt und das funktioniert alles schon seit 10.0.

Nur bei Programmen, die extrem "low level" arbeiten müssen (wie DiskWarrior), oder bei neuen Features, bei denen Apple deutlich sagt, dass diese (noch) nicht auf allen Dateisystemen zur Verfügung stehen (ACLs über eine NFS-Verbindung hinweg sind z.B. nicht implementiert), könnte es Probleme geben.

[Florian]

Nein, ich wüsste nicht warum eine Applikation etwas vom Dateisystem wissen muss. Das betrifft höchstens die Entwickler von solchen Tools wie DiskWarrior.

Z.B. ZFS unterstützt keine UTF-16 oder -32-Namen, weil es voraussetzt das ein 0-Byte das Ende markiert: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/sys/zap.h (Zeile 77 ff.)

Das dürfte doch ein größeres Problem sein, das viele Programme auflaufen lassen dürfte?

Also würde MAC OS X übersetzen müssen nur leider würden dann Nicht-ASCII-Namen halt beeinträchtigt es sei denn es gibt irgendeinen Zauberweg.

Denkfehler meinerseits?

Warum? Seit 09.05.2007 besitzt ZFS auch offizielle Unterstützung zum "case-insensitive"-Betrieb.

Ja, und übrigens nicht wegen Apple sondern Microsofts CIFS.
Wir erinnern uns das Leopard zunächst zu diesem Zeitpunkt eigentlich schon draussen gewesen sein sollte... auch die Zeitlinie spricht irgendwie gegen "ZFS als Standard". Man meinte halt allgemein ZFS mit seinen Snapshots passe so super zu Time Machine.

Äh, was sind "Fat Zaps"? Du meinst Forks und Finder-Attribute, oder? Seit Tiger bereits sind alle Entwickler gehalten, von solchen Dingen zu abstrahieren (falls jemand überhaupt so tief ins Dateisystem einsteigen muss). Auf Darwin-Ebene wird ab 10.4 alles über sogenannte "extended attributes" geregelt. Da diese Attribute beliebig lang sein dürfen, sind Forks ein einfacher Spezialfall hiervon.

Soweit ist mir das halbwegs klar gewesen.

ZFS verwendet für Attribute sog. Zap-Objekte. Normalerweise sollen die Attribute in ein Microzap, daß nur einen Allocation-Block groß ist, also in ZFS-Standardeinstellungen (die man ja ändern könnte) acht KB.
Aber!
Die Attribute dürfen nur einen Namen mit 50 oder weniger Zeichen haben und (kleiner oder gleich) acht Bytes sein. Ist auch nur ein Attribut anders, wird ein sog. Fat-Zap verwendet, viel komplexer und mit einem 128KB-Header.

So meine Informationen.

Also würden ja wohl wahrscheinlich wieder die tollen .-Dateien zum Einsatz kommen die dem normalem Mac-Benutzer verborgen bleiben aber nicht nur in gemischten Netzwerken nervtötend sind.

ZFS frißt Leistung und Plattenplatz, Apple verkauft 50%++ Laptops, die meistens weit weg sind von irgendwelchen "storage pools".

Das einzige, was für Apple wirklich Aufwand bedeuten würde, wäre, alte Rechner so nachzurüsten, dass sie von ZFS booten können. Das ist, wie in diesem Thread schon diskutiert, ein Firmware-Problem. Da jede Mac-Baureihe eine unterschiedliche Firmware hat, wäre die Aktualisierung für die alte Hardware ganz schon teuer für Apple. Das ist schon eher ein technischer Grund, ZFS nicht als Standard einzusetzen. Realistisch wäre, dass Apple Firmware-Updates nur für EFI-Rechner mit GUID-Partitionstabelle bereitstellt. Mit anderen Worten nur Intel-Macs würden von ZFS booten können.

Dann wäre es ja schon mal kein Standard, denn Leopard wird ja wohl auch noch für PPC-Macs verkauft.

Ich nehme schon an das ZFS unterstützt werden wird, halt wie UFS, und nie was anderes geplant war. Ist aber nur meine Meinung, Beweise habe ich natürlich nicht.

Du weißt ja sicher mehr als ich,

Nein, mir liegen auch keine Insider-Informationen vor, wie Jochen vermutet. Was ich schreibe, sind Schlussfolgerungen und Spekulationen auf Basis der Tatsachen, die bis jetzt bekannt geworden sind.

Ich meinte eher die technischen Hintergründe.

[warlord]

Wenn Du einen Fork benutzt oder HFS-spezifische Attribute wie Type/Creator-Codes, dann funktioniert das auf jedem Dateisystem. Das System kümmert sich automatisch darum, ohne dass die Applikation davon etwas merkt und das funktioniert alles schon seit 10.0.

So einwandfrei scheint das aber nicht zu klappen. Mein zugegebenrmassen betagtes und seit Jahren nicht mehr aktualisiertes Programm, das für Dateizugriffe genau diese Carbon HFS-APIs nutzt, kommt mit FAT Partitionen z.B. nicht klar. (Zumindest berichteten das übereinstimmend eine Reihe von Kunden. Selbst habe ich nie mit FAT rumexperimentiert.) Das liesse sich zwar womöglich durch Anpassungen an Fehlerabfang-Routinen hinkriegen (ist also meiner eigenen Faulheit zuzuschreiben  ), stellt aber nichts desto trotz einen Bruch der Abwärtskompatibilität dar, der durch Einführung eines "neuen" Dateisystems verursacht worden ist.

[mbs]

ZFS unterstützt keine UTF-16 oder -32-Namen, weil es voraussetzt das ein 0-Byte das Ende markiert:

Mac OS X hat auch noch nie solche Namen verwendet. Für alle Dateizugriffe verwendet Mac OS X immer UTF-8, genau wie ZFS. UTF-7, UTF-16, UTF-32 sind nur andere mögliche Alternativen, Unicode-Zeichen als Bytefolge abzuspeichern. Der Zeichenvorrat ist immer Unicode und immer identisch. Hier gibt es also kein Problem.

Die Attribute dürfen nur einen Namen mit 50 oder weniger Zeichen haben

Benannte Attribute werden von Mac OS X nur für Resource Forks verwendet. In diesem Fall lautet der Name meines Wissens "rsrc", was in 4 Bytes abzuspeichern ist. Ob große Forks in ZFS tatsächlich ineffizienter abgespeichert werden, als in HFS+, müsste ich erst überprüfen.

Hierbei muss man allerdings bedenken, dass es immer weniger Programme gibt, die Resource Forks verwenden. Das betrifft heute fast nur noch Anwender von Classic-Programmen oder Leute, die immer noch Vorschauansichten von Bilddateien in Forks speichern, obwohl der Datenfork oft bereits mehrere Vorschaubilder enthält.

Die "._"-Dateien enthalten heute in der Regel nur noch Finder/HFS-Attribute, kaum noch Forks.

[VollPfosten]

Inzwischen gibt es ZFS-Treiber für mutige / experimentierfreudige Menschen ohne ADC-Abo über MacOSForge.

[radneuerfinder]

"it is now unlikely that Apple will ever use ZFS as a mainstream file system":
http://www.9to5mac.com/ZFS-apple-sun-oracle

[Florian]

Das ist nicht nur unlikely, sondern ziemlich sicher.
Es war auch noch nie likely, auch wenn auch ich darauf reingefallen bin, denn was will man mit ZFS in einem Laptop?

Außerdem pfeifen die Spatzen (nicht nur Gruber) von den Dächern, dass Apple selbst was bastelt/basteln will. Das dürfte dann auch sehr viel besser zu den meistverkauften Apple-Systemen passen.