Hintergrund:
1. Ich arbeite mit einem MBP mit M1 pro-Prozessor und derjeweils aktuellsten Version von macOS
2. Ich hatte neulich einen Fall eines extremen Datenverlust (30+ TB) auf einer Synology DS1815+, der hier erschöpfend diskutiert wurde, ohne dass eine Ursache identifiziert werden konnte. Dieser Datenverlust hat mich dazu gebracht, nach alternativen RAID-Systemen zu suchen. Derzeit benutze ich neben der Diskstation eine OWC Mercury Quad Pro im RAID 5-Modus.
3. Auch auf diesem RAID-System kam es in den letzten Tagen wiederholt zu Datenverlusten. Daten wurden auf das RAID kopiert (und von mir auch von dort aus weiterverarbeitet).
4. Ich leide an einer generellen Instabilität meines macOS. Wiederholte Crashs werden vom System immer mit der Einleitung kommentiert, dass eine Kernel panic von einem Prozess Namens "USB-Tart" ausgelöst wurden. An meinem MBP betreibe ich per Thunderbolt ein LG 5K-Display mit USB-C 3fach HUB an dem wiederum ein alter Anker 7fach USB 3 Portreplikator läuft. Das OWC Mercury-RAID ist an einem zweiten Thunderbolt-Anschluss des MBP angeschlossen, läuft aber als USB-C 3.1-Anschluss (das OWC hat kein Thunderbolt.

Beobachtungen:
In den letzten Tagen hatte ich leider wiederholt die Gelegenheit, das Verhalten des OWC-RAIDs nach Kernel panics zu beobachten.
Dabei hat sich wiederholt der Verlust von großen Datenmengen gezeigt (und ist auch nachweisbar, s.u.), die jene Daten betreffen, die während der Sitzung geschrieben wurden, die durch den Crash beendet wurde. Diese Daten waren jedoch vor dem Crash unzweifelhaft auf dem OWC-RAID vorhanden und abgespeichert, was ich unter anderem anhand von Foto-Dateien beweisen kann. Gestern importierte ich eine Anzahl von RAW-Bildern in meine Fotobearbeitungssoftware und exportierte anschließend jpegs nach Fotos. In Fotos, dessen Mediathek auf einer einzelnen externen HDD liegt, sind die Bilder auch heute, nach einem erneuten Crash, noch vorhanden, nicht jedoch in meinen Verzeichnissen für RAW-Daten auf dem OWC-RAID.
D.h., dass die fertig geschriebenen RAW-Dateien nach dem Crash von dem OWV RAID verschwunden sind (vermutlich wurden sie im Inhaltsverzeichnis entfernt oder nicht aus einem vorübergehenden Inhaltsverzeichnis in das endgültige Inhaltsverzeichnis des RAIDs übertragen. Meine Fotos-Mediathek liegt übrigens nicht auf dem OWC-RAID, sondern wie gesagt auf einer herkömmlichen externen Festplatte, weshalb sich die importierten jpegs dort erhalten haben.
Vermutlich erklärt dieses Verhalten nach Crashs auch meinen oben verlinkten Datenverlust auf der Synology. Ich hatte ja angegeben, dass ich vor dem Verlust Ordner verschoben hatte. Es wäre also gut möglich, dass diese Ordner im Inhaltsverzeichnis der Sybology nicht in das endgültige Verzeichnis übertragen wurden, weil sich vor dem nächsten Herunterfahren ein Crash meines Systems ereignet hat. Das würde auch erklären, warum der Speicherplatz auf der Synology nach dem Ereignis nicht freigegeben wurde.
Ich vermute den Bug übrigens in macOS, weil ich mir nicht vorstellen kann, dass Synology und OWC SodtRAID den gleichen Fehler als Reaktion auf Crashs des verbundenen Computer eingebaut haben könnten.

Hat irgendjemand ähnliche Erfahrungen mit dem Verlust von "frisch geschriebenen" Daten auf seinem RAID gemacht? Halten die RAID-Experten hier den beschriebenen Verlust durch einen Fahler in macOS (Verhalten bei Crashs) für möglich?

Für euren Input wäre ich sehr dankbar!

Das ist technisch nicht möglich, denn ein Prozess kann keine Kernel-Panic auslösen, selbst wenn er das wollte. Du interpretierst offenbar Teile des Absturzberichtes falsch. Hast Du eine Kopie des Berichtes?

Auch die restliche Beschreibung ist größtenteils unsinnig. Eine Synology ist ein eigenständiger Computer, der seine Datenträger zu hundert Prozent selbst verwaltet. Für andere Computer, die über ein Netzwerk hinweg zugreifen, ist das lediglich ein abstrakter Fileserver. Ob dieser ein RAID benutzt oder nicht, können andere Computer überhaupt nicht "wissen" oder irgendwie ermitteln.

Nach einem System-Crash sind Datenverluste immer zu erwarten und völlig normal. Aber ob dabei eine Festplatte, eine SSD oder ein RAID zum Einsatz gekommen ist, ist völlig egal und kann mit dem Problem nichts zu tun haben.

Die einzige Ausnahme wäre, wenn das Software-RAID selbst die Ursache für den Absturz ist und fehlerhaft arbeitet.

Neulich wurde mal diskutiert, ob iStatMenu und SoftRaid dieses verhalten zeigen.

SoftRaid wurde schon vor zwei Monaten als Problem genannt

Danke für den Kommentar. Nur wie erklärst Du, dass durch die Abstürze Daten verschwinden (sie liegen definitiv nicht im Papierkorb), die bereits zwei Tage zuvor geschrieben wurden? Und die von dem RAID aus auch aktiv benutzt wurden, u.a. auch um RAWs in jpegs zu verwandeln und in Fotos zu exportieren? Solche Daten sollten sich dann deiner Meinung nach nicht in Luft auflösen können, was sie aber tun. Denn Abstürzen tut wie gesagt das MacBook Pro, nicht das OWC RAID mit SoftRAID.
Wenn, wie du sagst, die RAID-Systeme unabhängige Rechner sind (wovon ich auch immer ausgegangen bin), dann würde das bedeuten, dass macOS alle vor dem Crash geschriebenen Daten auf RAIDs (nicht auf einfachen Festplatten) nac einem Crash und Neustart aktiv löschen – was ein noch viel schlimmerer Bug wäre, als von mir vermutet.
Gemeinsam ist auf jeden Fall den beiden Datenverlusten auf der Synology wie dem OWC RAID nur der Computer mit dem auf beide zugegriffen wird. (Und ich habe gestern extra Malwarebytes heruntergeladen und laufen lassen. Befund: der Rechner ist völlig sauber.) Also was ist dann deine Erklärung? OWC habe ich übrigens bereits kontaktiert, aber noch keine Antwort erhalten.
Und hast du irgendeine Anmerkung zu diesem "USBtart"-Fehler? Ich habe Dir einen damaligen bsturzericht übrigens schon vor zwei Monaten mal hier über MTN geschickt.

Hast du einen Link dazu?

SoftRAID läuft nicht und lief nie auf der Synology, kann also kaum für den damaligen Datenverlust verantwortlich sein. Und der Hinweis kam ohne Link oder Beleg oder zeitliche Einordnung. Inzwischen ist schon SoftRAID 7.6 herausgekommen.

@Rosember
Wenn ich mir deine Beiträge ansehe, komme ich irgendwie zur Annahme das bei dir Murphy eingezogen ist. Irgendwie scheinen deine Systeme die Probleme regelrecht anzuziehen. Mit welcher wird denn hier gearbeitet? Hersteller und Versionsnummer wäre hilfreich. Es gibt ja nach wie vor einige Programme die nicht so wirklich gut mit externen Systemen klarkommen und man am besten die Daten lokal verarbeitet und dann auf das entsprechende Volume synchronisiert.
Wenn Daten "verschwunden" sind die schon vor 2 Tagen geschrieben wurden, so denke ich das diese noch physikalisch auf dem RAID vorhanden sind, durch den Crash aber das Inhaltsverzeichnis zerstört wurde, und daher die Probleme kommen.
Ich würde zuerst mal prüfen, woher diese leidigen Crashs kommen, sonst wirst du nie mit den eingesetzten Systemen wirklich zufrieden sein. Dein Problem mit den Kontakten scheint mir auch daher zu kommen.

Ja, Murphy ist bei mir vor ungefähr 10 Jahren eingezogen – und bleibt hartnäckig hier.
Die Fotobearbeitungssoftware ist DxO Photolab, derzeit in einer Testversion von Version 7. Da nicht nur Fotos betroffen sind, sondern auch Filmdateien, die ich in grundsätzlich anderen Ordnern des OWC RAIDs ablege, glaube ich nicht recht an diesen Ursprung der Probleme, zumal es sich bei DxO Photolab7 um eine vor knapp einem Monat veröffentlichte neue Version handelt.
Bei den Filmdateien handelt es sich um Downloads aus Mediatheken der öffentlich rechtlichen Sender. Ich bin in meiner Schilderung nur auf die Fotodateien eingegangen, weil ich hier in Form der jpegs harte Beweise dafür habe, dass die Originale überhaupt jemals auf meinem Rechner und dem OWC RAID gewesen sind. Bisher konnte ich das immer nur behaupten – auch gegenüber Synology übrigens.
Was Du zum Vorhandensein der Daten schreibst, ist genau das, was ich ausdrücken wollte: Irgendetwas (ich vermute macOS) verändert das Inhaltsverzeichnis des OWC RAIDS nach diesen (supernervigen) "USBtart-Crashs", so dass sämtliche (zumindest größeren, bei denen ich das überprüft habe) Dateien, die seit dem letzten Hochfahren des Macs auf das RAID geschrieben wurden. zumindest aus dem Inhaltsverzeichnis des RAIDs entfernt werden – wie auch immer das geschieht. Dass ich hier zu allerst an macOS denke, hängt damit zusammen, dass ein solches Ereignis besser als jede bisher vorgeschlagene Theorie erklärt, warum meine Synology über 30 TB an Daten verloren hat. Denn ich hatte auch zu jener Zeit im Juli bereits solche "USBtart"-Crashes. Außerdem benutzt die OWC Mercury mit SoftRAID ein vermutlich völlig anderes Prgramm zur RAID-Verwaltung als meine Synology.
Ob die Probleme mit den Kontakten auch daher kommen, halte ich derzeit nicht für sehr wahrscheinlich, aber lasse mich eines Besseren beleeren. Die Google-Suche nach "USBtart" hilft auch nict wirklich weiter, wenngleich ich danach meinen LG Ultrafein 5K auf die neueste Software-Version gebracht habe. Danach schienen die Abstürze etwas seltener zu werden, haben inzwiscen wieder die alte Frequenz erreicht (bis zu 6x pro Tag, dazwischen auch immer wieder mal für drei Tage keiner).
Ich rufe auf jeden Fall morgen den Apple Support an, um das Problem ausführlich zu diskutieren (und werde berichten). Außerdem rechne ich morgen mit einer Rückmeldung des OWC Supports, der i.d.R. sehr schnell reagiert.

Ich habe jetzt auch noch einmal an den Synology Support geschrieben, um auch von denen eine Stellungnahme zu erhalten.

6 Abstürze pro Tag und Du suchst nicht nach dieser Ursache? Egal welches OS, da ist der Wurm drin!wenn jetztder alte Anker 10 Jahre alt ist, hätte ich vielleicht eine Vermutung

Spaß beiseite, aber wenn mir die Kiste 6x am Tag abraucht, würde ich es zumindest einmal ohne weitere angeschlossene Hardware testen. Also auch ohne den LG und der weiteren etwas abenteuerlichen Peripherie. Wenn dann alles läuft, nach und nach die alte Hardware wieder dran hängen. Möglicherweise bekommst Du dann einen Schuldigen.

Falls das in dem anderen Thread schon erwähnt wurde - sorry, den habe ich mir nicht durchgelesen ...

Hätte denn jemand einen Vorschlag für einen moderneren USB-C-Hub (mit Stromversorgung) der ca. 7 Eingänge unterstützt? Ich finde immer nur Docks mit zig anderen Anschlüssen als USB-C, wenn ich nach sowas suche ...

Und – nur als Hinweis zu diesem Thread – das OWC RAID ist direkt am Mac angeschlossen. Ich halte es also für sehr unwahrscheinlich, dass der alte Anker-Hub (falls er denn die Crashs verursachen sollte) an den Problemen mit dem RAID beteiligt ist. Und ich bin der Meinung, dass kein OS nach einem Crash das Inhaltsverzeichnis von irgendwelchen externen Speichern um irgendwelche Einträge erleichtern darf.

Ich verwende RAIDS von Synology und DROBO seit Dekaden, und verschiedenste MBPs in den jeweiligen aktuellen OS Systemen. Ich habe mit diesen Systemen noch niemals einen selektiven Datenverlust erlebt. Das bedeutet nicht, das es so was theoretisch nicht geben könnte. Ich habe quasi Totalverlust aus persönlicher Blödheit und defekte Mainboards von DOBO und von Synology gehabt, aber niemals nur einzelne Bereiche.

Ich würde um eine Lösung bei deinem Problem zu finden deine verwendete RAID externe Hardware sequentiell austauschen, damit meine ich komplett jedes Teil auf die Liste setzen! Von Hub über Kabel (oxidierte Kontakte?, Switches und auch den damit korrespondierenden Mac, oder zumindest den Mac KOMPLETT neu aufsetzen - und keine Hobbysoftware installieren,
m2cent

4xUSB-C, 3xUSB-A

An Stelle von Synology würde ich Dir eine QNAP schenken

Danke für den Link. 7x USB-C scheint es aber nicht zu geben, oder? Ich wollte gerne mal ein adapterfreies Leben führen ...
Und, um noch mal nachzufragen: Wieso denkt ihr, der alte Anker USB 3-Hub könnte verantwortlich sein? Er hat bisher immer dem Standard entsprochen und besitzt keine eigene Firmware. Ich wundere mich einfach, dass die alten Standards plötzlich nicht mehr gelten sollen.

Es wäre nicht der erste Hub, der Ärger macht. Hat der Anker eine zuverlässige, eigene Stromversorgung?

Zum 7x USB-C: Geizhals hat eine gute Suchfunktion. Das Problem wird sein, dass 7x 5 Gbit/s = 35 Gbit/s sind. Womöglich ist 7x USB-C nicht mit den Spezifikationen der USB-Norm vereinbar (nur ein Gedanke).

Mein MBP habe ich nach Erwerb vor gut einem Jahr komplett neu aufgesetzt. "Hobbysoftware" habe ich nie installiert, keine Spiele kein etc. Ich hatte vor der OWC auch eine Drobo 5D3, die allerdings unter Ventura zu häufigen Kernel panics (mit Verweis auf Drobo) geführt hat, weshalb ich sie im Juli ersetzt habe. Bei den anderen Komponenten bin ich dabei, sie zu überprüfen. Einem Ersetzen sind allerdings zumindest beim RAID finanzielle Grenzen gesetzt. Was mir auch nict einleuchtet, ist woher der Verlust von allen Daten seit dem letzten Neustart des Macs kommt. Und über diesen Zusammenhang bin ich mir inzwischen sehr sicher. Als Erklärung kommen für mich eigentlich nur macOS oder SoftRAID in Frage (im letzteren Fall dann ohne Erklärung für die Datenverluste auf der Synology). Die "USBtart"-Crashs sind natürlich noch einmal eine eigene Geschichte, die ich nur zu gerne abstellen würde.

SoftRAID kenn ich nur aus dem dem schlechten alten OS9 (vor OSX), das hat das in meinem Verbund problemlos funktioniert. Mit SoftRAID und OSX habe ich keine Erfahrung. macOS hat in meinem Verbund noch nie Datenprobleme erzeugt, und ich habe grosse Daten Mengen. Und kenne aus meinem Beratungsbereich auch diverse Druckereien mit sehr großen Datenmengen und Raidsystemen, dazu noch im LAN, auch da gibt es KEINEN Datenverlust, sowas wäre undenkbar - sich damit abzufinden noch undenkbarer!
Nach deinen Erfahrungsberichten würde ich versuchen nach Fehlern in den Schnittstellen (auch Mac eigenen) zu eruieren. Was ist wenn eine Schnittstelle "Funken" sprüht und dadurch Datenpakete marginal beschädigt werden? Das HIFI Schnittstellen vergoldet werden ist zwar Quatsch, sind doch schlechte Kontakte nicht unbedingt mit Vergoldungen zu vermeiden, aber schlechte Kontakte sind, wenn auch nicht einfach zu Hören, tatsächlich Dynamik begrenzend.

Hier liegt wohl die Fehlerquelle. Die Stromzufuhr für angeschlossene Festplatten am Hub reicht sicher nicht aus.
Selbst wenn das Netzteil vom Anker Hub angeschlossen ist, kann es mit der Energieversorgung knapp werden. Die 5A sind ungleich fix verteilt. Festplatten haben einen Anlaufstrom. Auf Dauer können die das Netzteil schädigen. Und wenn man eine Festplatte durch Stromentzug plötzlich gestoppt wird , kann das zu Datenverlust führen.

Diese Aussage ist im Zusammenhang mit Raids ziemlich irrefuehrend und hoechst unwahrscheinlich.

Bei Deinen Ausfuerhungen, sowohl im alten Synology Thread als auch in diesem hier, wuerde ich mal behaupten, da steckt ein massiver User Fehler dahinter. Irgendwas ist bei Deinem System ohne Zweifel falsch konfiguriert.
Nachdem Dir sowohl auf dem Syno als jetzt auch auf dem OWC Daten abhanden kommen, untermauert das nur die Vermutung, dass keines der Systeme defekt ist, sondern irgendwas falsch konfiguriert ist. Vor allem weil ja das OWC direkt am MAC angeschlossen ist und das Synology uebers LAN verbunden ist.

Ich wuerde es so halten wie tarbi und nach dem Ausschlussverfahren vorgehen und ohne jegliche Peripherie auf die Fehlersuche gehen.
Eine erste Anlaufstelle fuer die Fehlersucher waere fuer mich die Rubrik User Rechte fuer Schreib und Lese Zugriff.
Auch so lapidare Dinge wie System Datum und Zeit wuerde ich mal checken.

Ich stolpere gerade über diesen Thread weil ich auch den mit dem Synology-Problem verfolgt habe (der mich interessierte weil ich selbst auf Synology setze seit vielen Jahren) – und bei allem Respekt möchte mir ein: WTF entfleuchen

HIER schreibst Du (plötzlich), dass Du Kernel Panics hast… und setzt nach, dass bis zu 6x am Tag für Dich eher "normal" seien?!

Ich erinnere mich nicht, dass Du das im Synology-Problem-Thread erwähnt hättest und, das fand ich jetzt auch, im Kontakt-Verlust-Thread auch nicht. Nun bin ich sicherlich kein ganz normaler User weil ich nicht nur Anwender sondern auch als Software-Entwickler unterwegs bin, wenn auch nicht wirklich am Mac. Ich muss mich aber schon wundern, dass Du
a) bis zu 6 harte Abstürze (Kernel Panic ist quasi der Blue Screen von Windows) akzeptierst oder gar als (Deinen) Normalzustand empfindest und wenn es mal keiner oder nur 3 am Tag sind, ist doch alles fluffig…
b) Du scheinbar überhaupt keinen Zusammenhang zwischen diesen Problemen zu sehen scheinst (also hier, in diesem Thread, vielleicht ein bisschen aber offenbar auch nicht wirklich, sonst wäre das schon im Synology-Thread eine der ERSTEN Informationen für die andere gewesen)

Ich schließe mich der dringenden Empfehlung anderer hier an:
- Als ERSTES würde ich an Deiner Stelle die Ursache für die Abstürze finden!

Wenn ein System so hart abschmiert, hat es in dem Augenblick auch keine Chance irgendetwas zu "retten" - Was dann im Cache lag, was noch nicht vom Server bestätigt wurde, etc. pp. das kann im Zweifel einfach KAPUTT sein - also nicht unbedingt "weg" sondern eben auch defekt! Kann also auch sein, dass Du Dinge (Dateien/Programme) noch hast, diese aber defekte aufweisen weil sie intern kaputt gegangen sind – Das kann z.B. mit Datenbank sehr schnell passieren und die Auswirkungen sind unvorhersehbar und, für einen Support im nach hinein, schwer bis überhaupt nicht nachvollziehbar

USB-Hubs sind prädestiniert für Abstürze … USB an sich ist immer wieder ein Thema. Und Hubs erst Recht. Da verhält sich ein Gerät / ein Treiber nicht 100%ig sauber, da fällt die Spannung im falschen Augenblick für den Bruchteil einer Sekunde ein wenig zu sehr ab, da wackelt ein Kabel / Kontakt im falschen Augenblick …


Wenn ich mich an das erinnere, was ich über Probleme mit dem LG 5K alles las in der Vergangenheit (auch immer wieder im Kontext von am LG angeschlossenen USB-Geräten) … und dann noch ein 7x Hub hinten dran …

Ernsthafter Rat:
- Alles abklemmen, nur das Notebook nehmen. Einfach mal einen Satz Daten aufs Notebook woran Du gerade arbeitest und gucken was passiert … bei bis zu 6 crashes am Tag solltest Du schnell wissen, ob das stabil läuft wenn nicht: Defekt am Notebook ist wahrscheinlich.

- wenn das mal 2 Tage gelaufen ist, dann hängst Du mal EIN Gerät ans MBP und guckst wieder …
- Dann hängst Du mal den 7x Hub ans Notebook und daran EIN Gerät und schaust … dann ein weiteres …

Viel Erfolg bei der Suche – und denke daran: Wenn Du solche merkwürdigen Probleme wie Datenverluste hast und fragst, sag dazu, dass Du mehrere Kernel Panics am Tag hast …

Tja, klingt nach einer Idee, aber gerade die beiden Festplatten, die über den Hub angeschlossen sind funktionieren seit vielen Jahren ohne jeden Datenverlust. Ansonsten sind an dem Hub nur Drucker, mal ein USB-Stick und ähnlicher Kleinkram angeschlossen. Die von Datenverlust betroffenen Geräte sind ausschließlich RAID-Systeme, die entweder im Netzwerk hängen (Synology) oder über einen eigenen USB/Thunderbolt-Anschluss direkt am Mac hängen.

Der User-Fehler ist deine fixe Idee. Schau Dir mal an, was bei einer OWC/SoftRAID konfiguriert werden muss: Es ist so gut wie nichts (etwa im Vergleich zur Synology). Die Festplatten werden eingesteckt, über SoftRAID initialisiert, der RAID-Typ und die gewünschten Platten ausgewählt – und das Ding läuft. Und da es läuft, kann ich bei diesen wenigen Schritten nichts falsch gemacht haben.
Und am Mac, um auch mal den gemeinsamen Punkt von beiden Systemen anzusprechen, läuft ausschließlich nur das normale macOS im hochgesicherten Modus, d.h. ohne irgendwelche Kernel extensions etc., nur Standard-Software von großen und namhaften Anbietern. Ich installiere auch ausschließlich Software, die ich zu Arbeiten brauche. Keine Spiele, nix zum mal eben angucken - und eben auch nichts, was irgendwelche seltsamen Erweiterungen braucht. Und den Terminal nutze ich nur in höchster Verzweiflung, etwa als ich auf der Synology nach den verlorenen Daten gesucht habe. Ich bin quasi der langweiligste Mac-User, den man sich denken kann.
Ich kann Deinen Gedanken aber gut verstehen, weil ich bei meinen zuletzt sehr zahlreichen Problemen auch immer wieder an Apple-Supporter geraten bin, die genau solche Punkte und potentiellen Fehler endlos mit mir durchgegangen sind (inzwischen bekomme ich schon einen Schreikrampf, wenn diese Leute als erstes den abgesicherten Modus und einen neuen User anführen, die ich doch mal ausprobieren solle etc.).
Es ist tatsächlich so, dass ich mich manchmal frage, ob sich mein Computer überhaupt noch wie eine Maschine verhält, denn Maschinen verhalten sich berechenbar. Nur ausgerechnet meine Macs graben immer wieder neue Probleme aus, die niemand sonst hat , kennt oder – manchmal – auch nur für möglich hält. Alles, was bei tausenden anderer User sicher und verlässlich funktioniert, scheint bei mir rätselhafte Probleme zu machen.

Irgendwo auf Reddit. IIRC in r/MacStudio Woanders bin ich nicht.

Korrektur: gefunden.

War nicht das Hauptproblem eines SoftRaids, dass es beim Systemcrash zum Datenverlust kommen muss? Oder ist das mittlerweile obsolet?
Wenn das auch noch heute so ist, dann stellt sich die Henne/Ei-Frage: Stürzt die Bude ab, weil das Softraid rumnervt oder nervt das SoftRaid, weil die Bude abstürzt...

Damals(tm), als ich mich zwischen Soft- oder Hardraid entscheiden musste, meinte mein Berater: "Die Mischung aus externem Gehäuse und SoftRaid müsste verboten sein.". Das war aber 2008. Habe mich nicht mehr mit dem Thema befasst.

Die Anzahl der Crashes schwankt extrem. Mal sind es bis zu 6 am Tag, mal (und häufiger) ist es eine Woche lang kein einziger. Und - bei aller Richtigkeit, dass ich nach der Ursache suchen muss. Erklär mir bitte, wie ein Crash des Macs auf einem externen RAID-System zum Verlust von bereits vor zwei Tagen geschriebenen Daten führen soll? Es sei denn, irgendetwas an der Kommunikation zwischen Mac und RAID ist oberfaul und fehlerhaft.
Es is ja nicht so, dass der Crash mit irgendeinem Schreibvorgang interferiert und dann die aktuellen Daten weg sind, sondern es geht um bereits geschriebene Daten, z.T. sogar weiterverarbeitete Daten, die sich spurlos und im Fall der Synology nachweislich spurlos in Luft auflösen. Von den Crashes, an denen meine Macs seit ca. 6-10 macOS-Versionen leiden, habe ich immer wieder berichtet, sie aber aus obigen Gründen nicht in den Fokus meiner jeweiligen Probleme gestellt. Und alle betroffenen Geräte hingen direkt am Mac, nicht über Hubs oder den LG.

Wir hatten hier an anderer Stelle auch diskutiert, dass Rosember verhältnismäßig wenig freien Speicherplatz auf der internen SSD belässt. Auch dies kann zu Problemen führen.

Erstens habe ich längst deutlich mehr freien Speicher auf internen SSD, zweitens erklärt auch das nicht. was auf meinem RAID-System mit bereits geschriebenen Date passiert. Bleibt doch bitte mal beim Thema, statt hier Gerüchte zu verbreiten!

Du vermutest laut Ueberschrift einen Fehler im MacOS. Wie waers einfach mal den Mac komplett platt zu machen und MacOS ohne Altlast frisch zu installieren. Damit meine ich nicht updaten sondern frisch auf die formartierte SSD in Deinem MBP. Somit wirst Du den Fehler am schnellsten finden und es kostet Dich weniger Zeit als hier wieder und wieder das gleiche zu schreiben. Denn Vorschlaege nimmst Du ja leider nicht an oder tust Diese als Bloedsinn ab.

Welchen Vorschlag habe ich denn nicht angenommen? Etwa deinen, dass ich "irgendeinen groben Fehler" in der Bedienung mache?
Die Wahrheit ist doch leider die, dass ich wiederholt Probleme habe, zu denen auch hier und zu meinem großen Bedauern niemand etwas einfällt, was diese Probleme erklären könnte.
Aber danke für deinen persönlichen Angriff. Der wird mir bestimmt helfen, das Problem zu lösen und die Diskussion hier sicher deutlich schneller zum Ziel führen!

Einen neuen USB-Hub habe ich bestellt, kommt morgen.
Hier übrigens das Crash-Protokoll, das ich so oder ähnlich bei den "Dart-USB"-Crashes (sorry, USBtart, wie oben geschrieben hatte sich falsch eingeprägt, es heißt Dart-USB) bekomme (und ich bin nicht der einzige mit diesem Fehler: ):

panic(cpu 1 caller 0xfffffe0025ae24b0): "dart-usb0 (0xfffffe201976c000): DART(DARTBLK) error: SID 1 write protect exception on write of DVA 0xcad000 (TTBR 0 SEG 0 PTE 0x32b) ERROR_STATUS 0x81000408 TIME 0x31e27692dbe6 TTE 0x400fff10354e5405 AXI_ID 0" @AppleT6000DART.cpp:1407
Debugger message: panic
Memory ID: 0x1
OS release type: User
OS version: 23A344
Kernel version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000
Fileset Kernelcache UUID: B5B971E36AEB2872B9B570E10D3D2BF3
Kernel UUID: BBDD4971-4AC1-34C9-B0E3-26B569022090
Boot session UUID: 4A9B5D6E-1B9D-4453-AC0C-52E7A192F90A
iBoot version: iBoot-10151.1.1
secure boot?: YES
roots installed: 0
Paniclog version: 14
KernelCache slide: 0x000000001bcec000
KernelCache base: 0xfffffe0022cf0000
Kernel slide: 0x000000001bcf4000
Kernel text base: 0xfffffe0022cf8000
Kernel text exec slide: 0x000000001d208000
Kernel text exec base: 0xfffffe002420c000
mach_absolute_time: 0x1327dc54132
Epoch Time: sec usec
Boot : 0x6534e2d2 0x0007fc19
Sleep : 0x6535bf94 0x000748db
Wake : 0x6535c37a 0x000358ce
Calendar: 0x6535c426 0x000027fd

Zone info:
Zone map: 0xfffffe1019658000 - 0xfffffe3019658000
. VM : 0xfffffe1019658000 - 0xfffffe14e6324000
. RO : 0xfffffe14e6324000 - 0xfffffe167fcbc000
. GEN0 : 0xfffffe167fcbc000 - 0xfffffe1b4c988000
. GEN1 : 0xfffffe1b4c988000 - 0xfffffe2019654000
. GEN2 : 0xfffffe2019654000 - 0xfffffe24e6320000
. GEN3 : 0xfffffe24e6320000 - 0xfffffe29b2fec000
. DATA : 0xfffffe29b2fec000 - 0xfffffe3019658000
Metadata: 0xfffffe302a230000 - 0xfffffe3032230000
Bitmaps : 0xfffffe3032230000 - 0xfffffe3034ff0000
Extra : 0 - 0

TPIDRx_ELy = {1: 0xfffffe24e36b7818 0: 0x0000000000000001 0ro: 0x000000016ba730e0 }
CORE 0 PVH locks held: None
CORE 1 PVH locks held: None
CORE 2 PVH locks held: None
CORE 3 PVH locks held: None
CORE 4 PVH locks held: None
CORE 5 PVH locks held: None
CORE 6 PVH locks held: None
CORE 7 PVH locks held: None
CORE 0: PC=0x00007ff89f60550c, LR=0x000000010238911c, FP=0x00000002025f4320
CORE 1 is the one that panicked. Check the full backtrace for details.
CORE 2: PC=0xfffffe002429ff18, LR=0xfffffe002429ff18, FP=0xfffffe5dcb8a3ef0
CORE 3: PC=0xfffffe00247b47cc, LR=0xfffffe00247b45e0, FP=0xfffffe5dcc18b4a0
CORE 4: PC=0xfffffe002429ff18, LR=0xfffffe002429ff18, FP=0xfffffe5dcbf83ef0
CORE 5: PC=0xfffffe002429ff18, LR=0xfffffe002429ff18, FP=0xfffffe5dcbf9bef0
CORE 6: PC=0xfffffe002429ff18, LR=0xfffffe002429ff18, FP=0xfffffe5dcc2e7ef0
CORE 7: PC=0xfffffe002429ff18, LR=0xfffffe002429ff18, FP=0xfffffe5dcc51bef0
Compressor Info: 15% of compressed pages limit (OK) and 12% of segments limit (OK) with 1 swapfiles and OK swap space
Panicked task 0xfffffe24e2c734a8: 13538 pages, 26 threads: pid 42023: mediaanalysisd
Panicked thread: 0xfffffe24e36b7818, backtrace: 0xfffffe44569af550, tid: 826761
lr: 0xfffffe0024265288 fp: 0xfffffe44569af5e0
lr: 0xfffffe00243be074 fp: 0xfffffe44569af600
lr: 0xfffffe00243aebcc fp: 0xfffffe44569af670
lr: 0xfffffe00243ad040 fp: 0xfffffe44569af760
lr: 0xfffffe0024213aa4 fp: 0xfffffe44569af770
lr: 0xfffffe0024264b64 fp: 0xfffffe44569afb20
lr: 0xfffffe0024a76808 fp: 0xfffffe44569afb40
lr: 0xfffffe0025ae24b0 fp: 0xfffffe44569afda0
lr: 0xfffffe0025ae2000 fp: 0xfffffe44569afe40
lr: 0xfffffe0025ae1844 fp: 0xfffffe44569afef0
lr: 0xfffffe002497c8b8 fp: 0xfffffe44569aff30
lr: 0xfffffe00255e8b38 fp: 0xfffffe44569affd0
lr: 0xfffffe00243b0464 fp: 0xfffffe44569affe0
lr: 0xfffffe0024213b18 fp: 0xfffffe44569afff0
Kernel Extensions in backtrace:
com.apple.driver.AppleT6000DART(1.0)[346EF674-05A1-3D60-8F49-ADFDD3BFF98D]@0xfffffe0025add1200xfffffe0025ae42ab
dependency: com.apple.driver.AppleARMPlatform(1.0.2)[46E2D12C-E153-3DD2-999C-FFF05EC8A75E]@0xfffffe0024c179400xfffffe0024c6a227
dependency: com.apple.driver.IODARTFamily(1)[F891B63C-A9DE-362C-A0B9-55A857151181]@0xfffffe00265ebb600xfffffe00265ff93f
com.apple.driver.AppleInterruptControllerV2(1.0d1)[A1A4C713-2CF8-3485-8348-49F483D98B7B]@0xfffffe00255e70700xfffffe00255e98df
dependency: com.apple.driver.AppleARMPlatform(1.0.2)[46E2D12C-E153-3DD2-999C-FFF05EC8A75E]@0xfffffe0024c179400xfffffe0024c6a227

last started kext at 2554063604: com.apple.filesystems.afpfs 11.4 (addr 0xfffffe00236723a0, size 52272)
loaded kexts:
com.apple.filesystems.afpfs 11.4
com.apple.nke.asp_tcp 8.3
com.apple.driver.SoftRAID 7.6
com.apple.UVCService 1
com.apple.driver.AppleHIDALSService 1
com.apple.driver.usb.realtek8153patcher 5.0.0
com.apple.iokit.SCSITaskUserClient 492
com.apple.driver.AppleUSBMassStorageInterfaceNub 556
com.apple.filesystems.autofs 3.0
com.apple.driver.AppleTopCaseHIDEventDriver 7400.26
com.apple.driver.AppleBiometricServices 1
com.apple.driver.CoreKDL 1
com.apple.driver.DiskImages.ReadWriteDiskImage 493.0.0
com.apple.driver.DiskImages.UDIFDiskImage 493.0.0
com.apple.driver.DiskImages.RAMBackingStore 493.0.0
com.apple.driver.DiskImages.FileBackingStore 493.0.0
com.apple.driver.BCMWLANFirmware4387.Hashstore 1
com.apple.driver.SEPHibernation 1
com.apple.driver.AppleUSBDeviceNCM 5.0.0
com.apple.driver.AppleFileSystemDriver 3.0.1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless 1.0.0d1
com.apple.nke.l2tp 1.9
com.apple.filesystems.tmpfs 1
com.apple.filesystems.nfs 1
com.apple.filesystems.lifs 1
com.apple.filesystems.apfs 2235.0.13
com.apple.IOTextEncryptionFamily 1.0.0
com.apple.filesystems.hfs.kext 650.0.2
com.apple.security.BootPolicy 1
com.apple.BootCache 40
com.apple.driver.AppleALSColorSensor 1.0.0d1
com.apple.driver.AppleSmartBatteryManager 161.0.0
com.apple.driver.AppleAOPVoiceTrigger 300.7
com.apple.driver.AppleThunderboltIP 4.0.3
com.apple.driver.ApplePMP 1
com.apple.driver.ApplePMPFirmware 1
com.apple.driver.AppleSmartIO2 1
com.apple.driver.AppleProResHW 325.0.0
com.apple.driver.AppleAVE2 703.6.9
com.apple.driver.AppleJPEGDriver 6.1.1
com.apple.driver.AppleEventLogHandler 1
com.apple.driver.AppleAVD 732
com.apple.AppleEmbeddedSimpleSPINORFlasher 1
com.apple.driver.AppleMCDP29XXUpdateSupport 1
com.apple.driver.AppleSN012776Amp 700.46
com.apple.driver.AppleMobileDispT600X-DCP 140.0
com.apple.driver.AppleM68Buttons 1.0.0d1
com.apple.driver.AppleCS42L84Audio 700.46
com.apple.driver.AppleDPDisplayTCON 1
com.apple.driver.AppleT6000SOCTuner 1
com.apple.driver.AppleT6000CLPCv3 1
com.apple.driver.AppleT6000PMGR 1
com.apple.driver.AppleS5L8960XNCO 1
com.apple.driver.AppleSamsungSerial 1.0.0d1
com.apple.driver.AppleSerialShim 1
com.apple.driver.AppleInterruptControllerV2 1.0.0d1
com.apple.AGXG13X 275.6
com.apple.driver.AppleS8000DWI 1.0.0d1
com.apple.driver.AppleS8000AES 1
com.apple.driver.usb.AppleSynopsysUSB40XHCI 1
com.apple.driver.AppleSDXC 3.4.3
com.apple.driver.AppleT8110DART 1
com.apple.driver.AppleBluetoothModule 1
com.apple.driver.AppleBCMWLANBusInterfacePCIe 1
com.apple.driver.AppleS5L8920XPWM 1.0.0d1
com.apple.driver.AudioDMAController-T600x 300.15
com.apple.driver.AppleT6000DART 1
com.apple.driver.AppleSPIMC 1
com.apple.driver.AppleS5L8940XI2C 1.0.0d2
com.apple.driver.AppleT6000 1
com.apple.iokit.IOUserEthernet 1.0.1
com.apple.driver.usb.AppleUSBUserHCI 1
com.apple.iokit.IOKitRegistryCompatibility 1
com.apple.iokit.EndpointSecurity 1
com.apple.driver.AppleDiskImages2 272.0.0
com.apple.AppleSystemPolicy 2.0.0
com.apple.nke.applicationfirewall 404
com.apple.kec.InvalidateHmac 1
com.apple.kec.AppleEncryptedArchive 1
com.apple.security.SecureRemotePassword 1.0
com.apple.driver.usb.IOUSBHostHIDDevice 1.2
com.apple.driver.usb.cdc.acm 5.0.0
com.apple.driver.usb.serial 6.0.0
com.apple.driver.usb.cdc.ecm 5.0.0
com.apple.driver.usb.AppleUSBXHCIPCI 1.2
com.apple.driver.usb.cdc 5.0.0
com.apple.driver.AppleUSBAudio 600.40
com.apple.iokit.IOAudioFamily 500.4
com.apple.vecLib.kext 1.2.0
com.apple.driver.AppleThunderboltPCIUpAdapter 4.1.1
com.apple.driver.AppleThunderboltDPOutAdapter 8.5.1
com.apple.driver.driverkit.serial 6.0.0
com.apple.iokit.IOAVBFamily 1200.18
com.apple.driver.AppleHSBluetoothDriver 7400.26
com.apple.driver.IOBluetoothHIDDriver 9.0.0
com.apple.driver.AppleHIDKeyboard 7400.2
com.apple.driver.AppleActuatorDriver 7400.42
com.apple.driver.AppleMultitouchDriver 7400.42
com.apple.driver.AppleMesaSEPDriver 100.99
com.apple.iokit.IOBiometricFamily 1
com.apple.driver.DiskImages.KernelBacked 493.0.0
com.apple.driver.AppleXsanScheme 3
com.apple.driver.AppleSEPHDCPManager 1.0.1
com.apple.driver.AppleTrustedAccessory 1
com.apple.iokit.AppleSEPGenericTransfer 1
com.apple.driver.usb.networking 5.0.0
com.apple.nke.ppp 1.9
com.apple.driver.AppleBSDKextStarter 3
com.apple.kext.triggers 1.0
com.apple.filesystems.hfs.encodings.kext 1
com.apple.driver.AppleSyntheticGameController 11.0.24
com.apple.driver.AppleBTM 1.0.1
com.apple.driver.IOHIDPowerSource 1
com.apple.driver.AppleCallbackPowerSource 1
com.apple.driver.AppleConvergedIPCOLYBTControl 1
com.apple.driver.AppleConvergedPCI 1
com.apple.driver.AppleBluetoothDebug 1
com.apple.driver.AppleUVDMDriver 1.0.0
com.apple.driver.AppleAOPAudio 300.14
com.apple.driver.AppleThunderboltUSBDownAdapter 1.0.4
com.apple.driver.AppleThunderboltDPInAdapter 8.5.1
com.apple.driver.AppleThunderboltDPAdapterFamily 8.5.1
com.apple.driver.AppleThunderboltPCIDownAdapter 4.1.1
com.apple.driver.AppleHIDTransportSPI 7400.34
com.apple.driver.AppleHIDTransport 7400.34
com.apple.driver.AppleSPU 1
com.apple.driver.AppleInputDeviceSupport 7400.34
com.apple.AGXFirmwareKextG13XRTBuddy 275.6
com.apple.AGXFirmwareKextRTBuddy64 275.6
com.apple.driver.AppleDCPDPTXProxy 1.0.0
com.apple.driver.DCPDPFamilyProxy 1
com.apple.plugin.IOgPTPPlugin 1200.91
com.apple.iokit.IONVMeFamily 2.1.0
com.apple.driver.AppleSART 1
com.apple.driver.DCPAVFamilyProxy 1
com.apple.iokit.IOMobileGraphicsFamily-DCP 343.0.0
com.apple.iokit.IOMobileGraphicsFamily 343.0.0
com.apple.driver.AppleM2ScalerCSCDriver 265.0.0
com.apple.driver.AppleDiagnosticDataAccessReadOnly 1.0.0
com.apple.driver.AppleNANDConfigAccess 1.0.0
com.apple.driver.AppleDCP 1
com.apple.driver.AppleCSEmbeddedAudio 700.46
com.apple.driver.AppleEmbeddedAudio 700.46
com.apple.iokit.AppleARMIISAudio 300.11
com.apple.driver.AppleFirmwareKit 1
com.apple.driver.ApplePassthroughPPM 3.0
com.apple.driver.ApplePMGR 1
com.apple.driver.AppleHPM 3.4.4
com.apple.driver.AppleSPMIPMU 1.0.1
com.apple.driver.AppleDialogPMU 1.0.1
com.apple.driver.AppleStockholmControl 1.0.0
com.apple.driver.AppleSPMI 1.0.1
com.apple.driver.AppleARMWatchdogTimer 1
com.apple.iokit.IOGPUFamily 93
com.apple.driver.AppleDisplayCrossbar 1.0.0
com.apple.iokit.IODisplayPortFamily 1.0.0
com.apple.driver.AppleT6000TypeCPhy 1
com.apple.driver.AppleT8103TypeCPhy 1
com.apple.driver.AppleUSBXDCIARM 1.0
com.apple.driver.AppleUSBXDCI 1.0
com.apple.iokit.IOUSBDeviceFamily 2.0.0
com.apple.driver.usb.AppleSynopsysUSBXHCI 1
com.apple.driver.usb.AppleUSBXHCI 1.2
com.apple.driver.AppleTypeCPhy 1
com.apple.driver.AppleEmbeddedUSBHost 1
com.apple.driver.usb.AppleUSBHub 1.2
com.apple.driver.usb.AppleUSBHostCompositeDevice 1.2
com.apple.driver.AppleThunderboltNHI 7.2.81
com.apple.driver.AppleT6000PCIeC 1
com.apple.iokit.IOThunderboltFamily 9.3.3
com.apple.iokit.IOPortFamily 1.0
com.apple.driver.ApplePIODMA 1
com.apple.driver.AppleT600xPCIe 1
com.apple.driver.AppleMultiFunctionManager 1
com.apple.driver.AppleBluetoothDebugService 1
com.apple.driver.AppleBCMWLANCore 1.0.0
com.apple.iokit.IO80211Family 1200.13.0
com.apple.driver.IOImageLoader 1.0.0
com.apple.driver.AppleOLYHAL 1
com.apple.driver.corecapture 1.0.4
com.apple.driver.AppleEmbeddedPCIE 1
com.apple.driver.AppleMCA2-T600x 800.11
com.apple.driver.AppleEmbeddedAudioLibs 300.1
com.apple.driver.AppleFirmwareUpdateKext 1
com.apple.driver.AppleH13CameraInterface 8.24.1
com.apple.driver.AppleGPIOICController 1.0.2
com.apple.driver.AppleFireStormErrorHandler 1
com.apple.driver.AppleMobileApNonce 1
com.apple.driver.usb.AppleUSBHostPacketFilter 1.0
com.apple.iokit.IOTimeSyncFamily 1200.91
com.apple.driver.DiskImages 493.0.0
com.apple.iokit.IOGraphicsFamily 597
com.apple.iokit.IOBluetoothFamily 9.0.0
com.apple.driver.AppleSSE 1.0
com.apple.driver.AppleSEPKeyStore 2
com.apple.driver.AppleUSBTDM 556
com.apple.iokit.IOUSBMassStorageDriver 240
com.apple.iokit.IOPCIFamily 2.9
com.apple.iokit.IOSCSIBlockCommandsDevice 492
com.apple.iokit.IOSCSIArchitectureModelFamily 492
com.apple.driver.AppleRSMChannel 1
com.apple.iokit.IORSMFamily 1
com.apple.driver.AppleLockdownMode 1
com.apple.driver.AppleIPAppender 1.0
com.apple.driver.AppleFDEKeyStore 28.30
com.apple.driver.AppleEffaceableStorage 1.0
com.apple.driver.AppleCredentialManager 1.0
com.apple.driver.KernelRelayHost 1
com.apple.iokit.IOUSBHostFamily 1.2
com.apple.driver.AppleUSBHostMergeProperties 1.2
com.apple.driver.usb.AppleUSBCommon 1.0
com.apple.driver.AppleSMC 3.1.9
com.apple.driver.RTBuddy 1.0.0
com.apple.driver.AppleEmbeddedTempSensor 1.0.0
com.apple.driver.AppleARMPMU 1.0
com.apple.iokit.IOAccessoryManager 1.0.0
com.apple.driver.AppleUVDM 1.0.0
com.apple.driver.AppleOnboardSerial 1.0
com.apple.iokit.IOSkywalkFamily 1.0
com.apple.driver.mDNSOffloadUserClient 1.0.1b8
com.apple.iokit.IONetworkingFamily 3.4
com.apple.iokit.IOSerialFamily 11
com.apple.driver.AppleSEPManager 1.0.1
com.apple.driver.AppleA7IOP 1.0.2
com.apple.driver.IOSlaveProcessor 1
com.apple.driver.AppleBiometricSensor 2
com.apple.iokit.IOHIDFamily 2.0.0
com.apple.driver.AppleANELoadBalancer 7.23.3
com.apple.driver.AppleH11ANEInterface 7.23.0
com.apple.driver.IODARTFamily 1
com.apple.AUC 1.0
com.apple.iokit.IOSurface 352.0.3
com.apple.iokit.IOAVFamily 1.0.0
com.apple.iokit.IOHDCPFamily 1.0.0
com.apple.iokit.IOCECFamily 1
com.apple.iokit.IOAudio2Family 1.0
com.apple.driver.AppleIISController 300.1
com.apple.driver.AppleAudioClockLibs 300.1
com.apple.driver.FairPlayIOKit 71.3.0
com.apple.driver.AppleARMPlatform 1.0.2
com.apple.iokit.IOSlowAdaptiveClockingFamily 1.0.0
com.apple.iokit.IOReportFamily 47
com.apple.security.quarantine 4
com.apple.security.sandbox 300.0
com.apple.iokit.IOStorageFamily 2.1
com.apple.kext.AppleMatch 1.0.0d1
com.apple.driver.AppleMobileFileIntegrity 1.0.5
com.apple.iokit.CoreAnalyticsFamily 1
com.apple.security.AppleImage4 5.0.0
com.apple.kext.CoreTrust 1
com.apple.iokit.IOCryptoAcceleratorFamily 1.0.1
com.apple.kec.pthread 1
com.apple.kec.Libm 1
com.apple.kec.Compression 1.0
com.apple.kec.corecrypto 14.0



** Stackshot Succeeded ** Bytes Traced 551010 (Uncompressed 1431904) **

Alles abstecken, from scratch anfangen und nach dem Ausschlussverfahren vorgehen, wie oben von tarbi erstmals erwaehnt.
Welcher persoenliche Angriff? Die Empfehlung, Dein MBP neu aufzusetzen, damit Du Fehler im System eingrenzen und eleminieren kannst? Diese Methode hat mir schon vielfach geholfen und ist weit hilfreicher als blind im Heuhaufen rumzustochern. Du hast doch ein Backup Deiner Daten. Insofern kannst Du doch nichts verlieren, wenn Du mit einem frischen System anfaengst.

Freien Speicher (damals nur 30-40 GB) und USB-Hub haben wir jedenfalls erst im Mai vergeblich diskutiert
Aber gut, dass Du jetzt ausreichend freien Speicher hast (auch wenn Du damals das Problem nicht anerkannt hast). Eine potenzielle Ursache weniger.
Über mangelnde Beiträge in Deinen wiederkehrenden Problemforen brauchst Du dich jedenfalls nicht beschweren, auch wenn diese Diskussionen hier und mit allen möglichen Support-Hotlines deine Mac-Probleme bislang nicht lösen konnten.

Und worauf basiert deine Annahme, dass ich das nicht gemacht habe oder mache?

OK, der Bericht zeigt an, dass ein Hardware- oder Software-Fehler in der Virtuellen Speicherverwaltung des Systems vorliegt. Der Systemkern hat einen Widerspruch in der Speicherabbildungstabelle für ein USB-Gerät (Device Access Resolution Table) gefunden.

Das könnte in der Tat ein Bug in macOS 14.0 sein oder ein Fehler in der USB-Hardware. Mit dem erwähnten Synology-Problem hat das aber garantiert nichts zu tun.

Auch mit RAID dürfte das nicht direkt etwas zu tun haben, außer dass hier in diesem speziellen Fall natürlich überproportional viel Hochgeschwindigkeits-USB-Kommunikation zum Einsatz kommt, was Fehler wahrscheinlicher aufdeckt.

Weil Du es nie erwaehnt hast, dass Du das schon getan hast.

Hast du noch im Kopf, wie häufig die Crashs auftreten? Zwischen keinmal in knapp einer Woche und mehrfach täglich. Kannst du dir da vorstellen, wie lange ein Negativ-Nachweis (kein Crash) dauern kann? Bei all den Kabeln und Geräten die angeschlossen sind, werde ich damit wohl ein paar Wochen beschäftigt sein.

Danke, Marcel! Das ist doch zumindest mal eine Aussage. Wie gesagt bin ich dabei die einzelnen Komponenten auszutauschen und zu prüfen, ob es noch zu Crashs kommt.
Wichtig ist mir vor allem, dass auch du nicht denkst, dass dieser Crash etwas mit dem Verschwinden von Daten auf meinem RAID zu tun hat (wovon ich auch selbst ausgegangen war – allerdings ohne echte Wissensgrundlage).
Damit haben wir also zwei Probleme: die Crashs und den Datenverlust.
Und ich schreibe es hier noch einmal, damit es allen klar ist: Ich habe sowohl den Support vo OWC (SoftRAID) als auch von Synology angeschrieben und um Rückmeldung zu der neuen Entwicklung gebeten.

Und noch etwas: Nicht jeder Crash fürt zu Datenverlusten auf dem RAID. Der letzte, dessen Protokoll oben steht, scheint diesmal alle Daten intakt gelassen zu haben – was es leider nur noch schwieriger macht.

Nicht lange, wenn man mit einem sauberen System anfaengt und von dort aus mittels Ausschlussverfahren vorgeht.
Siehe Marcel - Interpretation Crashreport - USB Hub

Aber doch braucht man mindestens eine Woche pro Komponente, um halbwegs sicher zu sein, dass sie die Ursache für die Crashs war. Und dieser Thread wurde gestern begonnen.

Also wenn man nur mal die richtige Zeile des Crash-Reports in der Suchmaschine deiner Wahl eingibt, dann landet man relativ schnell hier: (Mac Rumors Forum)
Längerer Thread und bereits vor macOS 14, aber der TE hat ja erwähnt, dass er das Problem schon länger hat.

Im Beitrag #16 sieht man dann was dort das Problem gelöst hat: USB-C-Hub und externen Monitor abgesteckt, keine Panics mehr. Im Laufe des Threads sieht man, dass es auch bei anderen mit Hubs anderer Hersteller passiert (Kingston, CalDigit, ...). Das Problem scheint dabei nicht nur das Hub zu sein, sondern auch andere USB-C Geräte verursachen das Problem (dort Apple USB-C - HDMI Connector). Am Ende lief es auf "No resolution so far, except do NOT use *ANY* USB-C adapter to connect an external display." hinaus. (Dann wäre es aber wohl dart-disp0 und nicht DARTBLK). SID0 bezieht sich auf eine Stream-ID

DART ist die "Device Address Resolution Table". Also jedem USB-Device wird eine Adresse zugeordnet. Diese ist dann zu dem Zeitpunkt, an dem der Kernel etwas an das Gerät schicken will (write protect exception) nicht mehr gültig. Das führt dann zu dem DVA (Device Virtual Address) Fehler.

Es sieht also für mich nach kurzer Recherche danach aus, dass der Kernel einen Stream auf ein USB-Device offen hat, vermutlich ein Block-Storage Device, also ein Speichermedium. Beim Versuch über den Stream auf das Gerät zu schreiben, ist dieser aber nicht mehr gültig und das führt zum Kernel Panic. Scheinbar kann das gleiche Problem sowohl mit Speichermedien wie auch mit Displays passieren. Meine Vermutung ist, dass das jeweilige USB-Gerät immer mal wieder "kurz verschwindet" und sofort wieder "erscheint". Das ist wie ganz schnell ab- und anstecken, während schreibend auf das Gerät zugegriffen wird. Dann dürfte das Gerät einen neuen Eintrag in die DART bekommen und eine neue Adresse im DVA, wo der Kernel dann einen neuen Stream erstellt. Ich vermute auch, dass es sich dabei dann um ein Timing-Problem handelt, also dass in einen noch offenen Stream geschrieben wird, obwohl längst ein anderer zu benutzen wäre.

Die Ursache dürfte sowohl in macOS liegen (schon seit mehreren Versionen) - der Kernel sollte nie versuchen auf ein "verschwundenes" Gerät zuzugreifen. Genauso ist aber die Frage berechtigt, warum das Gerät ab- und wieder angemeldet wird. Wäre letzteres stabil, würde das Problem nicht auftreten - und es scheint ja eher "zufällig" (zwischen mehrmals täglich und alle paar Tage) aufzutreten.
Ganz banal könnte es natürlich an Spannungsschwankungen oder Störungen im Stromnetz liegen, die von den Netzteilen bzw. der internen Stromversorgung im Gerät nicht mehr ausgeglichen werden können - kurzer Brown-Out in einem der Geräte während gerade Daten geschrieben werden (daher scheint das Problem bei Displays häufiger aufzutreten) und schon kommt der Kernel Panic. Es können aber auch beschädigte oder minderwertige Kabel schuld an dem Problem sein.

Der Prozess medianalysisd könnte es in dem Fall verursachen, weil macOS im Hintergrund versucht Medien-Dateien zu analysieren und ggf. für QuickLook Informationen bereitzustellen. Dabei wird von der Mediendatei nur gelesen, aber ggf. Extended Attributes und zB Preview-Daten geschrieben. Geht was beim schreiben der Extended Attributes schief, könnte das komplette Inventar des Ordners kaputt gehen und dann erscheint dieser Ordner nicht mehr.

Ich hatte zB schon mal an einem Dock per HDMI einen Monitor, Ethernet und ein paar USB-Geräte hängen, und plötzlich war das Dock mit allen Geräten weg (zum Glück ohne Panic). Mir wurde dann ein neues Netzteil zugeschickt, das leider das Problem nicht lösen konnte. Seit ich den Monitor per HDMI am MBP angeschlossen habe, trat das Problem nicht mehr auf.

Dass es beides Male RAID-Systeme waren, dürfte eher ein Zufall sein. So eine Synology (bzw. ein NAS im Allgemeinen) ist für den Mac erstmal nur ein Netzlaufwerk via SMB, AFP oder NFS. Dass es ein RAID ist kommt im macOS gar nicht an und ist für macOS auch irrelevant, es sieht halt einen Datei-Server. Bei dem OWC-System handelt es sich dann um ein DAS, in wie Weit macOS hier im RAID-Zusammenhang etwas tut oder eben die zugehörige RAID-Software, kann ich mangels Nutzung von solchen Lösungen nicht überblicken. Aber an einen generellen schwerwiegenden Bug von macOS im Zusammenhang mit RAID-Systemen mag ich nach deiner Problematik nicht glauben:
1.) Da du Ventura einschließt, wäre der Bug mutmaßlich schon ein knappes Jahr in macOS enthalten. Bei sovielen Mac-Usern, die tagtäglich mit Synology, QNAP und anderen RAID-Systemen arbeiten, hätte man davon viel viel mehr gehört und gelesen.
2.) Aufgrund der technischen Unterschiede zwischen NAS (=Netzlaufwerk) und DAS wäre es schon ein komischer Bug, der Netzlaufwerke und lokale RAIDs betrifft, aber keine Non-RAID-Netzwerklaufwerke.

