Beiträge von guckux

Nunja, ich schließe mich den Skeptikern für eine Neuauflage von Raumpatrouille Orion an - das besser zu machen, wird schwierig, aber bestimmt schwerpunktmäßig bei denen, die älter sind...

Beim Anhalter durch die Galaxis seh ich das definitiv so, die BBC-Serie verstand ich als Kind nicht, dann habe ich in der Jugend die Bücher gelesen und Douglas "verstanden", plötzlich war diese Serie, in der Marvin durch einen Menschen mit Ofenrohren an den Gliedmaßen dargestellt wurde, "genial"

Vorsicht: opencore kann zwar ohne Probleme von einer "Standard-APFS-Disk" starten, wenn man aber zB ein Fusion-Laufwerk erstellt hat, benötigt man noch den apfs.efi in der Konfiguration!

Ich habe in meinen Anfangszeiten viel an irgendwelchen Stellschrauben gespielt, und in den Jahrzehnten lernen dürfen, daß die DEFAULT-Einstellungen idR immer die Besten sind.

Mittlerweile bin ich viel mit Oracle-DBs unterwegs, und wer da nicht genau weiß, was er mit den 4987 (fiktiver Wert, es sind aber viiiiele) Stellschrauben bewirken kann (und viele sind komplex, haben also Abhängigkeiten untereinander) sollte die Finger davon lassen.

Viel sinnvoller ist es resourcenschonend zu arbeiten, weniger ist mehr!

Weniger -> je weniger Komplexität ich in ein System hineinbringe, desto einfacher ist die Handhabung bis inclusive. Update.

Resourcenschonend: einfach nur ne Shell verwenden, damit lassen sich die meisten Aufgaben lösen, perl mag mächtig sein, lädt aber im default zB erstmal viele MBs nach, ggfs noch ein paar weitere Module (weil die es so schön lösen), am Schluss habe ich für ne einfache Aufgabe zig MBs zu laden mit Haufen IO und MBs bis GBs an Speicherresourcen verbraten.

Das script löst die Aufgabe in 4.38s und das perl braucht dann den 10-100 fachen Arbeitsspeicher und 11.89s...

Mal herzlichen Dank an alle Diskussionsteilnehmer und so...

Mir unklar ist, wieso sich dergleichen auf die Bootzeit auswirkt. TRIM ist ein SATA/SAS command für SSDs, welches normalerweise aktiv durch das filesystem ausgeführt wird.

Also, ich lösche Dateien, dann hat das fs einen "TRIM-Befehl" zu schicken, welcher der SSD (egal ob SATA oder m.2/nvme) mitteilt, die Blöcke x, y etc. sind gelöscht worden, lösche sie in Deinen Zellen und das zur Laufzeit...

Ich kann das jetzt schlecht "kreuzverifizieren", meinen Server (FreeBSD) reboote ich höchstens 2mal im Jahr, die Workstation habe ich jetzt erst auf SSD umgestellt, da muss ich auch erstmal schauen, was mir mein BSD erzählen kann...

Normalerweise würde ich erwarten vom APFS, daß es zur Laufzeit der SSD via TRIM mitteilt, daß Blöcke nicht mehr genutzt werden und nicht erst beim nächsten Neustart...

TRIM zu enablen ist in meinen Augen "ein Streicheln" der SSD, wenn es kontinuierlich ausgeführt wird.

Mir stellt sich gerade die Frage, ob die Ausführung von TRIM regelmäßig ausgeführt die Bootzeit nur um wenig länger verlängert - und die Meldungen, daß es so lang dauern würde nur bei erstmaligem Ausführen ist.

Zumindest würde ich meinen, es tut auf lange Sicht der SSD gut und definitiv sollte es auf die Gesamtperformance der SSD umso sinnvoller sein, je mehr auf der SSD an Daten gespeichert sind und Daten dort bewegt werden. Stelle ich das in Bezug auf die Erforderlichkeit, regelmäßig zu en- und dann wieder zu disablen, sorry, wieso soll ich nicht vorhandene Automatismen nutzen um manuelle Tätigkeiten zu provozieren, welche dann auch noch einen erheblichen Zeit und Tätigkeitsaufwand erfordern? Nur um ein paar Sekunden Bootzeit für ein, zwei Wochen zu gewinnen?

