Eine neue Chance für xfs am Mac?

[Rastafari]

Oder über direkte ATA-Kommandos.

 

[FritzS]

Das würde mich schon näher interessieren! Und gibt es dazu eine App die den Zustand einer Festplatte genau beschreiben vermag?

 

[Rastafari]

Wenn du mehr Kontrolle darüber willst, kauf eine SCSI HD.

 

[FritzS]

Die passt aber nicht in mein MBP!?

Oder etwa doch? :rolleyes:

 

[Rastafari]

Kein Grund gleich so warmduschermässig loszuheulen.
Zwei, drei beherzte Schläge mit dem Fäustel machen das schon passend.
Richtige Männer lassen sich durch solche Kleinigkeiten nicht vom optimieren ihrer Twitter-Workstation abhalten.

 

[FritzS]

Das Scherz & Satire Flag hast vergessen

 

[FritzS]

Etwas kritische Anmerkungen zu HFS+
http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/

 

[Rastafari]

Ein schöner Beweis, dass selbst fachlich kompetente Leute manchmal, aus mutmasslicher Betriebsblindheit heraus, ziemlich haarsträubenden Unsinn von sich geben. Hier exemplarisch ein paar Kommentare dazu:

When searching for unused nodes in a b-tree file, Apple's HFS+ implementation processes the data16 bits at a time. Why? Presumably because Motorola's 68000 processor natively supports 16-bit operations. Modern Mac CPUs have registers that are up to 256 bits wide.

Was Siracusa hier seltsamerweise nicht erwähnt:
Würde man einen 68k mit den gleichen Taktraten und mit den gleichen Schnittstellen betreiben können wie heutige CPUs, dann wären seine 16-bittigen Operationen bei solchen Algorithmen kein Stück langsamer oder ineffizienter als solche in grösseren Zahlenräumen. Im Gegenteil sogar - der Effekt wäre die gleiche Wirkung bei weniger Energie- und Speicherverbrauch.
Oder anders formuliert: Im Stau fährt sich ein Porsche auch nicht schneller als ein Trabbi.
Die modernere CPU kann hier zwar tatsächlich wesentlich punkten - aber durch ganz andere Neuerungen, die *Registerbreite* spielt hierbei keinerlei Rolle. (Die Zauberworte hier heissen "spekulative Spungzielvorhersage bzw -Ausführung", und die sind hier eben nicht noch effektiver einsetzbar. Darüber kann man nachdenken, wenn die Zahl der Nodes sich noch ein weiteres mal um den Faktor 100 etwa erhöht hat, bis dahin ist noch viel Zeit - falls es überhaupt jemals noch so weit kommt.)
Dass man sich durch "effizienter gefüllte" Register hier genau einen (!) von 32767 Iterationsläufen einsparen könnte, wird durch andere Faktoren mehr als nur wettgemacht.
Nächste Stilblüte:

The time resolution for HFS+ file dates is only one second. ... Modern file systems have up to nanosecond precision on their file dates.

Das ist schon richtig, aber deshalb ein komplett neues FS einzuführen gleicht dem berühmten Ölscheich, der seinen Mercedes mit vollem Aschenbecher einfach wegschmeisst. Für solche Lappalien verbreitert man ganz einfach die entsprechenden Datenfelder, fügt bei der Gelegenheit noch ein paar weitere nützliche hinzu und nennt das ganze simpel eine neue Revision.
Momentan sind wir (nach etwa 20 Jahren) erst bei der Nummer 5, bleiben noch weitere 121 solch massiven Eingriffe möglich bis sich dadurch ein *wirkliches* Kompatibilitätsproblem auftut.
Weiter:

File system metadata structures in HFS+ have global locks. Only one process can update the file system at a time. This is an embarrassment in an age of preemptive multitasking and 16-core CPUs. Modern file systems like ZFS allow multiple simultaneous updates, even to files that are in the same directory.

