Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsWindows 11 erhält ReFS: Microsoft bereitet Update auf das robuste Dateisystem vor
Ich schrieb verkleinern geht nicht. Vergrößern schon.
Ergänzung ()
Edit, @cloudman, da werden dir einige heftig widersprechen, genug Stoff wirst du im Netz dazu haben. Und sorry, die Begründungen in deinem genannten Thread ... hm.
Aber es gibt halt des öfteren die Situation das man die Partition auch verkleinern muss.... Also, eigentlich schon mir unverständlich warum das im Jahr 2022 nicht mehr geht.
Benutze ReFS schon länger auf einem 2022er File- u. VM-Server in einem Windows Software RAID-5 SSD Verbund. Bisher rock solid und rasend schnell.
Ich glaube, viele werfen immer erstmal alles mögliche an zum Teil veralteteten Vorurteilen und Informationen in die Runde, ohne einfach mal selbst zu testen bzw. sich klar zu machen, zu welchem Zweck bestimmte Dinge eingeführt wurden. Und ohne Fehl und Tadel sind BTRFS und ZFS auch nicht. Gerade letzteres muss auch gut und mit viel Erfahrung konfiguriert werden, damit man sich keine Ruine zusammen baut.
ReFS (und Speicherplätze/Speicherpools) ist aber nicht wirklich neu. Das gibt es schon seit Windows 8.1 - da war es noch für alle Versionen vollständig freigeschaltet. Ab Windows 10 war das Erstellen von neuen Volumes/Speicherpools mit ReFS nur ab Enterprise möglich, vorhandene Speicherpools mit ReFS können allerdings problemlos und ohne irgendwelche Beschränkungen auch mit Windows 10 Pro weiterverwendet werden. Über "Home" kann ich nichts sagen, ich verwende nur "Pro". Ich benutze ReFS in Speicherpools von Anfang an und habe auch unter Windows 10 schon mehrmals Festplatten erneuert.
Einen Vorteil von ReFS gegenüber NTFS hat man gegenwärtig aber nur, wenn man es in einem Speicherpool mit Zwei-Wege-Spiegelung (oder besser) betreibt. Das "Re" im Namen steht für "Resilient" und soll Ausfallsicherheit garantieren. Wenn eine der parallel betriebenen Festplatten ausfällt, dann kann man noch immer die Daten von dem/den anderen hoffentlich noch funktionsfähigen Datenträger(n) lesen. Festplatten tauschen geht recht einfach: man klemmt die neue(n) Platte(n) an, die auszutauschende (falls nicht komplett defekt) läßt man noch betriebsbereit und markiert dann in der Konfigurationsoberfläche, daß man sie austauschen möchte. Das Kopieren auf den/die neuen Datenträger dauert dann zwar recht lange - ist allerdings unterbrechbar; d.h. man kann den PC ausschalten und wenn man ihn wieder einschaltet, dann wird einfach ab der Unterbrechung weitergemacht.
Das funktioniert wirklich gut. Ich habe einen kleinen Server mit Festplatten 2* 4TB und 2* 5TB. Zuvor hatte ich anstatt der 2* 5TB Platten kleinere Modelle und kaum noch freien Speicher. Als ich die neuen 5TB Platten eingebaut und das Kopieren von "alt" nach "neu" gestartet hatte, fiel mir zwar ein kleines gelbes Dreieck im Dialog auf, aber das hatte ich falsch interpretiert (ich dachte das wäre noch immer die Anzeige dafür, daß der Speicher knapp geworden ist). In Wirklichkeit war aber ein SATA-Kabel einer der Festplatten defekt, die ich ersetzen wollte. Windows hat jedoch schon mit der Kopiererei begonnen und als ich den wirklichen Fehler entdeckte, habe ich den PC heruntergefahren, das Kabel getauscht und dann wieder eingeschaltet. Das Kopieren wurde fortgesetzt und im Anschluß hatte ich trotz allem wieder einen voll funktionsfähigen Speicherpool.
Aber wie gesagt: Das "Re" bringt nur bei gepiegelten Datenträgern einen Vorteil. Beim Schreiben war NTFS bis jetzt immer schneller, als ReFS - vielleicht hat Microsoft ja dort noch etwas geändert.
Warum es in Windows 11 erstmal nicht mehr enthalten sein sollte, obwohl es schon jahrelang verfügbar und für ausfallsichere Server gedacht ist, erschließt sich mir nicht.
@SnoopyDog : Das was du da beschreibst, kann ein normales RAID 1 leisten, oder verstehe ich dich falsch? Und ist nicht der einzige Vorteil von ReFS, im Gegenteil. Stichwort File Integrity Streams.
Sorry, aber das sehe ich anders. Kannst du belegen, dass das der zentrale Punkt gewesen sein soll, wofür es entwickelt wurde?
Das Re steht für Resilient. Und die Resilienz bedeutet nicht nur, dass ich zwei Platten habe, eine geht kaputt und alles ist gut. Denn das wäre ... völlig obsolet, da bereits seit Dekaden vorhanden.
Es geht halt darum, dass im Dateisystem noch zusätzlich entsprechende Prüfsummen hinterlegt sind (bzw. sein können, kann man auch abschalten bei ReFS). Und diese werden z.B. auch beim Lesen verglichen. Ich weiß nicht, welche Software-RAIDs auch standardmäßig prüfen, ob die gelesenen Daten überhaupt Sinn ergeben. Nehmen wir einfdach mal RAID1, nehmen wir an, eine HDD fällt aus. Kann der Controller noch feststellen, ob die Daten auf der noch funktionierenden HDD korrekt sind?
ReFS tut das eben. Und im Falle eines Prüfsummenfehlers kann im Falle von Paritätsdatenträgern eben der Versuch unternommen werden, die beschädigte Datei zu rekonstruieren.
ReFS in Kombination mit Storage Pools sollte man am ehesten wohl mit ZFS vergleichen.
Das ist natürlich richtig.
Die Aussage, ReFs würde nur bei "[...] gepiegelten Datenträgern einen Vorteil [...]" bringen ist eben nicht richtig. Wenn ich einen Exchange oder Dateiserver auf ReFS laufen lasse, tue ich das in aller Regel als VM, das heißt, meine VMDK/VHDX oder was auch immer ist selbst alleine. Dennoch habe ich mit ReFS die Integrity Streams (beim File, beim Exchange sind diese zwingend auszuschalten).
AFAIK gibt es bei Storage Pools/Storage Spaces eh kein "klassisches Spiegeln", sondern eben Paritätsdatenträger - wenn man 2 Columns hat und eine Column ist Partität, dann ist es halt defacto ein Spiegeln, ja.
Also die Erkennung funktioniert auch ohne Spiegeln, das paritätsunterstützte Reparieren halt logischerweise nicht.
Nein, Spiegelungen sind unabhängig von Parität. Das merkt man schnell, wenn man mal Parität mit schlechten Blockgrößen einsetzt und die Performance mit Mirror vergleicht
Man kann einstellen, wie auf wie viele Platten man verteilen will (Columns), wie viele Kopien vorhanden sein sollen oder wie viele Parity Datenträger.
Auch wenn man nicht mehr die klassischen Raid Modi auswählt kann man die trotzdem nachbauen.
Also 1 Kopie und 2 Columns = Raid0 auf 2 Platten
2 Kopien und 1 Column = Raid1
2 Kopien und 2 Columns = Raid10
x Columns und 1 Parity = Raid5
x Columns und 2 Parity = Raid6
...
Es geht halt darum, dass im Dateisystem noch zusätzlich entsprechende Prüfsummen hinterlegt sind (bzw. sein können, kann man auch abschalten bei ReFS). Und diese werden z.B. auch beim Lesen verglichen. Ich weiß nicht, welche Software-RAIDs auch standardmäßig prüfen, ob die gelesenen Daten überhaupt Sinn ergeben. Nehmen wir einfdach mal RAID1, nehmen wir an, eine HDD fällt aus. Kann der Controller noch feststellen, ob die Daten auf der noch funktionierenden HDD korrekt sind?
Dateisystem-Checksummen und die damit mögliche Selbstreparatur sind ein Kernaspekt von ZFS. Beim Scrub (also dem „Schrubben“ des Dateisystems) wird alles einmal ausgelesen und mit den gespeicherten Prüfsummen verglichen. Wird eine Diskrepanz festgestellt, dann weiß ZFS, welche Platte fehlerhaft ist und kann die Daten dank Redundanz wiederherstellen. Checksummen werden zwar auch in nicht-redundanten Pools verwendet, aber dort haben sie freilich nur eine informierende Funktion und bieten keine Wiederherstellung.
ZFS bietet generelle, blockbasierte Integritätssicherung über das gesamte Laufwerk. ReFS integrity streams sind dagegen wohl eher Dateibasiert und für viele Fälle ungeeignet, weshalb sie wohl auch nicht per Default und schon gar nicht generell über das gesamte Laufwerk aktiviert sind. Ein gewaltiger Unterschied.
arktom schrieb:
... Wenn ich einen Exchange oder Dateiserver auf ReFS laufen lasse, tue ich das in aller Regel als VM, das heißt, meine VMDK/VHDX oder was auch immer ist selbst alleine. Dennoch habe ich mit ReFS die Integrity Streams (beim File, beim Exchange sind diese zwingend auszuschalten).
Ehm, wirklich ReFS innerhalb der VM? Ich finde das ist der grundlegend falsche Ort. Speichersicherheit gehört doch auf Host-Ebene und die VM verlässt sich darauf, korrekte Daten zu erhalten.
Ich würde auch nicht auf die Idee kommen, zwei VM-Images (ala VMDK/VHDX/qcow2/etc.) an die VM zu binden, die auf zwei Festplatten liegen und der VM das RAID und damit die Redundanzbildung darüber zu überlassen. Das VM-Image liegt am Host auf einem RAID (bzw. einem anderweitig verteilten System ala Ceph, DRBD oder so) und genau da findet auch ein etwaiges Checksumming statt (ob nun übers Dateisystem ala ZFS oder btrfs oder einen integrity layer ala dm-integrity oder direkt in der Verschlüsselung ala "authenticated encryption").
Ehm, wirklich ReFS innerhalb der VM? Ich finde das ist der grundlegend falsche Ort. Speichersicherheit gehört doch auf Host-Ebene und die VM verlässt sich darauf, korrekte Daten zu erhalten.
Ich würde auch nicht auf die Idee kommen, zwei VM-Images (ala VMDK/VHDX/qcow2/etc.) an die VM zu binden, die auf zwei Festplatten liegen und der VM das RAID und damit die Redundanzbildung darüber zu überlassen. Das VM-Image liegt am Host auf einem RAID (bzw. einem anderweitig verteilten System ala Ceph, DRBD oder so) und genau da findet auch ein etwaiges Checksumming statt (ob nun übers Dateisystem ala ZFS oder btrfs oder einen integrity layer ala dm-integrity oder direkt in der Verschlüsselung ala "authenticated encryption").
Ja, in der VM, da gehört es auch hin. Das RAID, das darunterliegt, wird von einem Hardware Controller mit FBU verwaltet, in z. B. vSphere eingebunden und von eben diesem nicht großartig angefasst.
Anders als in der VM macht das wenig Sinn - habe ich übrigens auch noch nie gesehen was du schreibst. Die VM hat mit der Redundanz ja schlicht gar nichts zu tun. Das ist eben der Punkt, refs hat nicht zwingend auch nur irgendwas mit Redundanz zu tun.
Es ist ein Dateisystem.
Man sollte sich bei dieser Diskussion etwas breiter mit dem Dateisystem beschäftigen, weil ReFS auch Features und einen Aufbau hat, die nichts mit der Sicherheit oder Spiegelung zu tun haben. Namentlich sind hier vor allem drei Sachen zu nennen:
1. ReFS erlaubt eine beliebig große Skalierung der Datenträger. Wer schon mal mit NTFS einen 10TB Datenträger erstellt hat und den später auf 30TB erweitern möchte, erlebt nämlich eine Überraschung.
2. ReFS basiert auf B-Trees. Auch hier die Anmerkung meinerseits, wer schon mal mit mehreren Milliarden Dateien auf einem Datenträger gearbeitet hat, will nicht wieder zu NTFS zurück. https://www.ntfs.com/refs-architecture.htm
3. ReFS unterstützt Checkpoints und "instant allocation" für Hyper-V Datenträger und ist seit Jahren die erste Wahl als Dateisystem für Hyper-V Hosts. https://aidanfinn.com/?p=18840
Um deine Frage mit einer einfachen Aussage zu beantworten: Ja! Die längere Antwort würde lauten, es kommt drauf an. Es gibt Bereiche da glänzt ReFS richtig und Bereiche da überwiegen die Nachteile.
Zu den Nachteilen zählt in meinen Augen vor allem die schlechte Unterstützung seitens Drittanbietersoftware, aber auch die noch fehlende "Disk Quota" Unterstützung. Dazu kommen dann noch Sachen wie die Kompatibilität unter verschiedenen Betriebssystemversionen, nimmt man einen unter Server 2019 formatierten ReFS Datenträger und bindet den unter Server 2022 an, kann man ohne jede Vorwarnung anschließend nicht mehr mit Server 2019 darauf zugreifen.
Das widerspricht sich docjh deutlich. Und ich sehe tatsächlich eher ersteres.
Ich würde sagen, außerhalb ist es sinnvoll und innerhalb kann man es sich dann sparen.
Nungut, oder man nutzt es innen und außen und lässt innen entsprechende Features weg, das geht ja auch. Man kann ja auch ZFS oder btrfs auch noch innerhalb einer VM nutzen.
Wie gesagt, eben doch. Siehe Beispiel von xexex. Genauso wie die Redundanz ala RAID sehe ich Verschlüsselung und eben auch etwaige Checksumen über Daten auf Host-Ebene. Der Integritätsschutz gehört auf Hostebene und nicht nur Teile davon. Und das bietet halt auch ReFS mehr gegenüber bspw. NTFS und ist daher auf Host-Ebene diesem wohl vorzuziehen ("wohl" weil ich auf Host-Ebene nur sehr wenig persönliche Erfahrung mit Windows habe, weil ich da anderes klar und deutlich vorziehe).
arktom schrieb:
Die VM hat mit der Redundanz ja schlicht gar nichts zu tun.
Das gilt nicht nur für Redundanz, sondern Integritätsschutz als Ganzes und ReFS integrity streams sind eben Teil einer solchen. In die VM gehört dann ein Dateisystem, das das nicht mehr bieten muss. Ob du da nun NTFS oder zusätzlich noch ReFS nutzt, das ist deine Sache.
arktom schrieb:
in z. B. vSphere eingebunden und von eben diesem nicht großartig angefasst.
... habe ich übrigens auch noch nie gesehen was du schreibst.
Ich beschrieb einen Integritätsschutz auf Host-Ebene. Bietet VMware etwa keinen vernünftigen solchen? Das würde mich aber wundern. Bzw. eigentlich auch nicht: Das kauft man ja schließlich nicht, weil es besonders gut wäre, sondern weil man zum vermeintlichen Marktführer greift. SCNR
"Nobody ever got fired for buying [hier beliebigen Marktführer einsetzen]."
Ergänzung ()
Nachtrag: ReFS integrity streams sind hier wohl tatsächlich eher ungeeignet für bspw. VM-Images, weshalb HyperV-Hosts Datenintegrität anders sicherstellen müssen. Dennoch gehört für mich Integritätsschutz (wie beschrieben) eben nicht in die VM sondern auf Host-Ebene.
