Bigeagle schrieb:
Der Controller leitet den Wert des Sektors daraus ab ob er beschrieben ist und nicht anhand des tatsächlichen Inhaltes.
Das macht jeder SSD Controller genauso, wenn ein LBA nie beschrieben (oder wieder getrimmt) wurde, dann steht der LBA gar nicht mehr in der Mappingtabelle und der Controller wüsste gar nicht, wo er Daten dafür auslesen sollte. Wo ist das Problem, wenn die HDD dies nun auch macht? Normalerweise stehen bei nagelneuen HDDs auf allen Sektoren nur Nullen, wenn eine Sektor also nie überschrieben wurde, dann würde die HDD beim Auslesen sowieso nur Nullen zurückgeben, wenn der nun weiß das dieser Sektor nie beschrieben (oder wieder getrimmt) wurde und die Nullen direkt ausgibt, wo ist das Problem? Nur kann man das Wiederherstellen von versehentlich gelöschten Dateien dann vergessen, wenn TRIM aktiv war, aber bei SSDs ist dies doch genauso.
Bigeagle schrieb:
Wobei ich mich schon frage wie die HDD an das Wissen vom Dateisystem kommt. Jeden Sektor flaggen wenn er das erste mal beschrieben wurde klingt unsinnig.
Den Aufwand sich selbst für jeden Sektor zu merken ob der jemals beschrieben bzw. ggf. danach wieder getrimmt wurde, halte ich auch für so groß, dass ich mir dies eigentlich nicht vorstellen konnte. Dazu hatte ich im anderen Thread schon mal geschrieben:
Holt schrieb:
Das einzige was mich interessieren würde wäre, wie sie das mit dem TRIM handhaben. Der Sinn ist klar, Sektoren die getrimmt wurden, braucht nicht mehr eingelesen und zurückgeschrieben werden, wenn sie ungewollt überschrieben werden, eben weil die sie überlappende Nachbarspur überschrieben wird. Es bringt erst richtig was, wenn alle Sektoren einer Spur getrimmt sind, dann kann man deren sie überlappende Nachbarspur nämlich wie bei CMR einfach nur überschreiben. Aber 6TB bedeutet über 11,5 Milliarden Sektoren, also fast 12GB an Daten wenn man ein Byte pro LBA speichert und selbst wenn es nur ein Bit ist, sind es noch 1,5GB an Daten und damit viel zu viel für die 256MB des DRAM Cache. Bei jedem TRIM Befehl muss also irgendwo auf die HDD geschrieben werden, was wegen der Kopfbewegungen die Performance auch nicht verbessert und dann muss ja in den Daten auch wieder vermerkt werden, wenn der Sektor mit neuen Daten beschrieben wurden, dies hebt das TRIM ja wieder auf, wird ein LBA getrimmt bedeutet dies ja, dass seine Daten ungültig sind, die Datei zu der sie gehört haben, wurde ja gelöscht, der Controller muss sie also nicht erhalten, aber wenn neue Daten auf dem LBA geschrieben werden, dann sind diese wieder gültig und müssen erhalten blieben. Schreibt man diese Information auf einen gesonderten Bereich, so muss dieser bei jedem TRIM oder Schreibbefehl auch angefahren und überschrieben werden. Schreibt man es aber zu den Daten den Sektoren, dann wäre es zwar beim Schreiben neuer Daten einfach, aber beim TRIM müsste man ja wieder die anderen Sektoren einlesen und neu Zurückschreiben, die Spuren sich ja nun einmal überlappen und dann würde jeder TRIM Befehl extrem lange brauchen um ausgeführt zu werden, dies wäre also nicht praktikabel, aber immer nur wegen TRIM eine anderen Position anfahren und dort 1,5GB Daten zu lesen oder ggf. zu überschreiben, könnte mehr Performance kosten als man am Ende gewinnt, denn es würde immer Performance kosten, ob man sich das Lesen und zurückschreiben eines Sektors sparen kann, ist dagegen ungewiss.
Nun findet mgutt beim Testen raus, dass es beim Lesen mit HD Tune einen gewaltigen Unterschied macht ob eine Partition vorhanden ist oder nicht, mit einer leeren Partition kommen über 350MB/s über die ganze Kapazität raus, so schnell kann keine 3.5" HDD lesen und schon gar nicht konstant von den äußersten bis zu den innersten Spuren, da wird also offensichtlich gar nicht von der Platte selbst gelesen, wohl aber wenn die Partition gelöscht wurde. Also scheint der Controller die Partitiontabelle und wertet auch das Filesystem und die Belegung aus, wie der Test bei dem mit 2,5TB befüllt war, nahe legt:
Allerdings muss die Platte dann eigentlich verschiedene Filesysteme unterstützen wenn es nicht nur unter Windows klappen soll und wenn sie in einem RAID 0, 5 oder 6 läuft, dann klappt es nicht mehr und kann ggf. wirklich gefährlich werden, da ja bei ausreichend großem Stripesize die Partitiontabelle komplett auf einer der Platten des RAIDs steht. Wenn der Offset der ersten Partition klein genug ist, dann steht so Kennung des Filesysteme dort. Die Adressen stimmen aber natürlich nicht, ein RAID 0 aus zwei der 6TB ist ja 12TB groß und die Partitionstabelle kann Daten jenseits der Kapazität der HDD enthalten auf der sie steht, was ggf. auch diesen komischen "IDNF" ("Sector ID not found") Fehler erklären könnte. Der käme dann gar nicht daher das der Host einen LBA adressiert hat den es nicht gibt, die RAID Lösung (egal ob HW oder SW RAID) rechnet die globalen Adressen des RAIDs (die so ja auch in der Partitionstabelle und allen anderen Metadaten auf dem RAID stehen) in die lokalen Adressen der einzelnen Platten um, aber wenn der Controller selbst versucht die Metadaten auf der Platte auszuwerten, dann findet er ggf. dort Adressen die über den eigenen Adressraum hinausgehen, die Platte weiß ja nicht, dass sie Teil eines RAIDs ist, aber an der Stelle könnte der Controller dies merken und abbrechen statt so einen Fehler auszugeben.
Nur wenn der Controller in Wahrheit die Metadaten auf der Platte auswertet, wozu dann die TRIM Untersützung? Nur als Ablenkung? Beim Entfernen einer Partition aus der Partitiontabelle wird ja nicht getrimmt, dies passiert erst beim Schnellformatieren, was man üblicherweise macht wenn man eine Partition anlegt.
mgutt, beim Test mit den 2,5TB Daten war da doch eine große Partition drauf oder? Kannst Du den nochmal wiederholen und danach die Dateien im Explorer löschen und erneut mit HD Tune benchen? Führe ggf. vorher ein Schnellformat aus um alles zu trimmen. Wärst Du auch in der Lage unter Linux zu benchen?
