Microsoft und der ungefixte ReFS-Bug in Windows, sieht schlecht aus

Windows[English]Am 8. Februar 2022 ist ja wieder Patchday bei Microsoft. Wer aber nach dem Desaster mit dem Januar 2022-Patchday hofft, dass bestimmte Sachen mit den Sicherheitsupdates vom 8. Februar gefixt werden, könnte enttäuscht werden. Zumindest gilt das wohl für die ReFS-Problematik, die in bestimmten Szenarien die entsprechenden Datenträger als RAW zurücklässt. Inzwischen liegt mir eine technische Erklärung vor, warum die Sonderupdates in einigen Szenarien keine Besserung bringen. Ob Microsoft das jemals fixt, steht in den Sternen.


Anzeige

Worum geht es beim ReFS-Problem?

Wurden die Sicherheitsupdates vom 11. Januar 2022 installiert, gab es das Problem, dass mit ReFS formatierte Datenträger nur noch als RAW angezeigt werden. Ich hatte das im Blog-Beitrag Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen? angesprochen. Dort bezog sich das Ganze aber auf die Installation der Updates KB5009624 (Monthly Rollup for Windows 8.1 and Windows Server 2012 R2) und Update KB5009595 (Security Only Quality Update for Windows 8.1 and Windows Server 2012 R2). Benutzern fehlt plötzlich der Support für das ReFS-Dateisystem.

Microsoft hatte dann zum 17. und 18. Januar 2022 Sonderupdates veröffentlicht, die die fehlende ReFS-Unterstützung für die jeweilige Windows-Version zurückbringen sollen. In den betreffenden Support-Beiträgen heißt es dazu:

Behebt ein Problem, durch das verhindert werden kann, dass Wechselmedien, die mit dem robusten Dateisystem (ReFS) formatiert sind, behoben werden können oder die Bereitstellung der Wechselmedien im RAW-Dateiformat verursachen. Dieses Problem tritt nach der Installation des Updates vom 11. Januar 2022 Windows auf.

Ich habe nachfolgend mal eine Liste aller Sonderupdates herausgezogen, die vorgeben, dass ReFS-Problem zu beheben.

In Kommentaren wie hier wird bestätigt, dass sich die ReFS-Laufwerke wieder mounten lassen. Allerdings gibt es Ungereimtheiten, denn Nutzer berichten, dass die ReFS-Unterstützung für bestimmte Szenarien weiterhin fehlt. Ich hatte im Blog-Beitrag Sonderupdate für Windows (17./18. Jan. 2022) fixen ReFS-Probleme nur teilweise darüber berichtet.

ReFS 1.0-Problem ist nicht gefixt