Nachdem man hier nach mir rief, muss ich auch noch ergänzend meinen Senf dazu geben:

LFS wäre ein filesystem, nachdem Du hier suchst griven

Ich kenne das noch aus den Anfangszeiten von BSD, log structured filesystem, ein filesystem welches für sich in Anspruch nimmt, Dateien in EINEM Stream (zusammenhängende Blöcke auf der disk) auf der Platte gespeichert zu haben - und somit auch nur EINEN zusammenhängenden freien Bereich.

Also der Tod der Fragmentierung!

Weiß aber nicht ml, ob das aktuell noch unter FreeBSD supported wird...

Ich betrachte das (mittlerweile) nur aus theoretischer/philosophischer Sicht

PS: Grundsätzlich TRIM enablen, meine Empfehlung, ob die Garbage Collection bei dem einen oder anderen nen tick schneller oder langsamer ist, who cares? Irgendwann schlägt es zu - und dann ist definitiv lahm...

6 Tage noch und schon Spekulationssammlung...

OK, ich tippe neben runderneuerten iPads und sonstigem Kleinkram auf einen iMac M1x und - etwas "unwahrscheinlicher" aber wünschenswert nen MBPro 16"-M1x

Merci!

Scheint wohl wieder OK zu sein, zumindest auf den ersten Blick - das Problem kenn ich noch von vB

Das ist so nicht richtig.

Wenn kein TRIM läuft und alle Zellen mal beschrieben waren, DANN wird es grottenlangsam, weil erst die nicht mehr belegten "freien" Zellen freigeräumt werden müssen, bevor neue Daten geschrieben werden können.

TRIM beugt diesem Vorgang vor und macht dies "Häppchenweise" im aktiven Betrieb.

Nähere Infos hier.

bluebyte

Referenz

Yep - als ich meinen Server neu aufsetzt (i5-6600) mit m2-SSD war ich anfangs zu langsam, um dem Boot-Vorging zuvorzukommen, nachdem weitere 6 Platten installiert waren, wurde es "gemächlicher" - ist also normal.

Bei FreeBSD und auch linux Bootvorgängen kann man das schön am Bootlog verfolgen :p

Hier wurde schon mehrfach jetzt auf den Austausch der SSD gegen eine m2 angebundene nvme hingewiesen - ich bin der Meinung, daß dies kein besonderes performance-improvement bietet, da die IO-Leistung im reinen Datendurchsatz nicht entscheidend ist, von den IOPS ganz zu schweigen (die nvme-SSD IOPS sind vergleichbar mit denen einer SATA-angebundenen SSD).

Nähere Ausführungen hier.

Definitiv sollte/kann die Speicheraufrüstung sinnvoll sein, schau - wie schon empfohlen, was an genutzter Auslagerungsdatei genutzt wird in der Aktivitätsanzeige.

Ich würde auch den Austaisch des i5 gegen einen i7 als nicht sehr leistungssteigernd betrachten, die zusätzlichen "cores" zeigen nicht flächendeckend in den Applikationen einen Mehrnutzen, die Hyperthreads können sogar "bremsend" sich auswirken (je nach Applikation).

Einen Umstieg auf M1? Das wäre sowas wie der Umstieg vom Käfer auf nen Porsche

Guckux

Seit ein paar Tagen (oder Wochen) fallen mir vermehrt Bilder auf, welche über die Darstellungsbreite sich erstrecken - normalerweise kenne/kannte ich das so, daß sie durch responsive Design im Rahmen der Darstellungsbreite bewegen, in letzter Zeit vermehrt mir aufgefallen die "ausufernde" Breite - so zB in diesem Beitrag mit seinem Movie.

aber auch hier - mit PNG-Bild.

so - mal schauen - ein screenshot, ob der auch ausufernd dargestellt wir:

nope - wird korrekt dargestellt, Bild in Beitragsbreite...

Ich meine da garnix