Ich glaube daher bei deinen Problemen mit dem OWC und der Synology nur an Korrelation, aber eben nicht an einen kausalen Zusammenhang.


Du schriebst von einer Testversion von DxO Photolab. Test im Sinne von Beta-Version oder einfach eine zeitlich beschränkte Testversion einer finalen Version?

Wie erwähnt: Wenn es mit Netzlaufwerken wirklich Probleme durch einen macOS-Bug geben sollte, ist es hier wirklich eine extrem seltene ungewöhnliche Gesamtsituation, die diesen auslöst oder es wäre ein viel größeres Thema. Ich habe mit meinem z.B. QNAP-NAS keine Probleme. Von daher glaube ich an ein spezielles Problem in deinem Setup. Ein Bug in macOS mag eine Rolle spielen, halte ich aber für eher unwahrscheinlich. Mehr als 6 Abstürze am Tag sind ein deutliches Warnzeichen, dass auf deinem System etwas gehörig schief läuft. So oft ist mein Mac Studio imin den letzten 12 Monaten nicht abgestürzt und ich habe da schon manche Spielerei installiert. Ohne sagen zu können, wie dein Problem Daten auf deinem NAS vernichtet, liegt ein Zusammenhang nahe.

Im anderen Thread bin ich irgendwann ausgestiegen, aber da war doch auch irgendeine Synchronisationslösung im Einsatz. Das wäre natürlich eine potenzielle Fehlerquelle.

Ein USB-Problem ist auch denkbar. Ich habe hier z.B. einen USB-Speicherstick der hat tadellos funktioniert und von einem Moment auf den anderen bringt der mir jeden Mac nur durch Einstecken zum sofortigen Shutdown, selbst wenn ich das Ding über einen USB-Hub anschließe.

SSB

Riesigen Dank für deinen Beitrag, der das Problem mit den Crashes entscheidend voranbringt. Ich habe den Thread natürlich sofort gelesen. Am Ende steht, dass, wie es meine Erfahrung ist, auch Ventura betroffen ist. Ich selbst habe nun noch Sonoma 14.0 ebenfalls hinzugefügt.
Ich benutze (leider?) einen LG Ultrafine 5K, der sich ausschließlich über Thunderbolt betreiben lässt. Daher habe ich leider keine Möglichkeit das Display anders anzuschließen. Mit dem bereits bestellten neuen USB-Hub werde ich auf die Nutzung des Hubs im Monitor verzichten können (was das Problem vielleicht seltener machen, aber nicht lösen können wird).
Heißt das also, ich muss mit gelegentlichen, hoffentlich selteneren Crashs leben, bis Apple endlich den Bug behebt? Ich hatte ohnehin darüber nachgedacht, mir einen Mac mini zu holen, um mein MBP mobil als Ersatz für mein (ebenfalls viel diskutiertes und als professionelles Gerät nicht zuverlässig nutzbares) iPad pro zu ersetzen. In dem Thread steht jedoch, dass auch Mac mini betroffen sind. Was also tun?

Lies mal den Beitrag von SSB direkt über deinem Posting. Da werden die "DART-USB"-Crashs diskutiert und festgestellt, dass diese nun bereits in der dritten macOS-Version auftreten und aller Wahrscheinlichkeit nach auf einen macOS-Fehler zurückgehen. Dass die allermeisten Nutzer noch nie ein vergleichbares Problem mit RAID-Systemen hatten, ist mir sehr bewusst. Ich habe diese rätselhaften Datenverluste nun schon in zwei völlig verschiedenen RAID-Systemen erlebt. Deshalb denke ich, dass macOS irgendwie daran beteiligt ist.
Auffällig ist vor allem, dass längst geschriebene Daten anscheinend rückwirkend gelöscht/entfernt werden – und das vermutlich ledilich aus den Inhaltsverzeichnissen der RAIDs. Seit der Umstellung auf APFS muss ich gestehen, dass ich nicht mehr wirklich verstehe, wie dieses Filesystem arbeitet. Viele Dinge scheinen nicht aktuell, sondern zeitversetzt zu passieren (u.a. die Freigabe von Speicherplatz). Und da ich bei meinen Datenverlusten einen entsprechenden Zeitversatz wahrnehme, habe ich die Vermutung, dass hier macOS beteiligt ist. Sei es, dass es einen internen Katalog darüber führt, was auf den RAIDs gespeichert und also angezeigt wird, sei es, dass es die Realität auf dem RAID nach einem Neustart mit seiner internen Wirklichkeit in Übereinstimmung zwingt.
Ich fürchte allerdings, dass hierzu nur ein intimer Kenner der Arbeitsweise von macOS/APFS Auskunft geben kann. Weshalb ich, sobald ich die Zeit habe, beim Apple Kundendienst anrufen werde, damt das Problem nach Cupertino an die zuständigen Ingenieure weitergereicht werden kann.

ssb:
Ich betreibe meinen LG Ultrafine 5K-Monitor übrigens an meiner unterbrechungsfreien Stomversorgung, was Netzschwankungen eigentlich ausschließen sollte, oder?

Es steht dazu aber natürlich im Raum, ob APFS für diesen Anwendungszweck wirklich eine kluge Lösung ist. Aber da du das Problem schon mit einer Synology NAS hattest, dürfte es das nicht allein sein.

Vielleicht könnte es schon helfen, mediaanalysisd zu deaktivieren, aber das geht nur ohne SIP und ist daher mit Vorsicht zu geniessen: (Apple Insider)
Wenn dort sehr viele Mediendaten liegen, dann könnte die Analyse (geht wohl auch im Face-Recognition etc.) teilweise sogar die CPU lahmlegen. Das erzeugt also richtig viel Last gerade bei externen Volumes und einerseits erhöht das die Wahrscheinlichkeit, dass der Kernel Panic auftritt, weil ja viel mehr auf das Volume zugegriffen wird und andererseits könnten Schwächen in den Kabeln oder der Stromversorgung der USB-Geräte wesentlich häufiger auftreten.

Am Ende ist es sicher auch für Apple hilfreich, wenn du denen die gesammelten Crash-Reports mit Beschreibung über den BugReporter zukommen lässt. Also mit deiner Apple-ID einen Case auf (Apple Feedbackassistant) öffnen. Der wird vermutlich relativ bald als "Duplicate" geschlossen, aber je öfter die es bekommen, desto höher die Chance, dass sie sich das anschauen. Aber "intermittend cases" sind grundsätzlich schwer einzugrenzen.

Nun: Ich würde raten, den USB-Hub im Monitor nicht zu nutzen als Minimalvorsichtsmaßnahme.
Und ein Mac Mini und ein mac Studio haben auch einen HDMI-Port - Dein Monitor aber leider keinen, sonst könntest Du so einen Rechner oder Dein MBP per externem USB-C-Hub mit HDMI-Ausgang nutzen.
Ich betreibe einen 42,5" 4K-Monitor von Dell (zunächst an einem MBA, und jetzt) an einem Mac Mini M2.
Anfangs hatte ich den Monitor via Thunderbolt betrieben und auch den integrierten USB-Hub genutzt.
Allerdings hatte ich immer mal Unannehmlichkeiten diverser Art (darunter erratisches Verhalten beim Ruhezustand), deren Genese mir nicht klar war, sodass ich schließlich auf HDMI umgestiegen bin, was mein Monitor zusätzlich bietet.
Seitdem und trotz Nutzung eines Synology NAS keine Probleme mehr.
Aber das dürfte ja für Dich nicht so einfach umzusetzen sein.

PS.: Ein NAS nutz kein APFS, sondern ein NAS-typisches Format. Damit kann es also kaum was zu tun haben.

Aber: Mindestens auf der Synology hat das alles nichts mit APFS zu tun. Ein NAS ist ein Server, also ein eigener Computer, mit eigenem Betriebssystem, der die Laufwerke erstmal selbst unabhängig vom Mac verwaltet. Dabei kommt auch kein APFS zum Einsatz. Dein Mac weiß gar nicht, dass da mehrere Festplatten werkeln. Wenn es ein Bug in macOS ist und der gleiche Fehler für beide Datenverluste zuständig ist, dann kann sich dieser nicht nur auf RAID-Laufwerke beschränken. Wie gesagt für den Mac ist das NAS kein RAID, es ist ein Netzlaufwerk auf einem Server.

Da dein Mac natürlich Schreib- und Leserechte hat, kann der dort auch theoretisch Daten löschen, aber das ginge genauso in einem NAS mit nur einer Festplatte. Also entweder ist es schlicht Zufall, dass deine normalen Festplatten und Sticks bisher nicht betroffen waren und der Bug löscht wild auf allen verfügbaren Verzeichnissen oder es liegt an speziellen Dingen/Softwares, die nur auf Verzeichnisse auf der Synology und dem OWC-Ding zugreifen, aber nicht auf die normalen Platten. Da du ja schreibst dass, dass auch ältere Daten betroffen sind, wären hier ja gerade Apps prädestiniert, die irgendwie eigenständig Daten abgleichen. Das war ja auch schon im ersten Thread ein Verdacht. Das es einen macOS-Bug gibt, der wild Daten löscht, ist nicht auszuschließen, aber extrem unwahrscheinlich (das wäre durch die Macmedien schon hoch und runter gemeldet worden) oder kommt eben nur bei einigen merkwürdigen Konstellationen vor. Also irgendwas wird an deiner Konfiguration sein, dass dafür verantwortlich ist.

Den Beitrag von ssb und den verlinkten Thread habe ich eben gelesen, war noch nicht da als ich angefangen habe zu tippen. Das würde die Abstürze erklären. Aber eben noch nicht den Datenverlust auf einem Netzlaufwerk der Synology.