Aber hallo, das ging ja voll nach hinten los. Dass diese Parallelisierung letztenendes immer nur eine PSEUDOparallelisierung ist, die mit zusätzlichen Taktzyklen erkauft werden muss und unterm Strich nur einen verlustbringenden Kompromiss darstellt, das sagt er nicht? Dem Gespann aus IO-Treiber und Dateisystem einen ganz eigenen Core exklusiv zu reservieren und diesen gleich direkt aufs Speichergerät auszulagern scheint wohl keine Option für übermorgen mehr zu sein? Wozu hier bitte heute noch ein ZFS auf OS-Ebene einführen, das dadurch schon in etwa 5-10 Jahren *komplett* obsolet werden und als ganzes "wegfallen" wird? Zu viel Langeweile?

HFS+ lacks sparse file support, which allows space to be allocated only as needed in large files.

Jaaaa, das ist schon richtig. Aber wer bitteschön braucht das noch, wo man vergleichbares schon sowohl eine Abstraktionsschicht höher (HDIX) als auch in einer zusätzlich darunter geschobenen Ebene (CoreStorage) zur Verfügung hat?
Braucht man das gleiche wirklich auch noch ein drittes mal? Echt? Wie häufig benutzt man das denn überhaupt wirklich, hm?
Wie oft wurde das denn seinerzeit im UFS genutzt, hm? Wie bitte, so gut wie nie? Och, schade eigentlich.

Aber der absolute Knaller ist eigentlich dieser eine Satz hier, ich bin sicher dafür möchte er nach etwas mehr nachdenken gerne im Boden versinken:

B-trees or no b-trees, over half a million files in a single directory makes me nervous.

Hier scheinen wir etwas zu wenig Schlaf gehabt zu haben?
Haben wir irgendwie vergessen, dass in HFS und HFS+ auf unterster technischer Ebene ohnehin *ALLE* Objekte des Dateisystems auf ein und der gleichen Ebene verzeichnet sind? Dass das Konstrukt des "Ordners" hier nur eine bessere Fleissaufgabe zur Benutzerführung darstellt, die "nachträglich" über dieses völlig homogene Meer aus "Extents" einfach "drübergestülpt" wird und zur Lokalisation derselben etwa genauso irrelevant ist wie eine zusätzliche Ebene von Anmerkungen oder Lesezeichen in einem PDF-Dokument für den eigentlichen, wesentlichen Seiteninhalt?
Ganz aus den Augen verloren, dass ein "Ordner" im B-Baum nur einen zusätzlichen Seitenzweig einnimmt, aber keinen "tragenden Ast"? Dass es einfach nicht wahr ist dass sich Dateien "darin" befinden würden, dass die Ordner in Wahrheit nichts anderes sind als ganz ordinäre Dateien einer lediglich besonderen Art, die einträchtig *neben* diesen Dateien her existieren? Dass die ganze "Hierarchie" nur ein virtuelles Scheingebilde ist, eine billige *nachträglich* erzeugte Illusion zur besseren Organisation des Anwenders? Und zwar NUR des Anwenders?
Lieber Herr Siracusa, hier was zum Nachdenken: Je *MEHR* Objekte im gleichen "Ordner" umso *BESSER*.
So herum passt der Schuh.
(Danke für das schöne Eigentor. Sowas kann auch dem besten Torwart mal passieren. )

 

[Rastafari]

.

 

[tjp]

Würde man einen 68k mit den gleichen Taktraten und mit den gleichen Schnittstellen betreiben können wie heutige CPUs, dann wären seine 16-bittigen Operationen bei solchen Algorithmen kein Stück langsamer oder ineffizienter als solche in grösseren Zahlenräumen.

Das ist falsch! 16Bit Operationen auf den alten Datenstrukturen mit neuen CPUs sind nun einmal deutlich langsamer, weil moderne CPUs nur schnell lesen und schreiben können, wenn das Aligment zur Wortgröße der CPU paßt. D.h. nimmt man neuen Programmcode der 16Bit Werte schreibt, knallt der Compiler massenweise Paddingbytes dazwischen, um schnelle Speicherzugriffe erreichen zu können. Die gibt es aber bei den alten Datenstrukturen aus 68k Zeiten ja nicht, denn damals hat man extra nur 16bit verwendet, weil man diese effizient und speichersparend schreiben und lesen konnte. Speicher war damals sehr teuer, sonst hätte man damals gleich 32Bit nutzen können.

Aber hallo, das ging ja voll nach hinten los. Dass diese Parallelisierung letztenendes immer nur eine PSEUDOparallelisierung ist,