Diese FCPGAs (oder wie die heißen) sind hochspeziell, korrekt, das Teil könnte auch verändert werden etc...

In das SOC mit drauf/hinein? Nein, würde ich nicht vermuten, macht keinen Sinn, der M1 ist jetzt schon ein "Trümmer", wenn da noch ein paar cores dazukommen, ist das eine Sache, aber keine so hochspezifischen Dinge...

Ich kenne mich da im Video-Bereich wenig bis gar nicht aus, ist schon >2 Jahrzehnte her, daß ich das mal "streifte", im Bildwerk FFM, wenn ich mich recht entsinne, SGIs für 40,000 Mark mit 80,000Mark teuren Videokarten und nochmal das Ganze für die entsprechende Software... aber praktisch nix mit zu tun gehabt

griven

Du betrachtest den "M1" als ein SOC...

Ich sehe darin primär nur einen RISC - daß die GPU mit drinne ist, muss ich mich erst dran gewöhnen...

Alternativ könnte Apple zB auf die Idee kommen, ihre Afterburner für den Apple Silicon zurecht zu machen...

Ja, Apple ist im grafischen Bereich groß geworden, daß war jahrelang ihre Milchkuh, weil dort Geld verdient wurde...

Heutzutage ist das grafische Gewerbe richtig hartes Brot geworden - da wird gefeilscht ohne Ende und der billige Digitaldruck tut seines noch dazu.

Video? Keine Ahnung, wie das in dem Markt ausschaut, ob dort noch vernünftige Margen zu haben sind...

Deshalb würde ich unterstellen, daß Apple sich langsam an den Massenmarkt annähert - mit dem iPhone haben sie eine ziemliche Marktmacht bei den Smartphones erlangt, bei den Macs sind sie noch etwas "abgehoben" und eher im Business/Profi-Preissegment, mit den ersten M1-Macs haben sie eine Preissenkung eingeführt (ob aus marketing oder Anfütterungsgründen, werden wir wohl vorerst nicht erfahren).

In den letzten Jahren gehören sie zu den Rekordhaltern bei Firmenzukäufen, ich würde gerne vermuten :D, daß sie hier noch mehr als ein As im Ärmel haben um den Konsumenten mehr bieten zu können...

Auch wenn meine Prognosen zur M1-Ankündigung in meinen Augen noch untertrieben waren - in diesem Falle wage ich keine weiteren - die Frage wird davon beantwortet werden, wie die zukünftigen M1x sich skalieren lassen... und parallel dazu ihre Anbindungsmöglichkeit, ihre GPU und nicht zu vergessen, die neuronalen KI-Einheiten... letztere könnten ein beträchtliches Potential beinhalten - aber ich habe noch nicht viel darüber lesen können, außer daß das ein oder andere Bildbearbeitungsprogramme in einzelnen Funktionen davon partizipieren sollen...

PS: Mein MBPro17 ist jetzt 10 - ich bin damit zufrieden, mein SE (old) ist auch "betagt" und tut alles was es soll - im Gegensatz zum Mac, schneller als ich es brauche

Guckux

Dieser Tage bin ich mal wieder über das Festplatten-4k Problem gestolpert und dachte mir, guggst Dir mal Deine Config an - mal einfach so...

Dabei stellte ich fest - ich habe die Festplatten "raw" einfach per zpool create erstellt, so daß die genutzte Kapazität bei sec63 anfängt - da scheinen die zfs-tools wohl noch etwas "Modernisierung" vor sich zu haben...

Ergo: Spiegel neu aufbauen damit die Blöcke richtig gesetzt werden - dabei habe ich mal durch die Reihe performance-Tests gemacht - war vorher im praktischen Betrieb nicht "unzufrieden" - aber die Werte enttäuschen mich etwas...

Hardware: i5-6500 (4x 3.2GHz), 32GB DDR4 Ram, SATA-6G Anbindung,

2x ST4000DM004-2CV104 0001 (4TB), System auf nvme SSD Samsung 950 Pro 512GB

FreeBSD 12-STABLE von Anfang März, bonnie++ (1.98) zum stressen und messen... (ich weiß, daß Teil ist und kann böse sein, bin aber der Meinung, es ist mit am ehrlichsten)

