Frage Over-Provisioning automatisch aktiviert? SSD

[h1ght]

Nabend,

Frage:
Wird bei Debian 8 Jessie bzw. bei neueren Distributionen Over-Provisioning automatisch aktiviert bzw. verwaltet?

laut df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1 222G 5,9G 205G 3% /

Code: Alles auswählen

root@debian:/home/christoph# hdparm -N /dev/sda

/dev/sda:
 max sectors   = 488395055/488397168, HPA is enabled

488395055-488397168= 2113 sektoren * 512bytes=1 081 856=0,001081856GB

Code: Alles auswählen

root@debian:/home/christoph# fdisk -l

Disk /dev/sda: 232,9 GiB, 250058268160 bytes, 488395055 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb2b35082

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048 471625727 471623680 224,9G 83 Linux
/dev/sda2       471627774 488394751  16766978     8G  5 Extended
/dev/sda5       471627776 488394751  16766976     8G 82 Linux swap / Solaris

laut meiner recherche sollten bei consumer sachen die OP bei 7% liegen, also bei mir bei ~16GB
Wären 8GB nicht zu wenig?
weiter frage bzw. wo liegt der fehler in meiner denkweise bezüglich hdparm -N /dev/sda bzw. hpa mit dem max sector/min sector.
= bzw. hpa ist aktiviert aber gar kein OP wie es empfohlen wurde? bzw. Da ich schon pi mal daumen über 10TB insgesammt geschrieben auf dieser Platte (Anfängerfehler, verpennt das TRIM im RAID0 nicht verfügbar ist bei P45 )

Bzw. woher kommt die Diskrepanz zwischen belegt und verfügbar? Habe ja nur ~222GB davon 6GB belegt und 10GB sind laut df -h irgendwo anders ô.O
Ich als langwieriger windoof user bin mal wieder mächtig verwirrt

[smutbert]

An der Ausgabe von hdparm -N sieht man einmal, dass es eine Host-Protected Area (HPA) gibt, die vermutlich (und allgemein unter anderem, aber nicht nur und auch nicht zwangsweise) fürs Overprovisioning verwendet wird.

Die HPA kann auch Daten enthalten, zB so etwas wie eine versteckte Recovery-Partition oder ähnliches und wenn Daten darauf stehen, dann hilft sie beim Overprovisioning natürlich nicht weiter. Um sicher zu gehen müsste man afaik zuerst die HPA deaktivieren, dann das ganze Device bzw. den fürs Overprovisioning vorgesehenen Bereich "discarden"/"trimmen" und dann eben gegebenenfalls wieder als HPA reservieren, was dann insgesamt auch mindestens 2 Neustarts (Kaltstarts glaube) erfordert, damit die jeweiligen Änderungen an der HPA wirksam werden.

Andererseits, wenn es vom Werk aus auf einer (einzeln und nicht mit einem Komplettsystem gekauften) SSD so eine HPA gibt, dann kann man imho auch davon ausgehen, dass sie zum Zwecke des Overprovisioning existiert.


Ich schreib auch gern noch ein paar weitere Überlegungen nieder, aber vorher wärs interessant was P45 ist - das sagt mir gar nichts.

[Lord_Carlos]

Ist Over-Provisioning nicht etwas was von SSD Controller gesteuert wird?

Kann es sein das ein tool GB und ein tool GiB angibt?

[smutbert]

Das wohl sowieso, immerhin muss der Controller ja auch von der HPA wissen, die es im übrigen auch bei Festplatten gibt. Darüber hinaus verfügen (viele oder gar fast alle) SSDs wohl auch noch über zusätzliches Overprovisioning, das von außen weder als HPA noch sonstwie sichtbar ist, so muss es ja zB auch ein paar Reserveflashzellen geben, damit defekte ersetzt werden können.

[h1ght]

An der Ausgabe von hdparm -N sieht man einmal, dass es eine Host-Protected Area (HPA) gibt, die vermutlich (und allgemein unter anderem, aber nicht nur und auch nicht zwangsweise) fürs Overprovisioning verwendet wird.

Die HPA kann auch Daten enthalten, zB so etwas wie eine versteckte Recovery-Partition oder ähnliches und wenn Daten darauf stehen, dann hilft sie beim Overprovisioning natürlich nicht weiter. Um sicher zu gehen müsste man afaik zuerst die HPA deaktivieren, dann das ganze Device bzw. den fürs Overprovisioning vorgesehenen Bereich "discarden"/"trimmen" und dann eben gegebenenfalls wieder als HPA reservieren, was dann insgesamt auch mindestens 2 Neustarts (Kaltstarts glaube) erfordert, damit die jeweiligen Änderungen an der HPA wirksam werden.

