ARCHIV 1999-2006

ARCHIV :: # 4227

ZFS?

HFS+UFSNFSNTFSFATFAT32 usw.

Autor: thyl - Datum: 02.05.2006

Auch wir wissen natürlich nicht, was an den Gerüchten dran ist, dass Apple Suns ZFS-Dateisystem für MacOSX einsetzen möchte. Aber hier gibts eine vergleichende Übersicht.

Kommentare

wozu?

Von: nam | Datum: 02.05.2006 | #1
na ich glaub ja nicht dran, wo apple doch ab 2007 mac os x einstellt und vista rechner anbieten wird.

aber nochmal zum sabbern:
[Link]

@nam

Von: kaos | Datum: 02.05.2006 | #2
danke für dne nächsten flame war. man muss sich an solche posts bei MG erstmal gewöhnen. früher hat man das ja nur bei heise gesehen. ich finde ZFS auch schick. ich glaube aber das kommt eher für den server als für das normale OS.

Für Servereinsatz?

Von: eclipse | Datum: 02.05.2006 | #3
[Link]

Vielleicht 'ne Alternative für den Servereinsatz? Die Schwierigkeit dürfte für Apple darin bestehen, die "extendet attributes" des HFS(+) im ZFS abzubilden.
Aber vielleicht wird das ja bei der Gelegenheit gleich abgeschafft. Aber es geht ja sowieso auch schon plain old ufs und auch ext2 - wenn ich mich nicht irre. Von daher, warum nichtz auch ZFS? Es kann ja dann jeder für sich entscheiden, welches FS für den vorgegebenen Einsatzzweck das geeignetste ist.

@kaos

Von: nam | Datum: 02.05.2006 | #4
zum glueck kannst du gepflegt mit ironie umgehen ;-)

@nam

Von: kaos | Datum: 02.05.2006 | #5
sorry. ich habe mittlerweile den überblick verloren wer hier welche schachsinnige ansicht vertritt und wer sie als ironischen kommentar einfliess lässt :-P

nicht gut

Von: Bernhard Nahrgang | Datum: 02.05.2006 | #6
zfs scheint nicht "journaled" zu sein, das wäre aber ein Rückschritt, oder?

@kaos

Von: Thyl (MacGuardians) | Datum: 02.05.2006 | #7
Das ist halt Zen.

@Bernhard Nahrgang

Von: Rüdiger Goetz | Datum: 02.05.2006 | #8
Hallo,

Woher nimmst du diese Erkenntnis? Laut dem verlinkten wikipedia-Artikel, ist zfs sogar transactions-orientiert. Das ist im Zweifelsfall noch besser. Lediglich meta-daten werden nicht separat "gejournalet".

Bis dann

R"udiger

Die neueste Heisemeldung zu ZFS schreibt da schon was konkreteres

Von: grate | Datum: 02.05.2006 | #9
Ich zitiere mal die entscheidende Passage:

>> Nach Angaben eines ZFS-Entwicklers interessiert sich inzwischen auch Apple für das Dateisystem und möchte es auf sein OS X portieren.<<
[Link]

Also nicht mehr wie bei den Rumours das Sun sich freuen würde wenn, sondern das angeblich Apple selbst ernsthaft an dem Ding dran ist.

Eine Festplatte »on-the-fly« einbinden

Von: tomvos | Datum: 02.05.2006 | #10
ist ein sehr schönes Feature, dass Mac OS X afaik bisher immer fehlte. Man erkennt das auf den Slides 53ff. aus dem Link von »nam«.

In der Praxis ist das beim Umgang mit großen Videodateien von Vorteil. Oder z.B. bei Aperture … ist eine Platte zu klein für die Bild-Datenbank, dann muss man nicht auf eine andere Platte umziehen, sondern bindet einfach eine zweite Platte ein und fasst die beiden Harddisks als Logical Volume zusammen. Nett! Hoffentlich kommt das in 10.5 schon zum Einsatz.