Aufgefallen ist mir beim testen:

Beim rewriting beobachtet mit systat :zarc, daß die einzelne disk etwa 50% mehr Durchsatz anzeigt als zpool iostat auf dem pool...

Beim lesen passt es - rund 2x Durchsatz vom systat:zarc zum zpool iostat

Etwas enttäuschen mich die Lesewerte beim bonnie++ beim "final-raid"

bonnie++ -r 32768 -m server -u root

gpart show ada3

=> 40 7814037088 ada3 GPT (3.6T)

40 2008 - free - (1.0M)

2048 7814033408 1 freebsd-zfs (3.6T)

7814035456 1672 - free - (836K)

gpart show ada5

=> 40 7814037088 ada5 GPT (3.6T)

40 2008 - free - (1.0M)

2048 7814033408 1 freebsd-zfs (3.6T)

7814035456 1672 - free - (836K)

"Vernünftige" Darstellung bedingt 80Zeichen Breite!

Hier sieht man deutlich schlechtere Werte als im vorstehenden Block - seq. output Block 10MB/s zu 78MB/s, rewrite 8k3 zu 46m, seq Input Block 2.7g zu 229m????? dfür mit einem Bruchteil der CPU-Last...

Danke pebbly für die links - wenngleich sie mir nix Neues erzählen (Ich mache mit ZFS rund 15 Jahre und habe manchen "Bug" miterlebt).

Yep kaneske DEN direkten Zusammenhang von ZFS und ECC gibt es nicht Wenn Dir günstig/kstl. ein ECC-basierender Server ins Haus gewandert ist, ist das schön, ich hätte hier auch zB ne Oracle/Sun 4150 und sogar 4170 haben können, war mir aber zu laut

Wie Du schreibst, es ist auch ne Geldbeutel-Sache - und mein Serverchen "höre" ich nicht, und es braucht relativ wenig Strom... Man kann sogar bei ECC-Server den "Ram spiegeln" - aber alles darf in Relation gesetzt werden. Je mehr Aufwand ich betreibe, desto arbeitsintensiver ist das Teil, im Fehlerfall ebenso wie bei nem System-update.

Ersatzfestplatten ist schön (mir schon passiert, daß im Raid5 eine hops gegangen ist und ih nicht zeitnah die Platte ersetzte, im Endresultat hat eine 2te nen Schlag gekriegt und mir sind "unwichtige" Daten erstmal hops gegangen ). Unter dem Strich - yep, daß beste NAS-Konzept bringt nichts, wenn man kein vernünftiges Backup hat - in meinem Falle versionsorientiertes Bänderbackup auf LTO-tapes (Datensicherheit für 10Jahre+). DA finden sich dann die wichtigen Daten.

Zum ZFS und Speicherhungrigkeit, daß ist bei anderen System nicht viel anders, alles lebt vom Speicher, ZFS gilt halt als "gierig" (bei meinen 32GB idR die Hälfte bis 2/3 vom ZFS belegt).

Wenn ich meinen privaten Server unter FreeBSD/ZFS vergleiche mit den beruflich betreuten (Solaris11/ZFS) dann sind letztere meinem Empfinden nach agiler und schneller, aber das sind auch eher Boliden - Enterprise halt...

In meiner Vorgängerfirma hatten wir EMC-Storage mit NLSAS (Bear-Line SAS Platten, im Prinzip zertifizierte SATA-Disks) 4x 4TB in R5 Gruppen, da haben wir hochgerechnet, wenn die "voll" sind, wird bei einem Recovering (Austausch einer Festplatte) im Prinzip schon die Festplattenerrorquote erreicht (MTBF). Enterprise-Platten wiederum haben meist ne 10er Potenz (oder mehr) beim MTBF als Desktop-Platten - und trotz dessen hat sich google entschieden, in seiner Infrastruktur Desktop-HDs einzusetzen...

so ganz steige ich durch Deinen Kommentar nicht durch :-?

Ohne ECC und den damit verbunden Speicher-Bit-Fehlern speichert JEDES filesystem die fehlerhaft gelieferten fehlerhaft ab.