Nein, das ist nicht der Fall! Lies Dir bitte mal wirklich die Informationen zu modernen Filesystemen durch. Es ist ja nicht so, daß es nicht viele Informationen im Netz gäbe. HFS+ ist alter Schrott und ganz und gar nicht mehr zeitgemäß. Die Aufgaben des OS auf einen Core zu pinnen ist auch nicht sonderlich intelligent, da FS wie ZFS auf NUMA und auch ccNUMA Systemen laufen, und auch die IO-Karten auf verschiedene NUMA-Knoten verteilt sein können. Daher ist es sinnvoll, die Aufgaben für echt paralleles Schreiben/Lesen auch auf verschiedene NUMA-Knoten zu verteilen.

 

[Rastafari]

16Bit Operationen auf den alten Datenstrukturen mit neuen CPUs sind nun einmal deutlich langsamer, weil moderne CPUs nur schnell lesen und schreiben können, wenn das Aligment zur Wortgröße der CPU paßt.

Auf die Lesegeschwindigkeit hat die Breite keinen Einfluss, und beim durchsuchen des Baums muss genau überhaupt nichts dorthin geschrieben werden.

Nein, das ist nicht der Fall!

Na sieh mal an, du fährst deine HD also über mehrere Interfaces gleichzeitig an?

HFS+ ist alter Schrott und ganz und gar nicht mehr zeitgemäß.

ZFS ganz genauso, das ist an die Bedingungen einer SSD exakt genauso schlecht angepasst.
Einen Untoten durch einen Zombie zu ersetzen ist nicht clever, sondern endzeitbescheuert.

Die Aufgaben des OS auf einen Core zu pinnen ist auch nicht sonderlich intelligent

Interessant. Was genau hättest du denn dann als Alternative zu SCSI oder (E)IDE seinerzeit eingeführt?
Diese Gerätetypen müssten sich ja eigentlich irgendwann als "nicht sonderlich intelligent" erwiesen haben, oder?

Daher ist es sinnvoll, die Aufgaben für echt paralleles Schreiben/Lesen auch auf verschiedene NUMA-Knoten zu verteilen.

Um dann letztlich auf dem Speichergerät trotzdem wieder konzentriert zu werden. Was für ein hilfloser Hirnfick.
Wobei man natürlich auch noch anmerken könnte, dass solche Dinge wie NUMA für ein OS X in etwa so ausschlaggebend sind wie die Methoden zur Anreicherung von Plutonium für die Streichfähigkeit von Butter.

 

[hosja]

Na sieh mal an, du fährst deine HD also über mehrere Interfaces gleichzeitig an?

Naja tatsächlich wird das ja jetzt mit den PCIe SSDs Steckkarten im Serverbereich versucht.

Auch mit Fragmentierung haben die SSDs weniger Probleme.

 

[FritzS]

Irgendwann werden die Permanentspeicher direkt an den Speicher&Adress Bussen hängen - da ist ein neues Filesystem angesagt.

HFS+ ist jedenfalls in die Jahre gekommen (auch etliche andere auch).

 

[hosja]

Direkter als PCIe gehts wohl kaum oder? Ich denke mal parallele Busse werden eher nicht zurückkommen für Verbindungen die über mehr als 10cm gehen.

 

[Rastafari]

direkt an den Speicher&Adress Bussen hängen - da ist ein neues Filesystem angesagt

Und das hat auch schon einen Namen. Verblüffenderweise ist das "gar kein" Filesystem mehr.

 

[FritzS]

Nenn es halt einfach „Datenverwaltungssystem“

Ich hatte seit Windows NT 3.11mit viel NTFS zu tun. In all den Jahren konnte ich mich von der Robustheit von NTFS überzeugen, selbst wenn das System „zerschossen“ war, konnte man die Partition noch immer reparieren (falls die Festplatte keinen HW Fehler aufwies) und aus einem anderen System heraus mounten. Ich habe auch mehrmals Stromausfälle mit hunderten von Clients erlebt - da gab es meiner Erinnerung keine Probleme, außer dass Windows beim Booten ein chkdsk laufen lies.
Ich rede hier vom Filesystem und nicht von Windows - damit alles klar ist! Ich will hier kein Mac Bashing betreiben, betrachte nur HFS+ etwas kritisch.