wäre eine gute Entscheidung

Von: Strangers Night | Datum: 03.05.2006 | #11
und zeigt, auch ob der Schelte, die die Laumichels (bei Heise u.a.) gerne an Sun ablassen, dass Sun immer noch große Bedeutung besitzt.
Apple und Sun hätten damals gute Partner werden können.

vielleicht

Von: neu | Datum: 03.05.2006 | #12
gibt es ja auch überlegungen bei apple, wie bei beos das dateiformat als datenbank zu nutzen (wegen transaktionen usw.), was ja beim jetzigen macos x (trotz einstellung des entsprechenden beos-entwicklers) anders geregelt ist. das wäre für mich das einzige argument für das neue dateiformat, denn ob nun 8eib oder 16eib ist doch eher egal.

ZFS rockt

Von: H. Richter | Datum: 03.05.2006 | #13
Grundfunktionalität schick umgesetzt, LVM weiter gedacht.

Ein paar Anmerkungen, warum ZFS rockt:

RAID-Z: Effekt wie RAID-5 bei Vorhandensein mehrerer Platten, ohne jedoch die Parität über immer den gleichen Block der einbezogenen Festplatten berechnen zu müssen, so dass die Schreibschwäche von RAID-5 umgangen wird. Cool.

Datensicherheit: s.o. bei R"udiger, dazu kommt noch eine Checksumme über jeden Block (erinnert mich ein stückweit an das selige Amiga-Filesystem)

Datensicherheit(2): Snapshot-Fähigkeit im laufenden System, somit auf Dateisystemebene die Möglichkeit, einen wählbaren alten Zustand "on-the-fly" wiederherzustellen. (Stichwort: fehlgeschlagenes System-Update)

Kapazität: eingebaute Kompression

ZFS ist das Beste seit der Erfindung des Geschirrspühlers. *SCNR*

h.richter

Von: nico | Datum: 03.05.2006 | #14
raid-z? also raid5 aehnliche funktionalitaet ueber software (system) regeln zu lassen - kostet das nicht enorme rechenkapazitaet? neben theoretisch schoenem gedanken - wie sieht das in der praxis aus? immerhin gibt es fuer raid5 und aehnliche verfahren teure controller - ob nun intern im rechner oder extern im gehaeuse mit dediziertem spezialprozessor.

ich faende es jedenfalls nicht nett, wenn die power meines macs nicht komplett zur verfuegung staende nur weil ein software-raid laeuft (damit meine ich natuerlich nicht solch einfache systeme wie raid0/1).

HFS- oder UFS-Ersatz?

Von: Kai (MacGuardians) | Datum: 03.05.2006 | #15
Ich tippe eher auf letzteres, oder kann das ZFS wirklich ALLES was HFS kann (Forks/Metadata usw)?

@Kai

Von: Rüdiger Goetz | Datum: 03.05.2006 | #16
Hallo,

Forks und MEtadaten würde Apple wohl in der bisherigen Form opfern.

Metadaten lassen sich auch anders abbilden, wie es OS X ja schon beim arbeiten auf NFS-/samba-shares macht.

Und Forks werden m.W. seit Beginn von OS X zwar noch unterstützt, aber nicht mehr wirklich eingesetzt (Auch wenn man das Bedauern mag). Sie sind durch die sog. "bundles" (d.h. Verzeichnissen mit definierter interner Struktur) abgelöst worden. Bundles sind beim Arbeiten mit Server, die auf anderen Systemen basieren leichter und somit stabiler umsetztbar. Ähnliches liesse sich ggfs. auch lokal realisieren.

In beiden Fällen, würde der Anwender wenig davon merken, sofern er sich nicht in der Shell austobt.

Das einzige was nicht ganz umsetzbar sein könnte, wären Aliases, die sich doch etwas anders als symbolische Links verhalten (z.B. beim Verschieden des Ziels). Anderseits erscheinen Aliases schon jetzt in der Shell als symlinks und symlinks im Finder als Aliases. Insofern scheint auch dort Apple auf eine Vereinheitlichung hin zu arbeiten.