Gab es bisher noch Hoffnung, dass die oben angerissenen Probleme mit ReFS nach dem Januar 2022-Patchday nur vorübergehend seien, hat sich diese Hoffnung in meinen Augen jetzt aufgelöst. Mike hat sich bereits im Januar 2022 mit diesem Kommentar gemeldet und auf die Techcommunity-Diskussion ReFS volume appears RAW (version doesn't match expected value) after Windows Update verwiesen. Dort dreht es sich ebenfalls darum, dass die Sicherheitsupdates vom Januar 2022 die Unterstützung für das ReFS-Dateisystem beschädigen. In der Diskussion hat sich der britisch Microsoft-Mitarbeiter Stephen Cole (stephc_msft) gemeldet und schreibt in seinem Kommentar:

The main issue is there are various versions of REFS:

ReFS v1 as used on Server 2012R2 and ReFS v3 used on later OS's

The Updated fix, for Refs on removable drives, only addresses the ReFS v3 case and does not (and never will) address the refsv1 case.
Note that some disks, even on later OS's might be using ReFS v1 if they were originally set up on earlier systems

And so the fix will not help on those disks on those systems

Since its mainly VMWare VM's that are affected, as they consider hotplug disks as removable, suggest using the vmware devices.hotplug solution described earlier

You can check the Refs version with

fsutil fsinfo refsinfo x:

(although cant do this if the drive is currently showing as RAW)

In aller Kürze: Es gibt ReFS v1 auf Windows Server 2012 R2 und ReFS v3 in späteren Windows-Versionen. Die oben erwähnten Sonderupdates adressieren nur ReFS v3 für Wechseldatenträgern. Wer ReFS v1 auf Laufwerken verwendet, hat nach dem Sicherheitsupdate vom Januar 2022 schlechte Karten. Betroffene VMware-Nutzer können das hotpluging deaktivieren (siehe Status der Januar 2022-Sicherheitsupdates von Microsoft (25.1.2022)).

In der Techcommunity-Diskussion ReFS volume appears RAW (version doesn't match expected value) after Windows Update bestätigen Betroffene dann auch, dass Volumes mit ReFS v1.2 als RAW angezeigt würden, während Volumen mit ReFS v3.4 wohl wieder funktionieren. Bedeutet, dass unter Windows Server 2012 R2 virtualisierte Systeme keinen wirklichen ReFS-Support mehr bekommen.

Wer ReFS v1-Datenträger unter Windows Server 2016 oder höher verwendet, kann das Problem nur umgehen, indem neue Festplatten mit diesem Dateisystem erstellt oder die alten ReFS-Datenträger neu formatiert werden. Für Nutzer, die mit Windows Server 2012 R2 arbeiten wird es schwierig, da dort ReFS v3 nicht unterstützt wird. Wer dort mit VMware virtualisiert, muss die oben erwähnte Lösung wählen und hotplug abschalten.


Anzeige

Ergänzung: Blog-Leser Karl hat mich noch auf diese GitHub-Dokumentation hingewiesen, die die einzelnen ReFS-Versionen dokumentiert.

Ergänzung 2: Im englischsprachigen Blog gibt es diesen Kommentar, der darauf hinweist, dass ReFS-Datenträger automatisch auf ein neueres Format aktualisiert werden, wenn der Administrator sie unter einer höheren Windows Server-Version mounted. Quelle ist die Technetcommunity-Diskussion ReFS volume auto updated aus 2018. Wer also unter Windows Server 2016 einen ReFS v1-Datenträger mountet, bekommt ein ReFS v3-System. Dann lässt sich dieses Volume nicht mehr unter Windows Server 2012 R2 nutzen. Allerdings meine ich, dass es keinen Automatismus gibt, sondern die ReFS-Volumes explizit formatiert werden müssen, um auf v3 zu kommen.

Ähnliche Artikel:
Patchday: Windows 8.1/Server 2012 R2-Updates (11. Januar 2022), mögliche Boot-Probleme
Patchday: Windows 10-Updates (11. Januar 2022)
Patchday: Windows 11-Updates (11.Januar 2022)
Patchday: Updates für Windows 7/Server 2008 R2 (11. Januar 2022)

Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife
Windows VPN-Verbindungen (L2TP over IPSEC) nach Januar 2022-Update kaputt
Windows Server 2012/R2: Januar 2022 Update KB5009586 brickt Hyper-V Host
Microsoft Januar 2022 Patchday-Revisionen (14.1.2022)
Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?

Sonderupdates für Windows mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 11/Server 2022 Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 10/Server: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 7/8.1; Server 2008R2/2012R2: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Sonderupdate für Windows Server 2019 fixt Jan. 2022-Patchday-Probleme (18.1.2022)

Nachlese: Fix für Windows IPSec VPN-Verbindungproblem
Sonderupdate für Windows (17./18. Jan. 2022) fixen ReFS-Probleme nur teilweise


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Antworten zu Microsoft und der ungefixte ReFS-Bug in Windows, sieht schlecht aus

  1. Rainer Winkler sagt:

    Wer benutzt den auch schon ReFS das ist ja das Windows 8 unter den Dateisystemen. NTFS macht seit Windows 2000 kein Probleme mehr.

    • Günter Born sagt:

      Ich schaue nur auf die Kommentarlage hier in den Blogs – da hat es einige Admins getroffen. Einen Grund wird es wohl geben, dass die ReFS verwenden.

      • L4mon sagt:

        ReFS als Veeam Backup Repository für Forever Forward Incremental Ketten (Merge Operation) oder Synthetic Fulls bietet durch Block Cloning deutliche Vorteile gegenüber NTFS.

    • Olli sagt:

      Veeam z.B. wünscht sich ReFS wenn man direkt auf Platte sichert und nicht etwa auf Tape oder eine spezielles Gerät wie eine DataDomain. Es sichert dann aber auch auf NTFS und andere…

    • Singlethreaded sagt:

      Wird ein ReFS Volume als Veeam Backup Repository verwendet, so kann man damit unter bestimmten Umständen eine ganze Menge Speicherplatz sparen. Sichert man z.B. 20 Windows Server 2016 in einem Job, so werden gleiche Blöcke nur einmal gespeichert. Da es unter den Windows Server 2016 Maschinen viele gleiche Dateien im Bereich des OS gibt kann dies im Vergleich zu vollständigen separaten Sicherungen schnell viele GB oder TB ausmachen. Hier gibt es eine recht gute Erklärung des Ganzen:

      https://blog.paessler.com/use-windows-refs-with-veeam-and-prtg-for-backups

      Gruß Singlethreaded

    • Armin Wagner sagt:

      Auf die Frage: "Wer benutzt den auch schon ReFS…"
      Zum Beispiel diejenigen, die sich an die Empfehlung von Microsoft halten, die Partition für Exchange Server Mailbox Datenbanken mit ReFS zu formatieren…

  2. 1ST1 sagt:

    Wer noch Server 2012 (R2) einsetzt, muss sich bis 2023 eh Gedanken machen, denn da läuft der Support aus. Daher, neuen Server (2016, 2919, 2022) hinstellen, mit ReFs v3 formatieren und Daten rübermigrieren.

  3. HermannK sagt:

    Ich bin zwar nicht betroffen, aber … Hey, da hast du ein einwandfrei funktionierendes System, installierst fleißig und Muster-Adminmäßig Updates und dann funktioniert der Zugriff auf deine Daten von einem Moment auf den anderen nicht mehr.
    Eindeutig ein Update schuld und dann heißt es, dass bleibt so. Obwohl das Produkt vom Hersteller noch im Support ist. Traurig, Lächerlich, … 🤮🤮🤮

  4. oli sagt:

    https://gist.github.com/0xbadfca11/da0598e47dd643d933dc

    Haben Win Server 2019 und damit ne externe HDD mit ReFS fromatiert. ReFS-Version zeigt 3.4 und ist auch ganz normal mountable nachdem beide Januar-Updates installiert sind.

  5. Boris Adler sagt:

    Der neue KB5010419 von Microsoft sorgt erneut für das Problem, ein ReFS v1 Datenträger ist nach der Patch Installation erneut ein RAW Datenträger. Und somit nicht mehr zu erreichen… Ein Schelm wer böses denkt, nach Deinstallation des Patches ist das Laufwerk wieder da. Ein Schelm wer böses denkt, aber offensichtlich jagt Microsoft die Kunden sehenden Auges in solche Situationen. Das sollte sich ein Fahrzeug Hersteller mal erlauben…

  6. Denis sagt:

    Hallo zuammen,
    wie sieht es denn bei ReFS v3.1 aus? Wird das nach dem aktuellen Update noch erkannt oder erst ab der v3.4?
    VG Denis

  7. Volker sagt:

    Wir stellen gerade einen Failover Cluster, der bisher als shared storage SMB3 genutzt hat, auf Fibre Channel um, dabei haben wir auf Wunsch unseres Storage-Admins und nach Lektüre der MS-Doku ein LUN unter Server 2016 mit ReFS formatiert und als Cluster Shared Volume eingebunden. Dann wollten wir ein Rolling Upgrade des Clusters auf Server 2019 durchführen, und ZACK, sobald der Knoten mit Server 2019 das CSV einmal im Schreibzugriff hatte, hat er die Version auf 3.4 erhöht und die restlichen Knoten, die noch unter 2016 laufen, konnten das Volume nicht mehr lesen, wodurch plötzlich der 2019er Host lebenswichtig für den Cluster wurde und der Weg zurück zu 2016, der ja im Rolling Upgrade eigentlich bis zum finalen Anheben des Clusterlevels immer möglich sein sollte, auch versperrt war. Danke, Microsoft, unsere Lektion : Benutze NIE ReFS. In der Doku wird ReFS auch überhaupt nur bei S2D erwähnt.Damit ist ein Rolling Upgrade mit auf ReFS formatiertem shared storage anscheindend gar nicht möglich, zumindest verliert man zwischendurch die Ausfallsicherheit.

Schreibe einen Kommentar zu HermannK Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.