Forum


Spickzettel

Neben den Buttons stehen unter anderem folgende BB-Codes zur Verfügung:

Bildgröße beschränken:
[img width=400 height=300]Bildadresse[/img]
Weglassen von height o. width behält Bildverhältnis bei.

Tabelle:
[table]
[tr][td]Zelle 1/1[/td][td]Zelle 1/2[/td][/tr]
[tr][td]Zelle 2/1[/td][td]Zelle 2/2[/td][/tr]
[/table]
[tr] = Zeile [td] = Zelle

Text:
[u]unterstreichen[/u]
[s]durchstreichen[/s]
[size=4]skalieren[/size]
[sup]hochsetzen[/sup]
[sub]runtersetzen[/sub]
Umbrechen[Br]Neue Zeile
[center]zentriert[/center]
[left]linksbündig[/left]
[right]rechtsbündig[/right]
[rtl]von rechts einschieben[/rtl]
[pre]Vorformattierung erhalten[/pre]
[move]Bewegen/Laufschrift[/move]
[shadow=red,right]Schattieren[/shadow]
[font=arial]Anderer Zeichensatz[/font]
[glow=yellow,2]„glühen“/markieren[/glow]

Horizontale Linie: [hr]

Abkürzung mit Erklärung bei Mouseover:
[acronym=Mysteriöse Inselzone]MIZ[/acronym]
am besten auch unterstreichen:
[acronym=Mysteriöse Inselzone][u]MIZ[/u][/acronym]

Link innerhalb des Beitrages oder derselben Seite:
Ziel setzen: [anchor=Ziel]Ziel[/anchor]
Link darauf: [iurl=#Ziel]Link zum Ziel[/iurl]

Link im selben Fenster öffnen:
[iurl]http://www.apfelinsel.de[/iurl]

Name:
Betreff:

Verifizierung:
Buchstaben anhören

Gib die Buchstaben aus dem Bild ein:


Zusammenfassung

Autor: Florian
Juli 27, 2012, 12:00:21
Don Brady - um den ging es in dem von radneuerfinder verlinkten Artikel - ist mittlerweile bei der Firma GreenBytes, die eine ZFS-Lösung anbieten. Diese Software Zevo wird ab Mitte September (für Privatkunden?) kostenlos werden (jetzt 20 $). Support nur über ein Forum. Weitere Details noch unklar.
http://www.getgreenbytes.com/blog/bid/80923/GreenBytes-and-the-Future-of-ZEVO
 
Autor: Florian
März 21, 2011, 01:12:51
Don Brady, früher bei Apple an HFS+ und dem abgebrochenen ZFS-Projekt beteiligt, will ZFS perfekt angepasst auch ausserhalb des Server-Bereichs auf dem Mac etablieren, mit seinem Projekt Z-410. Interessanter Artikel:
http://arstechnica.com/apple/news/2011/03/how-zfs-is-slowly-making-its-way-to-mac-os-x.ars
Autor: Florian
Oktober 26, 2009, 23:58:07
Der Chefentwickler von ZFS meint, es wären Lizenzierungsstreitigkeiten gewesen:
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-October/033125.html

Guter Text zu ZFS am Mac:
http://devwhy.blogspot.com/2009/10/loss-of-zfs.html

Beide Links von daringfireball.net
Autor: Florian
Oktober 24, 2009, 19:19:55
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.
Autor: radneuerfinder
Oktober 23, 2009, 23:59:20
"it is now unlikely that Apple will ever use ZFS as a mainstream file system":
http://www.9to5mac.com/ZFS-apple-sun-oracle
Autor: VollPfosten
Januar 12, 2008, 22:49:22
Inzwischen gibt es ZFS-Treiber für mutige / experimentierfreudige Menschen ohne ADC-Abo über MacOSForge.
Autor: mbs
Juni 26, 2007, 18:59:44
Zitat
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.

Zitat
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.
Autor: warlord
Juni 26, 2007, 17:32:38
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.
Autor: Florian
Juni 26, 2007, 17:19:04
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?


Zitat
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.


Zitat
Ä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". ;)


Zitat
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.

Zitat
Du weißt ja sicher mehr als ich,
Zitat
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.
Autor: mbs
Juni 26, 2007, 17:12:51
Zitat
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.
Autor: warlord
Juni 26, 2007, 16:30:52
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.
Autor: mbs
Juni 26, 2007, 15:49:44
Zitat
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.

Zitat
Die Metadaten- und Namenskonventionen müssten umgestellt werden,

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

Zitat
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.

Zitat
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.
Autor: Florian
Juni 26, 2007, 15:04:48
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.