Was meinst Du "in-Memory Management/Feature"?

Wenn man günstige Hardware (wie Du und ich) einsetzt, kann man jederzeit ZFS einsetzen und kann die Vorteile des ZFS nutzen (einfach zu bedienendes Volumemanagement und coole Features für Sicherheit etc) und hat als eine der vielen möglichen Fehlerquellen wie bei allen anderen filesystemen den "Storagecontroller" (Rechner ohne ECC und seine Komponenten).

Seufz - hier wird der "generelle" Vorteil von ECC ausgeführt, als schließende chain in der Kette der Fehleranfälligkeiten, vergleichbar mit den SPOFs eines redundanten Systems oder gar eines HA-Clusters.

Ich sehe in der Ausführung des von Dir genannten links keine "Abhängigkeit" von ECC zu ZFS, ZFS könnte man da auch durch jedes andere filesystem ersetzen und es wäre genauso gültig.

Nur eben, daß ZFS das self-healing-feature implementiert hat um Fehlern in filesystem-Daten vorzubeugen.

Die Aussage "ZFS nur mit ECC betreiben" halte ich in diesem Sinne überzogen, sie wäre gültig, wenn man ein HA-Storage aufbauen möchte, dann muss man aber die storage-controller ebenso redundant aufbauen, wie die storage-heads und alle Anbindungen und Verbindungen.

Also so etwas wie es Oracle mit seinen Exadatas macht, 2 Exadata, 2 ZFS-Appliances, 2 Infini-Band (oder jetzt neu 2x 100Gb-switches), 2 Exastores.

Alles in sich selbst nochmal redundant (also 2 Netzteile, 2 Storage HBAs, 2 Infini-Band HBAs, 2 Network HBAs etc. etc.).

Wie geschrieben, die Aussage alleine zu beziehen auf den Zusammenhang ECC<->ZFS ist meiner Ansicht nach "überzogen" und in Bezug auf die Nennung eines spezifischen filesystems mit der Suggestion einer Bedingung, welche für das genannte filesystem sich nachteilig auswirkt. JEDES andere filesysteme hat die gleichen Abhängigkeiten zur fehlerfreien Datenlieferung aus dem Speicher!

Bei solchen Aussagen sollte die GESAMTE Fehlerkette mit einbezogen werden, angefangen bei Enterprise-Festplatten bis hin zum Enterprise Backup-System.

Guckux kaneske

Du schreibst ZFS "nur" mit ECC-Ram zu betreiben...

Kannst Du das mal bitte näher ausführen? Mir ist das nicht "schlüssig", Speicherfehler im RAM vorzubeugen ist mir schon klar, aber der Zusammenhang mit Storage ist mir nicht bekannt - außer, daß fehlerhafte Daten aus dem Ram auf dem Storage landen - das ist dann aber ebenfalls für jedes andere filesystem gültig.

ZFS wiederum selbst hat eine self-healing Funktion, diese funktioniert wiederum nur dann, wenn das Storage redundant aufgebaut ist (Raid1, Raid10, Raid5, Raid50 etc.)

ZFS selbst zu verwenden hat in meinen Augen nur Vorteile - Nachteile sind, daß es für Performance Speicher braucht, mehr Speicher, nunja, gaaaanz viel Speicher - bei BSD kann man diesen auch "begrenzen/einschränken" über entsprechende kernel-parameter (linux kenn ich mich da nicht aus, würde es aber auch dort unterstellen wollen).

Hintergrund ist, das ZFS seine Performance aus den zbufs (zfs-buffer) schöpft, so sollte man ein RAID10 nur mit raid1+raid1+raid1+raid1 erstellen und nicht mit raid1(raid0+raid0).

Dedup sollte man gerade bei Speichermangel deaktivieren, oder eine SSD mit L2ARC cache einsetzen...

Bei mir läuft jetzt seit >>10Jahren mein home-Server mit ZFS stabil und zuverlässig... auch beruflich (Ninja, die Server haben dort ECC ) sehr gut

Ah - ein Neuer!

Frischfleisch!

Herzlich Willkommen