Andererseits, wenn es vom Werk aus auf einer (einzeln und nicht mit einem Komplettsystem gekauften) SSD so eine HPA gibt, dann kann man imho auch davon ausgehen, dass sie zum Zwecke des Overprovisioning existiert.


Ich schreib auch gern noch ein paar weitere Überlegungen nieder, aber vorher wärs interessant was P45 ist - das sagt mir gar nichts.

Entschuldige mich, dass ich mich kryptisch artikuliert habe. Das ist der Mainboard Chipsatz meiner alten Möhre. GA-P45-UD3P rev.1 wäre die korrekte Bezeichnung für mein Brett. Der Chipsatz kann TRIM aber nicht unter RAID. Ich vergesse immer, dass hier keine hardcore Gamer vertreten sind welche die Desktop Chipsätze auswending kennen.

Ja ich habe mich noch nicht befasst ob du/df in gigibyte bzw. dezimal/binär rechnen? Wenn man denkt man kennt sich aus, fällt man auf die Schnauze. Ich sollte mir mal ein Linux-Grundlagen-Buch besorgen und es verspeisen. SSD ist eine Samsung 840 EVO mit 250GB. Habe zwei davon, waren so günstig damals. Unter Windows musste ich den Cacheboost bzw. OP immer Manuell mit der Samsung Software Suite aktivieren. Deswegen war ich verwundert als ich sie gebenched habe, dass der geboostete Cache aktiviert ist bzw. mir die gleichen Werte ins Gesicht sprangen.

Zumindest kann ich mir bei df -h immer noch kein Reim machen, wieso zwischen verfügbar und belegt ein Unterschied halt ist. Ich will ja bei linux bleiben, weil mir der Humor gefällt den ich manchmal erblicke.

Für jemanden der wieder unnützige Informationen lesen möchte, meine Hardware
Intel Core2Quad Q9450
GA-P45-UD3P rev.1
DDR2-1066 von OCZ Reaper
AMD R9 290
Unter machen Umständen und Bugs habe ich mehr FPS in manch einem Spiel als jemand mit einem Top-modernen System

Müsst mich noch reinlesen ob meine SSD von dem Bug betroffen ist und in der Blacklist steht.

[smutbert]

Abgesehen von HPA (das es übrigens auch bei Festplatten gibt) gibts sogar wahrscheinlich noch ein weiteres von außen nicht sichtbares Overprovisioning. Immerhin sollte es wohl auch Reservespeicher geben mit dem defekte Flashzellen ersetzt werden können, selbst wenn der Anwender HPA deaktiviert hat oder die SSD von Werk aus ohne HPA ausgeliefert wird. Dieses Overprivisioning wird jedenfalls vom SSD-Controller verwaltet ohne, dass das Betriebssystem etwas davon mitbekommt.

Ich verzichte bei meiner SSD auf HPA und sehe einfach zu, dass es immer genug freien Speicher gibt, der der SSD auch als frei bekannt ist. Das könnte man zB mit einem einem unpartitioniertem Bereich auf der SSD erreichen oder auch einer swap-Partition, die etwas größer als notwendig ist (swap aktiviert discard/trim ganz automatisch - nur das Chipsatz-RAID stünde dem ev. im Weg).


Dass P45 ein Chipsatz ist habe ich dann auch noch herausgefunden. Die Raidfunktionen des Chipsatzes würde ich ganz bestimmt nicht verwenden - mir scheint damit verbindet man lediglich die Nachteile von einem richtigen Hardware-RAID mit denen eines richtigen Software-RAID. Letzteres würde ich inzwischen jederzeit vorziehen.
(wobei ich mich gerade frage ob unter GNU/Linux discard/trim nicht trotzdem funktionieren sollte, immerhin verwendet Linux ja den device-mapper für die Unterstützung von Chipsatz-Raids und der device-mapper kann discard/trim durchreichen - dm-raid seit Kernel 3.18 - blöd wärs nur, wenn das BIOS die trim-Unterstützung auf irgendeine Art und Weise deaktivieren würde, wegen des raid-Modus)

mit einem „normalen“ stellt discard/trim jedenfalls kein Problem mehr dar und speziell wenn man ein Dateisystem mit eingebauter raid-Unterstützung verwendet (zfs, btrfs) profitiert man uU auch noch von der Kenntnis des Dateisystems über das raid.