Nun hatte ich dreimal hintereinander einen Systempartition Crash bei dem es Mac OS X mit Bordmitteln nicht gelang zumindest lesend auf diese HFS+ Partition zuzugreifen. Unter Linux bzw. mit einem Recovery Tool war dies sehr wohl möglich und ich hätte damit viele Dateien retten können. Ich habe mich nur aus Neugierde damit befasst.

Wenn Du nun sagt „Einzelschicksal“ - da muss ich Dir widersprechen. In einer anderen Diskussionsrunde von Professionisten welche Mac Netze verwalten, wird die Robustheit und „Unkaputtbarkeit“ von HFS+ sehr wohl angezweifelt. Als Server werden hier meistens Maschinen mit ECC RAM und einem OS das ZFS beherrscht eingesetzt, man verlässt sich bei Servern mit heiklen Daten nicht auf HFS+. Bei manchen Anwendungen werden sogar mittels eines Tools zusätzliche Checksummen generiert um die Integrität der abgesicherten Dateien ja sicher zu stellen (das war selbst für mich neu). Diese Profis verlassen sich nicht auf die Zuverlässigkeit von Checksummen welche vom Festplatten Controller (unterhalb des Filesystems) erstellt werden.

Von den vielen Mac Computer kann anscheinend nur der MacPro mit ECC RAM umgehen. Ich vermute nun bei meinen drei Crashes eventuell auch Bit-Kipper im RAM, welche während des Sleep-Modus Zyklus auftraten. Das muss nicht unbedingt durch ein kaputtes RAM passieren, kann auch z.B. von der Stromversorgung verursacht sein. Das Logik-Board ist ja auch schon älter.
.

 

[Rastafari]

Bei manchen Anwendungen werden sogar mittels eines Tools zusätzliche Checksummen generiert um die Integrität der abgesicherten Dateien ja sicher zu stellen

Niemand hindert dich, das gleiche auch mit x-beliebigen anderen Dateisystemen zu tun.

Diese Profis verlassen sich nicht auf die Zuverlässigkeit von Checksummen welche vom Festplatten Controller (unterhalb des Filesystems) erstellt werden.

Diese Profis benötigen diese Prüfsummen auch auf entfernten Systemen und in ganz anderen speziellen Situationen. Beispielsweise für ein blitzschnelles Aufspüren von Dateiduplikaten auch in monströsen Datenbergen von hunderten oder tausenden TB. Die internen Datenstrukturen von ZFS sind da exakt genauso nutzlos. Hat schon seinen Grund, dass zB Google sein ganz eigenes spezialisiertes Filing-System entwickelt hat (GFS). Ganz andere Aufgabenstellungen erfordern eben auch ganz andere Lösungen.

Das spricht alles genausowenig gegen HFS+, wie die blosse Existenz der Energiegewinnungs-, Antriebs- und Lebenserhaltungssysteme an Bord der ISS einen betagten Mercedes der S-Klasse ganz pauschal zum veralteten, überholten und erneuerungsbedürftigen Objekt machen würde. Selbst dann nicht, wenn der schon (bzw erst) 20 Jahre auf dem Buckel hat.
Falsche Fragestellungen führen zwar oft zum gewünschten, aber grundsätzlich nie zum richtigen Ergebnis.

 

[FritzS]

Die Profis die ich meine verlassen sich nicht auf HFS+ auf Servern!

 

[Rastafari]

Echte "Profis" verlassen sich lieber auf einen mit viel Bling-Bling dekorierten Ableger des antiken UFS Dateisystems, das Apple (und andere) längst als Urne in die Gruft gestellt hatten. Sie bezeichnen diese an Dampfmaschinen erinnernden Relikte aus der frühesten IT-Steinzeit gerne als "richtiges, gestandenes Unix-FS" - warum auch immer.
(GNU/Linux ist halt noch nicht wirklich weiter gekommen als bis da hin.)

 

[FritzS]

Du willst uns ja nicht ernsthaft weismachen wollen, dass HFS+ das wahrlich beste, schönste, neueste und vor Allem zuverlässigste Filesystem in der gesamten IT Landschaft wäre? :rolleyes: