Dell PowerVault MD 34/38 Series Storage Controller Firmware and NVSRAM firmware version 08.25.14.60

Fixes:
Host-E/A führte bei fehlender Laufwerkswiederherstellung für ein Volume mit ungeschriebenen Daten im Cache zu Fehlern und Dateninkonsistenzen in Data Assurance.
Eine RLS-Anforderung vom Switch führte bei 16-GBit-Fibre-Channel gelegentlich zum Neustart des Controllers oder sehr selten auch zu Dateninkonsistenzen.
Auf Arrays mit hoher Dichte mit einem Neukonfigurationsvorgang (z. B. dynamische Volume-Erweiterung, RAID-Migration) und einer synchronen Spiegelung kam es unerwartet zum Neustart des Controllers.
Beim Austauschen aller Laufwerke in einem Pool mit Laufwerken größerer Kapazität kam es zum Datenverlust.
Auf Arrays mit hoher Dichte mit Rückschreib-Cache und aktivierter Cache-Spiegelung kam es bei hohen Schreib-Rechenlasten zu Host-E/A-Timeouts und -Abbrüchen.
Eine ausgefallene Hardware-Komponente führte zu Fehlern bei Erkennung des Laufwerks und zu überlappenden Zurücksetzungen des Ziels und somit zum Laufwerksausfall.
Wenn ein Controller während eines Laufwerksausfalls neu gestartet wurde, kam es gelegentlich zu Problemen mit der Datenintegrität.
Eine Änderung der Host-Portkonfiguration bei der Volume-Erkennung auf einem Host führte dazu, dass ein Controller neugestartet wurde.
Bei aktiviertem Cache ohne Akkus führte ein "sync cache"-Befehl vom Host möglicherweise zu einem Neustart des Controllers.
Bei der Migration der Controller-Firmware zwischen bestimmten Versionen kam es unter Umständen zu einem unerwarteten Neustart des Controllers.
Bei über 200 Hosts in einem Cluster führte das Zurücksetzen eines Geräts von einem Host zu einem unerwarteten Neustart des Controllers.
Bei asynchroner Spiegelung führten Rechenlasten, die den Schreibcache füllen, möglicherweise zu unerwarteten Controller-Neustarts.
Auf Arrays mit hoher Dichte mit mehr als einem Thin Provisioning-Volume kam es in seltenen Fällen (die Wahrscheinlichkeit nahm bei einer höheren Anzahl von Thin Volumes zu) dazu, dass Schreibvorgänge in zuvor ungeschriebene Bereiche von Thin Volumes zu Datenintegritätsproblemen oder Controller-Neustarts führten.
Bei iSCSI führte ein selten auftretendes Timing-Problem möglicherweise dazu, dass ein Controller versuchte, eine Sitzung zwei Mal zu beenden, was zu einem Neustart des Controllers führte.
Bei einem Nicht-Pool-Volume mit einem integrierten Hot-Spare-Datenträger führte ein unzuverlässiges Laufwerk, das ein kritisches 0x224D-Ereignis generierte, zu kontinuierlichen Neustarts oder Controller-Sperre.
Wenn ein Laufwerk aufgrund eines drohenden Ausfalls des Controllers ausgefallen ist, konnte der Ausfall des Laufwerks nicht abgebrochen werden.
Wenn bei Pools ein Laufwerk vor oder während des Ein- und Ausschaltens des Systems entfernt wurde, kam es möglicherweise zur Controller-Sperre oder zu potenziellem Datenverlust.
Der SMcli-Befehl zur Prüfung der Parität wurde möglicherweise angehalten, wenn eine nicht übereinstimmende Datenparität festgestellt wurde.
Unerwarteter Fehler bei ausschließlicher Konfiguration der IPv4-Adresse, wenn IPv6 aktiviert war.
Unerwarteter Neustart des Controllers/Core Dump auf Arrays mit hoher Dichte, wenn ein Pool oder Pool-Volume einer Neukonfiguration unterzogen wurde.
Auf Arrays mit hoher Dichte führte eine asynchrone Spiegelung oder ein Snapshot mit mehreren Repository-Volumes möglicherweise zu unerwarteten Neustarts des Controllers.
Bei aktivierter VMware VAAI und synchroner Spiegelung auf Arrays mit hoher Dichte kam es möglicherweise zu unerwarteten Neustarts des Controllers.
Für das Volume wurde aufgrund eines seltenen Fehlers bei der Verarbeitung von STPG von FlexArray (oder einem anderen TPGS/ALUA Treiber mit explizitem Modus) kein Failback auf den bevorzugten Controller nach SAN-Wiederherstellung nach einem Fehler ausgeführt.

Verbesserungen:
–