Die df-Ausgabe und deren Diskrepanz hat nur etwas mit dem Dateisystem zu tun und da spielt es keine Rolle ob das auf einer HDD, einer SSD, einem RAID oder etwas anderem liegt und HPA oder Overprovisionung hat nichts damit zu tun.
Kleinere Diskrepanzen aufgrund von Rundungsfehlern sind völlig normal, bei mir zB

Code: Alles auswählen

/dev/sde1       3.7T  1.8T  2.0T  48% /media/smutbert/...

Mehr könnte man vielleicht sagen, wenn du verrätst welches Dateisystem du verwendest. ext4 reserviert beispielsweise 5% für root und das journal gibt es auch noch, von dem weiß ich aber gar nicht ob/wie es in die Berechnung einfließt.

[h1ght]

Abgesehen von HPA (das es übrigens auch bei Festplatten gibt) gibts sogar wahrscheinlich noch ein weiteres von außen nicht sichtbares Overprovisioning. Immerhin sollte es wohl auch Reservespeicher geben mit dem defekte Flashzellen ersetzt werden können, selbst wenn der Anwender HPA deaktiviert hat oder die SSD von Werk aus ohne HPA ausgeliefert wird. Dieses Overprivisioning wird jedenfalls vom SSD-Controller verwaltet ohne, dass das Betriebssystem etwas davon mitbekommt.

Ich verzichte bei meiner SSD auf HPA und sehe einfach zu, dass es immer genug freien Speicher gibt, der der SSD auch als frei bekannt ist. Das könnte man zB mit einem einem unpartitioniertem Bereich auf der SSD erreichen oder auch einer swap-Partition, die etwas größer als notwendig ist (swap aktiviert discard/trim ganz automatisch - nur das Chipsatz-RAID stünde dem ev. im Weg).


Dass P45 ein Chipsatz ist habe ich dann auch noch herausgefunden. Die Raidfunktionen des Chipsatzes würde ich ganz bestimmt nicht verwenden - mir scheint damit verbindet man lediglich die Nachteile von einem richtigen Hardware-RAID mit denen eines richtigen Software-RAID. Letzteres würde ich inzwischen jederzeit vorziehen.
(wobei ich mich gerade frage ob unter GNU/Linux discard/trim nicht trotzdem funktionieren sollte, immerhin verwendet Linux ja den device-mapper für die Unterstützung von Chipsatz-Raids und der device-mapper kann discard/trim durchreichen - dm-raid seit Kernel 3.18 - blöd wärs nur, wenn das BIOS die trim-Unterstützung auf irgendeine Art und Weise deaktivieren würde, wegen des raid-Modus)

mit einem „normalen“ stellt discard/trim jedenfalls kein Problem mehr dar und speziell wenn man ein Dateisystem mit eingebauter raid-Unterstützung verwendet (zfs, btrfs) profitiert man uU auch noch von der Kenntnis des Dateisystems über das raid-Modus.


Die df-Ausgabe und deren Diskrepanz hat nur etwas mit dem Dateisystem zu tun und da spielt es keine Rolle ob das auf einer HDD, einer SSD, einem RAID oder etwas anderem liegt und HPA oder Overprovisionung hat nichts damit zu tun.
Kleinere Diskrepanzen aufgrund von Rundungsfehlern sind völlig normal, bei mir zB

Code: Alles auswählen

/dev/sde1       3.7T  1.8T  2.0T  48% /media/smutbert/...

Mehr könnte man vielleicht sagen, wenn du verrätst welches Dateisystem du verwendest. ext4 reserviert beispielsweise 5% für root und das journal gibt es auch noch, von dem weiß ich aber gar nicht ob/wie es in die Berechnung einfließt.

ext4 benutze ich, du kannst bei einem "anfänger" von ausgehen, dass er die festplatte automatisch partioniert und nur eine partition hat (exklusive swap)
Ich schätze mal es ist das Journaling. Ich habe mich mal hereingelesen und auf englisch gegoogelt. Hach war Windows so schön, da musste man sich weniger hereinlesen.

[MSfree]

Bzw. woher kommt die Diskrepanz zwischen belegt und verfügbar?

Mit Overprovisioning hat das nichts zu tun, das ist der ganz normale Overhead des Dateisystems:
http://debianforum.de/forum/viewtopic.p ... t=overhead
Lieder ist der Link zur Erklärung (zur Zeit) nicht erreichbar:
http://www.lisnichenko.com/articles/ext ... art-1.html