Wie genau werden die Daten denn auf dein NAS bzw. das OWC-Ding geschrieben? Durch deine Fotosoftware? Wurde diese zwischen Import der RAW-Daten und dem Absturz geschlossen oder lief diese durchgehend? Ohne DxO zu kennen, habe ich hier einen Verdacht, kann es sein, dass DxO die Daten erst in einem Cache-Verzeichnis (ggf. auf dem Startlaufwerk) zwischenspeichert und erst später ggf. beim Schließen endgültig schreibt. Bzw. mindestens seine eigenes Datenbank erst beim Schließen schreibt? Wenn ja hast du vorher direkt mit dem Finder oder Teminal mal geprüft, ob die Daten wirklich physisch auf dem RAID gelandet sind. DxO ist ja auch eine Foto-Datenbank: Ich halte es für denkbar, dass DxO ggf. beim öffnen seine eigenen Verzeichnisse aufräumt und alles entsorgt, was nicht in der eigenen Datenbank auftaucht. Bzw. die Bilder erst beim Schließen wirklich in seine eigenen Verzeichnisse überführt. Aber wie gesagt: Ich benutze DxO Photolab nicht und habe es auch noch nie genutzt. Aber es wäre folgender Ablauf denkbar: Du startest eine Sitzung, importierst Bilder, bearbeitest sie und exportierst sie und so weiter. Nun speicher DxO ggf. nicht unmittelbar jede Änderung in der eigenen Datenbank, hat diese aber auf jeden Fall geöffnet, weil DxO noch läuft. Nun könnte durch den Crash die Datenbank nicht sauber gespeichert sein und DxO greift dadurch auf eine ältere Version zu, in der die in der letzten Session importierten Bilder noch fehlen. Ob DxO in einem solchen Fall aufräumt, ist erstmal eine Mutmaßung, wäre aber denkbar.

Oder einfach, weil Fotos einfach die eigene Datenbank anders verwaltet. Wie gesagt, da ich DxO nicht nutze, ist da ganz viel Mutmaßung bei. Aber vielleicht liegt das Problem wirklich woanders als in RAIDs oder macOS. Oder sind dir auch andere Daten abhanden gekommen?

Eine mögliche Erklärung habe ich oben konstruiert. Aber da wäre halt die Frage, ob du DxO z.B. nach jeder Nutzung unmittelbar schließt oder eben der Absturz während der laufenden Session erfolgte.

USV ist prinzipiell immer gut, wie und welche Schwankungen abgefangen werden können hängt vom jeweiligen Modell und der eingesetzten Technik ab. Hoffe das MBP M1 ist auch mit der USV verbunden. Hast du mal geprüft ob bei dir die Netzspannung stabil ist? Kann man mit der USV sehr gut überwachen/protokollieren.

Hat das MBP M1 eine Touchbar?

Das ist richtig, betrifft allerdings nur die Synology. Die OWC Mercury ist ein RAID-Gehäuse ohne NAS-Funktionen und beherrscht APFS.

Solche Überprüfungsfunktionen bietet meine ältere USV nicht. Das MBP ist das 14" Standard-Model mit M1pro-Prozessor, hat also keine Touchbar.