Bis dann

R"udiger

@nico

Von: H. Richter | Datum: 03.05.2006 | #17
"Enorme Rechenkapazität" ist nach heutiger Sicht nicht mehr so unbedingt die Folge von Software-RAID. (Bei Interesse: Netter, gut recherchierter Artikel in der aktuellen c't)

Ich habe keine Meßdaten zur Hand und lehne mich daher nicht allzuweit aus dem Fenster. Nur eine kleine Überlegung dazu:

Eine gute HDD liefert Peak-Leistungen um die 70 MB/s. Ein RAID5-Verbund aus 3 Platten bringt bei optimaler Anbindung somit um die 210 MB/s max. Schreibrate brutto (netto minus Parität (*2) summasumarum 3*70-1*70=140 MB/s).

Gehen wir von einem Hauptspeicherdurchsatz von etwa 3 GB/s aus (*1) liegt die zu verarbeitende Datenmenge bei 7% der Transferkapazität der Maschine. Parität berechnen ist eine simple Integer-Operation, die sich wunderbar einfach mit SSE oder MMX oder Altivec oder sonstwas durchhämmern läßt. Die Zeit, um nach dieser Berechnung das Ergebnis in die Platten zu pumpen, ist da wesentlich höher.

Zudem hat RAID-5 (inclusive seiner neueren Spielarten) bei nicht defekten Platten die Eigenschaft, dass die Parität beim Lesen ignoriert werden kann und der Datentransfer rein über den DMA abläuft, ohne die CPU nennenswert zu belasten.

Resümee: RAID in Software im Lesebetrieb je nach Implementierung halb so wild, im Schreibbetrieb ein wenig Rechenlast durch das Umschaufeln von Speicherinhalten.

Es macht im übrigen auf modernen Maschinen keinen Sinn, einen alten PCI-basierten SCSI RAID-Controller einzubauen, der mit neueren Platten völlig überfordert wird. Lustigerweise ist in diesem Fall der Prozessor im Rechner deutlich schneller als der i960 (oder irgendwas) auf dem RAID-Board.

(*1) Athlon64 bringt aktuell rund 4.3 GB/s
(*2) Paritätsinformationen sind by design "redundant" und somit netto nicht nutzbar

@R"udiger

Von: H. Richter | Datum: 03.05.2006 | #18
Für alles, was im weiter gefassten Sinn in die Richtung von Applikationen geht (also auch Frameworks, Plugins usw.), sind Bundles genau das Richtige, ein mehr als vollwertiger und transparent nutzbarer Ersatz für die kruden Spielchen mit Resource-Editoren.

Eine generelle Lösung für die Mac-spezifischen Annehmlichkeiten sind die Bundles nicht. Finder-Spielereien (*) wie Labels, Kommentare usw. ließen sich gut und effektiv für Bilder, Dokumente usw. im Resource-Fork unterbringen.

Der Workaround mit versteckten Dateien auf Mac-fremden Dateisystemen ist transparent realisierbar und nur sichtbar, wenn der Zugriff von "fremden" Betriebssystemen aus erfolgt, richtig schick und elegant ist diese Lösung jedoch trotz der erreichten Kompatibilität (*2) nicht.

Ich kann damit leben, bin mit Metadaten in separaten Files quasi aufgewachsen. Kennt noch jemand die ".info"-Dateien vom Amiga ?

(*) sollte kein Flamebait sein
(*2) einige Applikationen kommen mit Resources in separaten Files bekanntlicherweise nicht klar

.info-Datei

Von: Kurdwubel | Datum: 07.05.2006 | #19
Hier, ich! Immerhin ist mein Amiga 4000 noch des Öfteren im Einsatz.
Manoman, das waren damals zweiten: 'animierte' Icons. Beliebige Größe. Das waren noch Zeiten in der GUI-Technik... *schwelg*