Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Samsung SSD 840 EVO schreibt nur noch 20 MB/s
56 views
Skip to first unread message
Marc Haber
Jun 12, 2021, 6:41:01 AM6/12/21
to
Hallo,
mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
ist EXT0CB6Q. Das gute Stück hat inzwischen 29000 Stunden und
180.384.825.722 "Total LABs Written" auf der Uhr. Wenn man das mit 512
multipliziert, kommt das bei 84 TBW raus. Den vollständigen
Smartctl-Output hänge ich an.
Nachdem ich in den letzten Tagen die Bulk-Geschwindigkeit von ein paar
unterschiedlich schnellen USB3-Speichermedien gemessen habe, habe ich
denselben Test auch bei meiner SSD gemacht und war sehr erstaunt, dass
die Platte nur noch 20 MByte/s (!) schreibt. Da sind nur noch die
Micro-SD-Karte vom Raspberry Pi und die kleinen USB-Sticks langsamer,
selbst das außer Konkurrenz mitlaufende Dreheisen schreibt schneller.
Auf der SSD sind 270 GByte aktuell unpartitioniert, aber bestimmt
schonmal in Benutzung gewesen, weli ich gerne mal ein paar hundert GB
für kurze Zeit allokiere, benutze und dann wieder freigebe.
Betriebssystem ist Linux, die SSD ist verschlüsselt und mit LVM
aufgeteilt, ich benutze ziemlich viel VMs und in diesen dann wieder
LVM, so dass ich meine Zweifel habe, ob TRIM-Befehle durch den
komplizierten Treiberstapel von
Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
Ich bin jetzt darauf vorbereitet, die Logical Volumes auf eine
bereitstehende HDD zu verlagern, der SSD dann ein Secure Erase
Kommando zu schicken, bei der Gelegenheit die Firmware auf EXT0DB6Q zu
aktualisieren, kurz die Performance zu messen und ggf dann die Logical
Volumes wieder zurück auf die SSD zu schieben.
Soll ich noch andere Tests/Aktionen durchführen, um diese doch relativ
seltene Situation einer gut durchgealterten, aber ganz leeren SSD mal
auszunutzen?
Seht ihr einen Weg, die SSD ohne die Kopier-Lösch-Kopier-Aktion zu
beschleunigen? Oder möchte die SSD mit dieser abgrundtiefen
Performance sowieso nur ihr baldiges Ableben ankündigen?
Grüße
Marc
|smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.12.9-zgws1] (local build)
|Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
|
|=== START OF INFORMATION SECTION ===
|Model Family: Samsung based SSDs
|Device Model: Samsung SSD 840 EVO 1TB
|Firmware Version: EXT0CB6Q
|User Capacity: 1.000.204.886.016 bytes [1,00 TB]
|Sector Size: 512 bytes logical/physical
|Rotation Rate: Solid State Device
|TRIM Command: Available
|Device is: In smartctl database [for details use: -P show]
|ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
|SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
|Local Time is: Sat Jun 12 10:09:18 2021 CEST
|SMART support is: Available - device has SMART capability.
|SMART support is: Enabled
|
|=== START OF READ SMART DATA SECTION ===
|SMART overall-health self-assessment test result: PASSED
|See vendor-specific Attribute list for marginal Attributes.
|
|General SMART Values:
|Offline data collection status: (0x00) Offline data collection activity
| was never started.
| Auto Offline Data Collection: Disabled.
|Self-test execution status: ( 0) The previous self-test routine completed
| without error or no self-test has ever
| been run.
|Total time to complete Offline
|data collection: (15000) seconds.
|Offline data collection
|capabilities: (0x53) SMART execute Offline immediate.
| Auto Offline data collection on/off support.
| Suspend Offline collection upon new
| command.
| No Offline surface scan supported.
| Self-test supported.
| No Conveyance Self-test supported.
| Selective Self-test supported.
|SMART capabilities: (0x0003) Saves SMART data before entering
| power-saving mode.
| Supports SMART auto save timer.
|Error logging capability: (0x01) Error logging supported.
| General Purpose Logging supported.
|Short self-test routine
|recommended polling time: ( 2) minutes.
|Extended self-test routine
|recommended polling time: ( 250) minutes.
|SCT capabilities: (0x003d) SCT Status supported.
| SCT Error Recovery Control supported.
| SCT Feature Control supported.
| SCT Data Table supported.
|
|SMART Attributes Data Structure revision number: 1
|Vendor Specific SMART Attributes with Thresholds:
|ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
| 5 Reallocated_Sector_Ct 0x0033 100 001 010 Pre-fail Always In_the_past 0
| 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 29716
| 12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 2953
|177 Wear_Leveling_Count 0x0013 081 001 000 Pre-fail Always - 221
|179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 001 010 Pre-fail Always In_the_past 0
|181 Program_Fail_Cnt_Total 0x0032 100 001 010 Old_age Always In_the_past 0
|182 Erase_Fail_Count_Total 0x0032 100 001 010 Old_age Always In_the_past 0
|183 Runtime_Bad_Block 0x0013 100 001 010 Pre-fail Always In_the_past 0
|187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
|190 Airflow_Temperature_Cel 0x0032 063 036 000 Old_age Always - 37
|195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
|199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 66
|235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 313
|241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 180384825722
|
|SMART Error Log Version: 1
|No Errors Logged
|
|SMART Self-test log structure revision number 1
|Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
|# 1 Extended offline Completed without error 00% 0 -
|# 2 Extended offline Completed without error 00% 0 -
|# 3 Extended offline Interrupted (host reset) 00% 0 -
|
|SMART Selective self-test log data structure revision number 1
| SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
| 1 0 0 Not_testing
| 2 0 0 Not_testing
| 3 0 0 Not_testing
| 4 0 0 Not_testing
| 5 0 0 Not_testing
|Selective self-test flags (0x0):
| After scanning selected spans, do NOT read-scan remainder of disk.
|If Selective self-test is pending on power-up, resume after 0 minute delay.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
ist EXT0CB6Q. Das gute Stück hat inzwischen 29000 Stunden und
180.384.825.722 "Total LABs Written" auf der Uhr. Wenn man das mit 512
multipliziert, kommt das bei 84 TBW raus. Den vollständigen
Smartctl-Output hänge ich an.
Nachdem ich in den letzten Tagen die Bulk-Geschwindigkeit von ein paar
unterschiedlich schnellen USB3-Speichermedien gemessen habe, habe ich
denselben Test auch bei meiner SSD gemacht und war sehr erstaunt, dass
die Platte nur noch 20 MByte/s (!) schreibt. Da sind nur noch die
Micro-SD-Karte vom Raspberry Pi und die kleinen USB-Sticks langsamer,
selbst das außer Konkurrenz mitlaufende Dreheisen schreibt schneller.
Auf der SSD sind 270 GByte aktuell unpartitioniert, aber bestimmt
schonmal in Benutzung gewesen, weli ich gerne mal ein paar hundert GB
für kurze Zeit allokiere, benutze und dann wieder freigebe.
Betriebssystem ist Linux, die SSD ist verschlüsselt und mit LVM
aufgeteilt, ich benutze ziemlich viel VMs und in diesen dann wieder
LVM, so dass ich meine Zweifel habe, ob TRIM-Befehle durch den
komplizierten Treiberstapel von
Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
Ich bin jetzt darauf vorbereitet, die Logical Volumes auf eine
bereitstehende HDD zu verlagern, der SSD dann ein Secure Erase
Kommando zu schicken, bei der Gelegenheit die Firmware auf EXT0DB6Q zu
aktualisieren, kurz die Performance zu messen und ggf dann die Logical
Volumes wieder zurück auf die SSD zu schieben.
Soll ich noch andere Tests/Aktionen durchführen, um diese doch relativ
seltene Situation einer gut durchgealterten, aber ganz leeren SSD mal
auszunutzen?
Seht ihr einen Weg, die SSD ohne die Kopier-Lösch-Kopier-Aktion zu
beschleunigen? Oder möchte die SSD mit dieser abgrundtiefen
Performance sowieso nur ihr baldiges Ableben ankündigen?
Grüße
Marc
|smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.12.9-zgws1] (local build)
|Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
|
|=== START OF INFORMATION SECTION ===
|Model Family: Samsung based SSDs
|Device Model: Samsung SSD 840 EVO 1TB
|Firmware Version: EXT0CB6Q
|User Capacity: 1.000.204.886.016 bytes [1,00 TB]
|Sector Size: 512 bytes logical/physical
|Rotation Rate: Solid State Device
|TRIM Command: Available
|Device is: In smartctl database [for details use: -P show]
|ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
|SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
|Local Time is: Sat Jun 12 10:09:18 2021 CEST
|SMART support is: Available - device has SMART capability.
|SMART support is: Enabled
|
|=== START OF READ SMART DATA SECTION ===
|SMART overall-health self-assessment test result: PASSED
|See vendor-specific Attribute list for marginal Attributes.
|
|General SMART Values:
|Offline data collection status: (0x00) Offline data collection activity
| was never started.
| Auto Offline Data Collection: Disabled.
|Self-test execution status: ( 0) The previous self-test routine completed
| without error or no self-test has ever
| been run.
|Total time to complete Offline
|data collection: (15000) seconds.
|Offline data collection
|capabilities: (0x53) SMART execute Offline immediate.
| Auto Offline data collection on/off support.
| Suspend Offline collection upon new
| command.
| No Offline surface scan supported.
| Self-test supported.
| No Conveyance Self-test supported.
| Selective Self-test supported.
|SMART capabilities: (0x0003) Saves SMART data before entering
| power-saving mode.
| Supports SMART auto save timer.
|Error logging capability: (0x01) Error logging supported.
| General Purpose Logging supported.
|Short self-test routine
|recommended polling time: ( 2) minutes.
|Extended self-test routine
|recommended polling time: ( 250) minutes.
|SCT capabilities: (0x003d) SCT Status supported.
| SCT Error Recovery Control supported.
| SCT Feature Control supported.
| SCT Data Table supported.
|
|SMART Attributes Data Structure revision number: 1
|Vendor Specific SMART Attributes with Thresholds:
|ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
| 5 Reallocated_Sector_Ct 0x0033 100 001 010 Pre-fail Always In_the_past 0
| 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 29716
| 12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 2953
|177 Wear_Leveling_Count 0x0013 081 001 000 Pre-fail Always - 221
|179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 001 010 Pre-fail Always In_the_past 0
|181 Program_Fail_Cnt_Total 0x0032 100 001 010 Old_age Always In_the_past 0
|182 Erase_Fail_Count_Total 0x0032 100 001 010 Old_age Always In_the_past 0
|183 Runtime_Bad_Block 0x0013 100 001 010 Pre-fail Always In_the_past 0
|187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
|190 Airflow_Temperature_Cel 0x0032 063 036 000 Old_age Always - 37
|195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
|199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 66
|235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 313
|241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 180384825722
|
|SMART Error Log Version: 1
|No Errors Logged
|
|SMART Self-test log structure revision number 1
|Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
|# 1 Extended offline Completed without error 00% 0 -
|# 2 Extended offline Completed without error 00% 0 -
|# 3 Extended offline Interrupted (host reset) 00% 0 -
|
|SMART Selective self-test log data structure revision number 1
| SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
| 1 0 0 Not_testing
| 2 0 0 Not_testing
| 3 0 0 Not_testing
| 4 0 0 Not_testing
| 5 0 0 Not_testing
|Selective self-test flags (0x0):
| After scanning selected spans, do NOT read-scan remainder of disk.
|If Selective self-test is pending on power-up, resume after 0 minute delay.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Shinji Ikari
Jun 12, 2021, 7:36:04 AM6/12/21
to
Guten Tag
Marc Haber <mh+usene...@zugschl.us> schrieb
>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>ist EXT0CB6Q.
Die 840 EVOs hatten mal ein Firmwareproblem, weshalb sie in
Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
gegengewirkt (Performance Restoration).
Hattest Du das damals durchgefuehrt?
Ich glaube das galt damals fuer alle Smausng 840 EVO SATA und mSATA.
https://www.samsung.com/de/support/model/MZ-7TE120BW/
Marc Haber <mh+usene...@zugschl.us> schrieb
>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>ist EXT0CB6Q.
Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
gegengewirkt (Performance Restoration).
Hattest Du das damals durchgefuehrt?
Ich glaube das galt damals fuer alle Smausng 840 EVO SATA und mSATA.
https://www.samsung.com/de/support/model/MZ-7TE120BW/
Marc Haber
Jun 12, 2021, 8:05:16 AM6/12/21
to
Shinji Ikari <shi...@gmx.net> wrote:
>Marc Haber <mh+usene...@zugschl.us> schrieb
>>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>>ist EXT0CB6Q.
>
>
>Die 840 EVOs hatten mal ein Firmwareproblem, weshalb sie in
>Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
>gegengewirkt (Performance Restoration).
>Hattest Du das damals durchgefuehrt?
Nein, ich weiß auch nicht ob meine Platte nicht vielleicht neuer ist.
>Marc Haber <mh+usene...@zugschl.us> schrieb
>>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>>ist EXT0CB6Q.
>
>
>Die 840 EVOs hatten mal ein Firmwareproblem, weshalb sie in
>Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
>gegengewirkt (Performance Restoration).
>Hattest Du das damals durchgefuehrt?
Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
Daten erhalten?
Grüße
Marc
Shinji Ikari
Jun 12, 2021, 9:12:15 AM6/12/21
to
Guten Tag
Marc Haber <mh+usene...@zugschl.us> schrieb
>>>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>>>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>>>ist EXT0CB6Q.
>>Die 840 EVOs hatten mal ein Firmwareproblem, weshalb sie in
>>Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
>>gegengewirkt (Performance Restoration).
>>Hattest Du das damals durchgefuehrt?
>Nein, ich weiß auch nicht ob meine Platte nicht vielleicht neuer ist.
>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>Daten erhalten?
Soweit ich mich von damals erinnere:
Nein, die Daten bleiben nicht erhalten
Die unterschiedlichen Versionen tun das Selbe, eine eben nur fuer DOS
die andere fuer Windows.
IMHO sollte die Platte dabei aber nicht als Bootlaufwerk aktiv sein.
Ist aber schon laaange her. Alles auf Dein eigenes Risiko.
Marc Haber <mh+usene...@zugschl.us> schrieb
>>>mein Desktop war damals der erste Rechner der eine SSD bekommen hat.
>>>Die Wahl fiel auf eine Samsung SSD 840 EVO 1TB, die Firmwareversion
>>>ist EXT0CB6Q.
>>Die 840 EVOs hatten mal ein Firmwareproblem, weshalb sie in
>>Performance verloren. Samsung hatte mit einer speziellen Prozedur 2014
>>gegengewirkt (Performance Restoration).
>>Hattest Du das damals durchgefuehrt?
>Nein, ich weiß auch nicht ob meine Platte nicht vielleicht neuer ist.
>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>Daten erhalten?
Nein, die Daten bleiben nicht erhalten
Die unterschiedlichen Versionen tun das Selbe, eine eben nur fuer DOS
die andere fuer Windows.
IMHO sollte die Platte dabei aber nicht als Bootlaufwerk aktiv sein.
Ist aber schon laaange her. Alles auf Dein eigenes Risiko.
Marc Haber
Jun 12, 2021, 9:14:51 AM6/12/21
to
Marc Haber <mh+usene...@zugschl.us> wrote:
>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>Daten erhalten?
Ich hab's natürlich nicht erwarten können, habe die SSD aus dem
>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>Daten erhalten?
Desktop ausgebaut und als zweite Platte¹ an mein Windows-Notebook
angeschlossen.
¹ in der Ultrabay ist die SSD als vollwertiges SATA-Device angebunden
Die Windows-Version von dem Samsung-Tool erkennt die SSD und sagt
dann, ich soll die SSD "initialisieren", was auch immer das bedeuten
soll. Da ich die SSD nicht für die Verwendung unter Windows
formatieren wollte, ging sie zurück in den Desktop und ich mache den
zweiten Versuch mit der Version für "sonstige" Betriebssysteme. Das
entpuppt sich als ein perf.exe für DOS.
Ich lade mir also das USB-Stick-Image von FreeDOS herunter und kopiere
es mit dd auf den Stick. Der Stick ist danach mit einem DOS Filesystem
versorgt, das ich in Linux einhängen kann und das perf.exe und ein
Unterverzeichnis mit zwei Firmwaredateien drauf kopieren kann.
Der Stick bootet auf dem Desktop und ich kann das perf.exe starten und
die Platte auswählen. Und an Step 2 hängt er jetzt seit einer halben
Stunde, malt etwa alle zehn Minuten einen Punkt dazu, damit man
überhaupt sieht, dass da gerade etwas passiert. Ich hoffe, dass das
kein "simulierter" Fortschritssanzeiger ist und wirklich etwas auf der
SSD passiert. Ich werde berichten.
Grüße
Marc
P.S.: Man verzeihe mir, dass ich in alter Gewohnheit immer wieder von
einer "Platte" spreche, aber in dch.laufwerke.festplatten wird man mir
das hoffentlich nachsehen
Gerald E:scher
Jun 12, 2021, 10:10:23 AM6/12/21
to
Marc Haber schrieb am 12/6/2021 15:14:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>>Daten erhalten?
>
> Ich hab's natürlich nicht erwarten können, habe die SSD aus dem
> Desktop ausgebaut und als zweite Platte¹ an mein Windows-Notebook
> angeschlossen.
Ich wollte dir vorschlagen, auf dem unpartitionierten Teil der SSD
> Marc Haber <mh+usene...@zugschl.us> wrote:
>>Sehe ich das richtig, dass die Version "DOS 1.0" dieselbe Prozedur
>>ausführt wie die Version "Windows 1.1" vom gleichen Tag? Bleiben die
>>Daten erhalten?
>
> Ich hab's natürlich nicht erwarten können, habe die SSD aus dem
> Desktop ausgebaut und als zweite Platte¹ an mein Windows-Notebook
> angeschlossen.
vorrübergehend eine Partition zu erstellen und mit blkdiscard zu TRIMen,
aber wohl zu spät.
Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt? Ubuntu
hat hierfür eine Timer Unit, Debian weiß ich nicht.
--
Gerald
Marc Haber
Jun 12, 2021, 10:57:59 AM6/12/21
to
"Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
Dem Vernehmen nach hat man das nie gebraucht, wenn das Betriebssystem
>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
das mit übernimmt (was Linux schon länger im Default tut als ich diese
SSD besitze), und bei modernen Platten gar nicht, wobei man sich
darüber streiten kann ob meine SSD 840 EVO schon als "modern" zählt.
Grüße
Marc
Marc Haber
Jun 12, 2021, 11:02:02 AM6/12/21
to
Marc Haber <mh+usene...@zugschl.us> wrote:
>Der Stick bootet auf dem Desktop und ich kann das perf.exe starten und
>die Platte auswählen. Und an Step 2 hängt er jetzt seit einer halben
>Stunde, malt etwa alle zehn Minuten einen Punkt dazu, damit man
>überhaupt sieht, dass da gerade etwas passiert. Ich hoffe, dass das
>kein "simulierter" Fortschritssanzeiger ist und wirklich etwas auf der
>SSD passiert. Ich werde berichten.
Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>Der Stick bootet auf dem Desktop und ich kann das perf.exe starten und
>die Platte auswählen. Und an Step 2 hängt er jetzt seit einer halben
>Stunde, malt etwa alle zehn Minuten einen Punkt dazu, damit man
>überhaupt sieht, dass da gerade etwas passiert. Ich hoffe, dass das
>kein "simulierter" Fortschritssanzeiger ist und wirklich etwas auf der
>SSD passiert. Ich werde berichten.
erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
mit dem Tool und lässt sogar die fast ungebrauchte und modernere
Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
EXT0DB6Q wäre möglich. Machen oder nicht?
Grüße
Marc
Bernd Mayer
Jun 12, 2021, 11:53:17 AM6/12/21
to
Am 12.06.21 um 17:02 schrieb Marc Haber:
ich hatte schon mehrmals ein update der Firmware bei SSDs (dabei war
auch eine 840 EVO) von Samsung durchgeführt über das CD-ROM-Image. Dabei
blieben die Daten jeweils erhalten, grob erinnere ich allerdings eine
Warnung vor Datenverlusten. Die letzten Firmwareupdates der 840 EVO
liegen ja länger zurück.
No Risk no Fun
Bernd Mayer
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Der Stick bootet auf dem Desktop und ich kann das perf.exe starten und
>> die Platte auswählen. Und an Step 2 hängt er jetzt seit einer halben
>> Stunde, malt etwa alle zehn Minuten einen Punkt dazu, damit man
>> überhaupt sieht, dass da gerade etwas passiert. Ich hoffe, dass das
>> kein "simulierter" Fortschritssanzeiger ist und wirklich etwas auf der
>> SSD passiert. Ich werde berichten.
>
> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>
> Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
> EXT0DB6Q wäre möglich. Machen oder nicht?
Hallo,
>> Der Stick bootet auf dem Desktop und ich kann das perf.exe starten und
>> die Platte auswählen. Und an Step 2 hängt er jetzt seit einer halben
>> Stunde, malt etwa alle zehn Minuten einen Punkt dazu, damit man
>> überhaupt sieht, dass da gerade etwas passiert. Ich hoffe, dass das
>> kein "simulierter" Fortschritssanzeiger ist und wirklich etwas auf der
>> SSD passiert. Ich werde berichten.
>
> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>
> Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
> EXT0DB6Q wäre möglich. Machen oder nicht?
ich hatte schon mehrmals ein update der Firmware bei SSDs (dabei war
auch eine 840 EVO) von Samsung durchgeführt über das CD-ROM-Image. Dabei
blieben die Daten jeweils erhalten, grob erinnere ich allerdings eine
Warnung vor Datenverlusten. Die letzten Firmwareupdates der 840 EVO
liegen ja länger zurück.
No Risk no Fun
Bernd Mayer
Shinji Ikari
Jun 12, 2021, 3:50:02 PM6/12/21
to
>Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
Das freut mich!
>erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>EXT0DB6Q wäre möglich. Machen oder nicht?
Ich wuerde sie auf die aktuellste Firmware updaten.
Marc Haber
Jun 12, 2021, 4:03:23 PM6/12/21
to
>>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>>EXT0DB6Q wäre möglich. Machen oder nicht?
>
>Diese Entscheidung liegt bei Dir.
>Ich wuerde sie auf die aktuellste Firmware updaten.
Ich tendiere zu "never touch a running system", wenn das
>>EXT0DB6Q wäre möglich. Machen oder nicht?
>
>Diese Entscheidung liegt bei Dir.
>Ich wuerde sie auf die aktuellste Firmware updaten.
Performancetool das Firmwareupdate nicht für nötig gehalten hat und
die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
sie auch bis zu ihrem Tod mit dieser Firmware laufen...
Shinji Ikari
Jun 12, 2021, 4:29:56 PM6/12/21
to
>Ich tendiere zu "never touch a running system", wenn das
>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
...und moeglicherweise das selbe Problem wieder neu erleben.
>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
Gerald E:scher
Jun 12, 2021, 6:39:26 PM6/12/21
to
Marc Haber schrieb am 12/6/2021 16:57:
> "Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
>
> Dem Vernehmen nach hat man das nie gebraucht, wenn das Betriebssystem
> das mit übernimmt (was Linux schon länger im Default tut als ich diese
> SSD besitze),
Jedenfalls bei Ubuntu per fstrim.timer. Stammt aber eh von Debian:
> "Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
>
> Dem Vernehmen nach hat man das nie gebraucht, wenn das Betriebssystem
> das mit übernimmt (was Linux schon länger im Default tut als ich diese
> SSD besitze),
https://packages.debian.org/buster/arm64/util-linux/filelist
> und bei modernen Platten gar nicht, wobei man sich
> darüber streiten kann ob meine SSD 840 EVO schon als "modern" zählt.
mit belegten Blöcken sein kann, und zu wenig Overprovisioning muss
der Controller der SSD vor dem Schreiben eines Blockes diesen erst
löschen und das verlangsamt massiv.
--
Gerald
Gerald E:scher
Jun 12, 2021, 6:45:29 PM6/12/21
to
Marc Haber schrieb am 12/6/2021 22:03:
> Shinji Ikari <shi...@gmx.net> wrote:
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>>>EXT0DB6Q wäre möglich. Machen oder nicht?
>>
>>Diese Entscheidung liegt bei Dir.
>>Ich wuerde sie auf die aktuellste Firmware updaten.
>
> Ich tendiere zu "never touch a running system",
Ich würde zumindest ins changelog der Firmware schauen. Vielleicht
> Shinji Ikari <shi...@gmx.net> wrote:
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>>>EXT0DB6Q wäre möglich. Machen oder nicht?
>>
>>Diese Entscheidung liegt bei Dir.
>>Ich wuerde sie auf die aktuellste Firmware updaten.
>
> Ich tendiere zu "never touch a running system",
behebt die dein Problem mit der Verlangsamung.
--
Gerald
Gerald E:scher
Jun 12, 2021, 6:51:26 PM6/12/21
to
Marc Haber schrieb am 12/6/2021 12:40:
> Betriebssystem ist Linux, die SSD ist verschlüsselt und mit LVM
> aufgeteilt, ich benutze ziemlich viel VMs und in diesen dann wieder
> LVM, so dass ich meine Zweifel habe, ob TRIM-Befehle durch den
> komplizierten Treiberstapel von
> Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
> Betriebssystem ist Linux, die SSD ist verschlüsselt und mit LVM
> aufgeteilt, ich benutze ziemlich viel VMs und in diesen dann wieder
> LVM, so dass ich meine Zweifel habe, ob TRIM-Befehle durch den
> komplizierten Treiberstapel von
> Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
bei einem TRIM des Gastes wieder verkleinern und dann kann der
Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
--
Gerald
Friedemann Stoyan
Jun 12, 2021, 11:52:58 PM6/12/21
to
Marc Haber wrote:
> Shinji Ikari <shi...@gmx.net> wrote:
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>>>EXT0DB6Q wäre möglich. Machen oder nicht?
>>
>>Diese Entscheidung liegt bei Dir.
>>Ich wuerde sie auf die aktuellste Firmware updaten.
> Ich tendiere zu "never touch a running system", wenn das
> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
Kannst Du ruhig machen. Ich habe seit ewigen Zeiten ohne Probleme am rennen:
> Shinji Ikari <shi...@gmx.net> wrote:
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
>>>EXT0DB6Q wäre möglich. Machen oder nicht?
>>
>>Diese Entscheidung liegt bei Dir.
>>Ich wuerde sie auf die aktuellste Firmware updaten.
> Ich tendiere zu "never touch a running system", wenn das
> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 840 EVO 1TB
User Capacity: 1.000.204.886.016 bytes [1,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
mfg Friedemann
Detlef Wirsing
Jun 13, 2021, 3:45:41 AM6/13/21
to
Marc Haber schrieb:
...
Dieser Satz hat dir eine Schreibgeschwindigkeit von 20 MB/s beschert.
Das solltest du bedenken. Ich tendiere zu allen Updates, die ich
kriegen kann. Nicht unbedingt gleich am ersten Tag, aber doch zeitnah.
Mit freundlichen Grüßen
Detlef Wirsing
...
>Ich tendiere zu "never touch a running system"
...
Dieser Satz hat dir eine Schreibgeschwindigkeit von 20 MB/s beschert.
Das solltest du bedenken. Ich tendiere zu allen Updates, die ich
kriegen kann. Nicht unbedingt gleich am ersten Tag, aber doch zeitnah.
Mit freundlichen Grüßen
Detlef Wirsing
Frank Möller
Jun 13, 2021, 4:18:08 AM6/13/21
to
Gerald E:scher:
> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
> bei einem TRIM des Gastes wieder verkleinern und dann kann der
> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
Das gelegentliche Verkleinern des Images kann man auch nach Gusto manuell
anstoßen (unter Windows):
"<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
Innerhalb einer Windows-VM kann man auch _vorher_ ab und zu mal
<https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete>
laufen lassen.
--
> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
> bei einem TRIM des Gastes wieder verkleinern und dann kann der
> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
anstoßen (unter Windows):
"<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
Innerhalb einer Windows-VM kann man auch _vorher_ ab und zu mal
<https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete>
laufen lassen.
--
Marcel Mueller
Jun 13, 2021, 4:23:34 AM6/13/21
to
Am 13.06.21 um 00:51 schrieb Gerald E:scher:
1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
> VirtualBox kann allerdings ein mitwachsendes Image
> bei einem TRIM des Gastes wieder verkleinern und dann kann der
> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
Das ist /nicht/ zu empfehlen. Dabei werden erhebliche Teile des
virtuellen Disk-Images neu geschrieben. Man muss schon viel Glück haben,
damit das /weniger/ ist, als die vom SSD-Controller ohne Trimmung
unnötig kopierten Daten; zumal aufgrund der obigen 1MB Restriktion oft
recht viel Luft drin bleibt.
> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
Da kann es Sinn ergeben, wenn man den Platz für die virtuellen Disks in
Summe überbuchen möchte. Andernfalls ist es auch sinnlos. Aber
Drehplatten stört es halt auch nicht wirklich.
Wünschen würde ich mir, das TRIM im Gast zu Sparse Files im Host führt.
Dann könnte man von Anfang an mit direkt gemappten Images ohne interne
Blockverwaltung arbeiten. Das würde dann das Dateisystem des Hosts
übernehmen, das macht es so wie so. Damit würde TRIm automatsisch bis
auf den physischen Datenträger durchgehen, solange nicht irgendetwas
ganz anderes dazwischen es aufhält.
Im Übrigen ist LUKS so ein Kandidat, der TRIM aufhalten kann. Da die
Kenntnis der nicht benötigten Blocke ein Informationsleck ist, wird
durch TRIM die Sicherheit der Verschlüsselung beeinträchtigt. Man kann
die Free Space Bitmaps des Dateisystems vorhersagen und damit versuchen,
die Verschlüsselung anzugreifen. Ich glaube, in der Standardeinstellung
wird nicht getrimmt.
Marcel
>> Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
>
> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
> nicht direkt durch.
Jein. So ein bisschen haben sie es schon, aber da die VBox Block-Größe
>
> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
> nicht direkt durch.
1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
> VirtualBox kann allerdings ein mitwachsendes Image
> bei einem TRIM des Gastes wieder verkleinern und dann kann der
> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
virtuellen Disk-Images neu geschrieben. Man muss schon viel Glück haben,
damit das /weniger/ ist, als die vom SSD-Controller ohne Trimmung
unnötig kopierten Daten; zumal aufgrund der obigen 1MB Restriktion oft
recht viel Luft drin bleibt.
> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
Summe überbuchen möchte. Andernfalls ist es auch sinnlos. Aber
Drehplatten stört es halt auch nicht wirklich.
Wünschen würde ich mir, das TRIM im Gast zu Sparse Files im Host führt.
Dann könnte man von Anfang an mit direkt gemappten Images ohne interne
Blockverwaltung arbeiten. Das würde dann das Dateisystem des Hosts
übernehmen, das macht es so wie so. Damit würde TRIm automatsisch bis
auf den physischen Datenträger durchgehen, solange nicht irgendetwas
ganz anderes dazwischen es aufhält.
Im Übrigen ist LUKS so ein Kandidat, der TRIM aufhalten kann. Da die
Kenntnis der nicht benötigten Blocke ein Informationsleck ist, wird
durch TRIM die Sicherheit der Verschlüsselung beeinträchtigt. Man kann
die Free Space Bitmaps des Dateisystems vorhersagen und damit versuchen,
die Verschlüsselung anzugreifen. Ich glaube, in der Standardeinstellung
wird nicht getrimmt.
Marcel
Christian Potzinger
Jun 13, 2021, 4:27:06 AM6/13/21
to
On 13.06.2021 09:45, Detlef Wirsing wrote:
>> Ich tendiere zu "never touch a running system"
>> Ich tendiere zu "never touch a running system"
> Dieser Satz hat dir eine Schreibgeschwindigkeit von 20 MB/s beschert.
Su nennst 20 MB/s "running"? :)
--
ryl: G'Kar
Bernd Mayer
Jun 13, 2021, 5:42:47 AM6/13/21
to
Am 13.06.21 um 10:16 schrieb Frank Möller:
unter Linux geht das wohl mit:
vbox-img compact, siehe vbox-img --help.
Oder?
Bernd Mayer
> Gerald E:scher:
>
>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
>
> Das gelegentliche Verkleinern des Images kann man auch nach Gusto manuell
> anstoßen (unter Windows):
>
> "<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
Hallo,
>
>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
>
> Das gelegentliche Verkleinern des Images kann man auch nach Gusto manuell
> anstoßen (unter Windows):
>
> "<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
unter Linux geht das wohl mit:
vbox-img compact, siehe vbox-img --help.
Oder?
Bernd Mayer
Marc Haber
Jun 13, 2021, 7:14:16 AM6/13/21
to
verhindert dass das Problem neu auftritt.
Bernd Mayer
Jun 13, 2021, 8:53:26 AM6/13/21
to
Am 13.06.21 um 13:14 schrieb Marc Haber:
ich hätte jetzt gedacht, das dieses Tool auch die Firmware aktualisiert.
Bernd Mayer
> Shinji Ikari <shi...@gmx.net> wrote:
>> Guten Tag
>>
>> Marc Haber <mh+usene...@zugschl.us> schrieb
>>
>>> Ich tendiere zu "never touch a running system", wenn das
>>> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>
>> ...und moeglicherweise das selbe Problem wieder neu erleben.
>
> Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
> verhindert dass das Problem neu auftritt.
Hallo,
>> Guten Tag
>>
>> Marc Haber <mh+usene...@zugschl.us> schrieb
>>
>>> Ich tendiere zu "never touch a running system", wenn das
>>> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>
>> ...und moeglicherweise das selbe Problem wieder neu erleben.
>
> Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
> verhindert dass das Problem neu auftritt.
ich hätte jetzt gedacht, das dieses Tool auch die Firmware aktualisiert.
Bernd Mayer
Detlef Wirsing
Jun 13, 2021, 10:30:45 AM6/13/21
to
Shinji Ikari
Jun 13, 2021, 3:09:24 PM6/13/21
to
Guten Tag
Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Ich tendiere zu "never touch a running system", wenn das
>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>...und moeglicherweise das selbe Problem wieder neu erleben.
>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>verhindert dass das Problem neu auftritt.
Wofuer war wohl die anschliessende neuere Firmware gedacht?
Marc Haber <mh+usene...@zugschl.us> schrieb
>>>Ich tendiere zu "never touch a running system", wenn das
>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>...und moeglicherweise das selbe Problem wieder neu erleben.
>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>verhindert dass das Problem neu auftritt.
Oder sollte es sinnvoll sein mit dem PerformanceTool das Problem in
der Firmware zu beheben ohne der Firmware eine neue Nummer zu geben?
Dann würde es ja 2 unterschiedliche Firmware mit dre selben Nummer
geben. Das wäre ein Supportalbtraum.
Marc Haber
Jun 13, 2021, 4:06:53 PM6/13/21
to
Bernd Mayer <beam.b...@knuut.de> wrote:
>Am 13.06.21 um 13:14 schrieb Marc Haber:
>> Shinji Ikari <shi...@gmx.net> wrote:
>>> Guten Tag
>>>
>>> Marc Haber <mh+usene...@zugschl.us> schrieb
>>>
>>>> Ich tendiere zu "never touch a running system", wenn das
>>>> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>
>>> ...und moeglicherweise das selbe Problem wieder neu erleben.
>>
>> Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>> verhindert dass das Problem neu auftritt.
>
>Am 13.06.21 um 13:14 schrieb Marc Haber:
>> Shinji Ikari <shi...@gmx.net> wrote:
>>> Guten Tag
>>>
>>> Marc Haber <mh+usene...@zugschl.us> schrieb
>>>
>>>> Ich tendiere zu "never touch a running system", wenn das
>>>> Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>> die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>> sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>
>>> ...und moeglicherweise das selbe Problem wieder neu erleben.
>>
>> Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>> verhindert dass das Problem neu auftritt.
>
>ich hätte jetzt gedacht, das dieses Tool auch die Firmware aktualisiert.
Das hielt es wohl nicht für notwendig.
Marc Haber
Jun 13, 2021, 4:07:55 PM6/13/21
to
Shinji Ikari <shi...@gmx.net> wrote:
>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>>Ich tendiere zu "never touch a running system", wenn das
>>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>...und moeglicherweise das selbe Problem wieder neu erleben.
>>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>>verhindert dass das Problem neu auftritt.
>
>Wofuer war wohl die anschliessende neuere Firmware gedacht?
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/
>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>>Ich tendiere zu "never touch a running system", wenn das
>>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>...und moeglicherweise das selbe Problem wieder neu erleben.
>>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>>verhindert dass das Problem neu auftritt.
>
>Wofuer war wohl die anschliessende neuere Firmware gedacht?
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q/EXT0CB6Q.enc
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q/EXT42B6Q.enc
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/PERF.EXE
|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/Samsung Performance Restoration DOS v.1.0 Installation guide.pdf
Und die EXT0CB6Q ist auf der SSD schon drauf.
Shinji Ikari
Jun 13, 2021, 5:52:16 PM6/13/21
to
>Shinji Ikari <shi...@gmx.net> wrote:
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>>>Ich tendiere zu "never touch a running system", wenn das
>>>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>>...und moeglicherweise das selbe Problem wieder neu erleben.
>>>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>>>verhindert dass das Problem neu auftritt.
>>
>>Wofuer war wohl die anschliessende neuere Firmware gedacht?
>
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q/EXT0CB6Q.enc
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q/EXT42B6Q.enc
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/PERF.EXE
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/Samsung Performance Restoration DOS v.1.0 Installation guide.pdf
>
>Und die EXT0CB6Q ist auf der SSD schon drauf.
Die _anschliessende_ Firmware war eben "anschliessend" = spaeter.
>>Marc Haber <mh+usene...@zugschl.us> schrieb
>>>>>Ich tendiere zu "never touch a running system", wenn das
>>>>>Performancetool das Firmwareupdate nicht für nötig gehalten hat und
>>>>>die Platte schon 29000 Stunden mit dieser Firmware gelaufen ist wird
>>>>>sie auch bis zu ihrem Tod mit dieser Firmware laufen...
>>>>...und moeglicherweise das selbe Problem wieder neu erleben.
>>>Ich hätte jetzt gedacht dass das "Performance Restoration Tool" auch
>>>verhindert dass das Problem neu auftritt.
>>
>>Wofuer war wohl die anschliessende neuere Firmware gedacht?
>
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT0CB6Q/EXT0CB6Q.enc
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/FW/EXT42B6Q/EXT42B6Q.enc
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/840Perf/PERF.EXE
>|Samsung_SSD840EVO_Performance_Restoration_USB_Bootable/Samsung Performance Restoration DOS v.1.0 Installation guide.pdf
>
>Und die EXT0CB6Q ist auf der SSD schon drauf.
Natuerlich konnte man die im Fix nicht einbauen.
Mit der "Performance Restoration" wurde die Auswirkung/Fehlerbild nur
aufgrund der massiven Auffaelligkeiten nach einiger Betriebszeit in
dem Moment 'behoben' (alle Bloecke einmal ueberarbeitet).
Das war damals keine endgueltige Loesung, sondern ein Pflaster, dass
man mal auf den 'Furunkel' geklebt hat, damit es erst einmal den
Kunden nicht stoerte/nicht auffiel (= Uebergangsloesung bis man das
zugrunde liegende Problem behoben hatte).
Beachte, dass das Fix schon diverse Jahre alt ist (ich glaube
irgendwann um 2014 oder so).
Sollte das Problem bis zur naechsten Firmware wieder auftreten, haette
man die Perf_res neu durchfuehren koennen. Deshalb auch nur die (zu
dem Zeitpunkt) aktuellste Firmware enthalten und aufgebracht wurde.
Spaeter kam dann die neuere Firmware, die das zugrunde liegende
Problem selber anging.
Aber mach, was du willst. Da kann dann auch ein Hersteller nicht mehr
helfen, wenn man die Fehlerbehebungen nicht nutzt.
Takvorian
Jun 14, 2021, 8:56:13 AM6/14/21
to
Marc Haber schrieb:
> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
zum Wunder-Tool zu posten.
> Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
> EXT0DB6Q wäre möglich. Machen oder nicht?
Könnte man davon abhängig machen, welche Vorteile eine neue Version hat.
Die Daten bleiben natürlich erhalten, aber Unfälle kann man nie völlig
ausschließen.
> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
zum Wunder-Tool zu posten.
> Als Firmwareversion meldet sie weiterhin EXT0CB6Q, ein Update auf
> EXT0DB6Q wäre möglich. Machen oder nicht?
Die Daten bleiben natürlich erhalten, aber Unfälle kann man nie völlig
ausschließen.
Bernd Mayer
Jun 14, 2021, 9:09:56 AM6/14/21
to
Am 14.06.21 um 14:56 schrieb Takvorian:
siehe:
https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
Bernd Mayer
> Marc Haber schrieb:
>
>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>
> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
> zum Wunder-Tool zu posten.
Hallo,
>
>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>
> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
> zum Wunder-Tool zu posten.
siehe:
https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
Bernd Mayer
Takvorian
Jun 14, 2021, 9:20:10 AM6/14/21
to
Bernd Mayer schrieb:
> Am 14.06.21 um 14:56 schrieb Takvorian:
>> Marc Haber schrieb:
>>
>>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>>
>> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
>> zum Wunder-Tool zu posten.
> siehe:
> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
> Am 14.06.21 um 14:56 schrieb Takvorian:
>> Marc Haber schrieb:
>>
>>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>>
>> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
>> zum Wunder-Tool zu posten.
> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
Gerald E:scher
Jun 14, 2021, 12:42:54 PM6/14/21
to
Marcel Mueller schrieb am 13/6/2021 10:23:
> Am 13.06.21 um 00:51 schrieb Gerald E:scher:
>>> Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
>>
>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>> nicht direkt durch.
>
> Jein. So ein bisschen haben sie es schon, aber da die VBox Block-Größe
> 1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
> freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
> LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
Kann ich aus UserManual.pdf von VBox 6.1.22 nicht herauslesen. Darin
> Am 13.06.21 um 00:51 schrieb Gerald E:scher:
>>> Filesystem-auf-LVM-in-VM-auf-LVM-in-LUKS-auf-SSD sauber durchkommen.
>>
>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>> nicht direkt durch.
>
> Jein. So ein bisschen haben sie es schon, aber da die VBox Block-Größe
> 1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
> freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
> LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
finde ich nur
"VBoxManage storageattach [...] --discard on"
und das lässt bei einem TRIM im Gast nur ein Diskimage im VDI Format
schrumpfen.
>> VirtualBox kann allerdings ein mitwachsendes Image
>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>
> Das ist /nicht/ zu empfehlen. Dabei werden erhebliche Teile des
> virtuellen Disk-Images neu geschrieben.
per fstrim. Das scheint mir akzeptabel, wenn man das Diskimage nicht
unnötig wachsen lassen möchte.
Bei einer VM mit Xubuntu stoße ich z.B. nach dem Löschen alter Kernel
fstrim händisch an. Eine Partition im Gast ständig TRIMen zu lassen,
mag fragwürdig sein.
> Wünschen würde ich mir, das TRIM im Gast zu Sparse Files im Host führt.
> Dann könnte man von Anfang an mit direkt gemappten Images ohne interne
> Blockverwaltung arbeiten.
Sparse Files gibt. Dies würde virtuelle Maschinen zudem wesentlich
Backup-freundlicher machen.
--
Gerald
Gerald E:scher
Jun 14, 2021, 12:51:27 PM6/14/21
to
ziemlich aufwändig, weil die VM heruntergefahren werden muss.
"VBoxManage storageattach [...] --discard on" für das Diskimage, und es
schrumpft automagisch, wenn der Gast TRIMt.
Bei Windows als Gast weiß ich allerdings nicht, wie man ständiges TRIM
im Gast verhindert, weil dann wird jedesmal geschrumpft, wenn
mindestens 1 MB frei wird.
--
Gerald
Marc Haber
Jun 14, 2021, 1:02:51 PM6/14/21
to
Takvorian
Jun 14, 2021, 3:44:44 PM6/14/21
to
Marc Haber schrieb:
> Takvorian <tak...@gmx.de> wrote:
>>Bernd Mayer schrieb:
>>
>>> Am 14.06.21 um 14:56 schrieb Takvorian:
>>>> Marc Haber schrieb:
>>>>
>>>>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>>>>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>>>>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>>>>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>>>>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>>>>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>>>>
>>>> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
>>>> zum Wunder-Tool zu posten.
>>
>>> siehe:
>>> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
>>
>>Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
>
> Das hilft aber nur bei GENAU dieser SSD.
Argh.
> Takvorian <tak...@gmx.de> wrote:
>>Bernd Mayer schrieb:
>>
>>> Am 14.06.21 um 14:56 schrieb Takvorian:
>>>> Marc Haber schrieb:
>>>>
>>>>> Nach knapp zwei Stunden ist das Tool durch, die Daten blieben
>>>>> erhalten, das OS ließ sich anstandslos booten und die SSD 840 EVO
>>>>> schreibt nun mit 494 MB/s und liest mit knapp 450 MB/s. Sie ist damit
>>>>> im Schreiben einen runden Faktor 20 schneller als vor der Behandlung
>>>>> mit dem Tool und lässt sogar die fast ungebrauchte und modernere
>>>>> Vergleichs-SSD 850 EVO 250 GB aus dem anderen Rechner hinter sich.
>>>>
>>>> Dann wäre es schön, den Leuten mit gleichen Problemen einen Download-Link
>>>> zum Wunder-Tool zu posten.
>>
>>> siehe:
>>> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
>>
>>Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
>
> Das hilft aber nur bei GENAU dieser SSD.
Shinji Ikari
Jun 14, 2021, 3:59:20 PM6/14/21
to
>>> siehe:
>>> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
>>Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
>Das hilft aber nur bei GENAU dieser SSD.
SSD Type.
>>> https://www.samsung.com/de/support/model/MZ-7TE250BW/#downloads
>>Danke, sollte mir sowas mal passieren, werd ich's damit versuchen.
>Das hilft aber nur bei GENAU dieser SSD.
Das problemn betrifft alle damaligen Samsung 840 EVO.
Marcel Mueller
Jun 15, 2021, 2:55:18 AM6/15/21
to
Am 14.06.21 um 18:42 schrieb Gerald E:scher:
1MB Stripes getrimmt sind, dieser im VDI-Image freigegeben wird. Und
auch das geschieht nur durch /verschieben/ von 1MB Blöcken vom Ende des
VDI-Files in die entstehenden Lücken - also mit erhebliche Write
Amplification.
Es ist durchaus vernünftig anzunehmen, dass die meisten SSD-Controller
eine kleiner Write-Amplification erreichen, wenn gar nicht getrimmt wird.
Hier ist das ganz gut zusammengefasst:
https://www.virtualbox.org/ticket/11092
Fazit: Discard ist in der aktuellen Implementierung kaum brauchbar.
Es ergibt eigentlich nur Sinn, wenn der physikalische Storage auf eine
normalen HDD liegt. Dann wird wenigstens Platz auf dem Host wieder frei
gegeben. Aber wer betreibt schon einen VM-Server auf einer Drehplatte?
Außer Retrofeeling mit 486-er Geschwindigkeit während sich 5 VMs um die
eine Platte prügeln, fällt mir da kein Grund ein. (OK, wenn ein SAN mit
100 Spindeln dran hängt, reicht der Durchsatz auch dicke, aber einzelne
Platten sind dafür der letzte Mist.)
>>> VirtualBox kann allerdings ein mitwachsendes Image
>>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>>
>> Das ist /nicht/ zu empfehlen. Dabei werden erhebliche Teile des
>> virtuellen Disk-Images neu geschrieben.
>
> Bei Debian und Ubuntu geschieht ein TRIM standardmäßig einmal pro Woche
> per fstrim. Das scheint mir akzeptabel, wenn man das Diskimage nicht
> unnötig wachsen lassen möchte.
Dabei würde VBox bei aktivierter discard-Option exakt so viele Daten
schreiben, wie vollständige 1MB-Blöcke getrimmt wurden. Für jeden
vollständig getrimmten 1MB Block wird ein anderer 1MB Block vom Ende des
VDI-Files in die entstandene Lücke verschoben.
Man kann nur hoffen, dass das selten passiert, wenn das VDI Image auf
einer SSD liegt.
> Bei einer VM mit Xubuntu stoße ich z.B. nach dem Löschen alter Kernel
> fstrim händisch an. Eine Partition im Gast ständig TRIMen zu lassen,
> mag fragwürdig sein.
Bei der derzeitigen VBox-Implementierung: full ack.
Da kann man froh sein, wenn Trim nur selten funktioniert.
>> Wünschen würde ich mir, das TRIM im Gast zu Sparse Files im Host führt.
>> Dann könnte man von Anfang an mit direkt gemappten Images ohne interne
>> Blockverwaltung arbeiten.
>
> Verstehe ich auch nicht, dass es für VBox kein Diskimage-Format mit
> Sparse Files gibt. Dies würde virtuelle Maschinen zudem wesentlich
> Backup-freundlicher machen.
Full ack. Die Anforderung liegt schon lange auf dem Tisch. Siehe auch
ober Link. Fixed Size mit Sparse File, würde den kompletten
Verwaltungsaufwand für die virtuelle Disk auf das Host Dateisystem
deligieren.
Der Haken an der Sache sind die VM-Snapshots. Die müssen dann komplett
anders implementiert werden. Man bräuchte ein weiteres Sparse file in
voller Größe, wo alle unveränderten Blöcke inexistent sind.
Da ist dann auch schon wieder Schluss mit der Backupfreundlichkeit.
Da würde man sich dann als nächstes Wünschen, dass die
Snapshot-Funktionen vom Host Dateisystem eingesetzt würden. Aber die
sind natürlich viel zu inhomogen verfügbar.
Selbst die Sparse-Files funktionieren auch nach 30 Jahren immer noch in
mindestens jeder zweiten Backup-Software nicht.
Marcel
>>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>>> nicht direkt durch.
>>
>> Jein. So ein bisschen haben sie es schon, aber da die VBox Block-Größe
>> 1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
>> freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
>> LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
>
> Kann ich aus UserManual.pdf von VBox 6.1.22 nicht herauslesen. Darin
> finde ich nur
> "VBoxManage storageattach [...] --discard on"
> und das lässt bei einem TRIM im Gast nur ein Diskimage im VDI Format
> schrumpfen.
Ja, und irgendwo im Kleingedruckten stand, dass wenn alle Blöcke eines
>>> nicht direkt durch.
>>
>> Jein. So ein bisschen haben sie es schon, aber da die VBox Block-Größe
>> 1MB ist (und nicht 4k wie bei der SSD) kann ein Block im VDI ohnehin nur
>> freigegeben werden, wenn kein einziges Byte in einem 1MB Block von
>> LBA-Adressen mehr belegt ist. Und das ist sehr unwahrscheinlich.
>
> Kann ich aus UserManual.pdf von VBox 6.1.22 nicht herauslesen. Darin
> finde ich nur
> "VBoxManage storageattach [...] --discard on"
> und das lässt bei einem TRIM im Gast nur ein Diskimage im VDI Format
> schrumpfen.
1MB Stripes getrimmt sind, dieser im VDI-Image freigegeben wird. Und
auch das geschieht nur durch /verschieben/ von 1MB Blöcken vom Ende des
VDI-Files in die entstehenden Lücken - also mit erhebliche Write
Amplification.
Es ist durchaus vernünftig anzunehmen, dass die meisten SSD-Controller
eine kleiner Write-Amplification erreichen, wenn gar nicht getrimmt wird.
Hier ist das ganz gut zusammengefasst:
https://www.virtualbox.org/ticket/11092
Fazit: Discard ist in der aktuellen Implementierung kaum brauchbar.
Es ergibt eigentlich nur Sinn, wenn der physikalische Storage auf eine
normalen HDD liegt. Dann wird wenigstens Platz auf dem Host wieder frei
gegeben. Aber wer betreibt schon einen VM-Server auf einer Drehplatte?
Außer Retrofeeling mit 486-er Geschwindigkeit während sich 5 VMs um die
eine Platte prügeln, fällt mir da kein Grund ein. (OK, wenn ein SAN mit
100 Spindeln dran hängt, reicht der Durchsatz auch dicke, aber einzelne
Platten sind dafür der letzte Mist.)
>>> VirtualBox kann allerdings ein mitwachsendes Image
>>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>>
>> Das ist /nicht/ zu empfehlen. Dabei werden erhebliche Teile des
>> virtuellen Disk-Images neu geschrieben.
>
> Bei Debian und Ubuntu geschieht ein TRIM standardmäßig einmal pro Woche
> per fstrim. Das scheint mir akzeptabel, wenn man das Diskimage nicht
> unnötig wachsen lassen möchte.
schreiben, wie vollständige 1MB-Blöcke getrimmt wurden. Für jeden
vollständig getrimmten 1MB Block wird ein anderer 1MB Block vom Ende des
VDI-Files in die entstandene Lücke verschoben.
Man kann nur hoffen, dass das selten passiert, wenn das VDI Image auf
einer SSD liegt.
> Bei einer VM mit Xubuntu stoße ich z.B. nach dem Löschen alter Kernel
> fstrim händisch an. Eine Partition im Gast ständig TRIMen zu lassen,
> mag fragwürdig sein.
Da kann man froh sein, wenn Trim nur selten funktioniert.
>> Wünschen würde ich mir, das TRIM im Gast zu Sparse Files im Host führt.
>> Dann könnte man von Anfang an mit direkt gemappten Images ohne interne
>> Blockverwaltung arbeiten.
>
> Verstehe ich auch nicht, dass es für VBox kein Diskimage-Format mit
> Sparse Files gibt. Dies würde virtuelle Maschinen zudem wesentlich
> Backup-freundlicher machen.
ober Link. Fixed Size mit Sparse File, würde den kompletten
Verwaltungsaufwand für die virtuelle Disk auf das Host Dateisystem
deligieren.
Der Haken an der Sache sind die VM-Snapshots. Die müssen dann komplett
anders implementiert werden. Man bräuchte ein weiteres Sparse file in
voller Größe, wo alle unveränderten Blöcke inexistent sind.
Da ist dann auch schon wieder Schluss mit der Backupfreundlichkeit.
Da würde man sich dann als nächstes Wünschen, dass die
Snapshot-Funktionen vom Host Dateisystem eingesetzt würden. Aber die
sind natürlich viel zu inhomogen verfügbar.
Selbst die Sparse-Files funktionieren auch nach 30 Jahren immer noch in
mindestens jeder zweiten Backup-Software nicht.
Marcel
Marc Haber
Jun 15, 2021, 3:35:01 AM6/15/21
to
"Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>Marc Haber schrieb am 12/6/2021 16:57:
>
>> "Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>>>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
>>
>> Dem Vernehmen nach hat man das nie gebraucht, wenn das Betriebssystem
>> das mit übernimmt (was Linux schon länger im Default tut als ich diese
>> SSD besitze),
>
>Jedenfalls bei Ubuntu per fstrim.timer. Stammt aber eh von Debian:
>https://packages.debian.org/buster/arm64/util-linux/filelist
Was hat das mit meiner oberen Aussage zu tun?
>Marc Haber schrieb am 12/6/2021 16:57:
>
>> "Gerald E:scher" <Spa...@fahr-zur-Hoelle.org> wrote:
>>>Werden die einzelnen Partitionen regelmäßig mit fstrim geTRIMt?
>>
>> Dem Vernehmen nach hat man das nie gebraucht, wenn das Betriebssystem
>> das mit übernimmt (was Linux schon länger im Default tut als ich diese
>> SSD besitze),
>
>Jedenfalls bei Ubuntu per fstrim.timer. Stammt aber eh von Debian:
>https://packages.debian.org/buster/arm64/util-linux/filelist
>> und bei modernen Platten gar nicht, wobei man sich
>> darüber streiten kann ob meine SSD 840 EVO schon als "modern" zählt.
>
>Bei voller Platte, wobei eine unbenutzte nicht geTRIMte Partition voll
>mit belegten Blöcken sein kann, und zu wenig Overprovisioning muss
>der Controller der SSD vor dem Schreiben eines Blockes diesen erst
>löschen und das verlangsamt massiv.
ein aktuelles Dokument, in dem das Gegenteil steht? Die meiste
Dokumentation, die ich zu dem Thema gefunden habe, ist aus der ersten
Hälfte der Zehnerjahre, SSD sind seitdem um einen Faktor 10 im Preis
gefallen und haben sich auch technisch weiterentwickelt.
Marc Haber
Jun 15, 2021, 3:36:01 AM6/15/21
to
Marcel Mueller <news.5...@spamgourmet.org> wrote:
>Bei der derzeitigen VBox-Implementierung: full ack.
Praktischerweise benutzt der OP KVM, qemu und libvirt.
>Bei der derzeitigen VBox-Implementierung: full ack.
Marc Haber
Jun 15, 2021, 7:41:53 AM6/15/21
to
Frank Möller
Jun 16, 2021, 6:55:05 AM6/16/21
to
Gerald E:scher:
> Das Ganze ist ziemlich aufwändig, weil die VM heruntergefahren werden
> muss.
Das Ganze bedeutet für mich keinen sonderlichen Zusatzaufwand. Wenn die VM
läuft, kann man darin auch mal SDelete laufen lassen; und wenn sie nicht
läuft, läßt sich nebenbei Compact und ein Backup ausführen. Ich bin nur
Privatanwender, kein Rechenzentrum.
> "VBoxManage storageattach [...] --discard on" für das Diskimage, und es
> schrumpft automagisch, wenn der Gast TRIMt.
"Syntax error: Storage controller name not specified"
Keine Ahnung, welchen Namen ich da angeben müßte.
_Das_ ist aber auch nicht so wichtig. 1. habe ich auch VMs mit älteren
Windosen, die nicht selber trimmen (2K, XP), 2. kann ich sehr wohl damit
leben, die VDI-Größe nur gelegentlich manuell bei Bedarf zu schrumpfen, z.
B. vor einem neu zu ziehenden Backup.
> Bei Windows als Gast weiß ich allerdings nicht, wie man ständiges TRIM
> im Gast verhindert, weil dann wird jedesmal geschrumpft, wenn
> mindestens 1 MB frei wird.
Das muß für mich nicht sein, zumal dabei vermutlich der Wear Leveling Count
der Host-SSD unnötig schnell steigen würde, was er so bislang nicht tut.
--
> Frank Möller schrieb am 13/6/2021 10:16:
>> Gerald E:scher:
>>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>>> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
>>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>>> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
>> Das gelegentliche Verkleinern des Images kann man auch nach Gusto manuell
>> anstoßen (unter Windows):
>> "<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
>> Innerhalb einer Windows-VM kann man auch _vorher_ ab und zu mal
>> <https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete>
> sdelete muss man *vor* dem Kompatieren laufen lassen.
Sicher. Deswegen schrieb ich das ja auch so.
>> Gerald E:scher:
>>> Jedenfalls bei VirtualBox kommen vom Gast zur SSD des Hosts TRIM-Befehle
>>> nicht direkt durch. VirtualBox kann allerdings ein mitwachsendes Image
>>> bei einem TRIM des Gastes wieder verkleinern und dann kann der
>>> Dateisystemtreiber des Hosts die SSD entsprechend TRIMen.
>>> Ersteres funktioniert auch bei einer VM auf einer rotierenden Platte.
>> Das gelegentliche Verkleinern des Images kann man auch nach Gusto manuell
>> anstoßen (unter Windows):
>> "<LW:\Pfad>\VBoxManage.exe" modifymedium "<LW:\Pfad>\<Name>.vdi" --compact
>> Innerhalb einer Windows-VM kann man auch _vorher_ ab und zu mal
>> <https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete>
> sdelete muss man *vor* dem Kompatieren laufen lassen.
> Das Ganze ist ziemlich aufwändig, weil die VM heruntergefahren werden
> muss.
läuft, kann man darin auch mal SDelete laufen lassen; und wenn sie nicht
läuft, läßt sich nebenbei Compact und ein Backup ausführen. Ich bin nur
Privatanwender, kein Rechenzentrum.
> "VBoxManage storageattach [...] --discard on" für das Diskimage, und es
> schrumpft automagisch, wenn der Gast TRIMt.
Keine Ahnung, welchen Namen ich da angeben müßte.
_Das_ ist aber auch nicht so wichtig. 1. habe ich auch VMs mit älteren
Windosen, die nicht selber trimmen (2K, XP), 2. kann ich sehr wohl damit
leben, die VDI-Größe nur gelegentlich manuell bei Bedarf zu schrumpfen, z.
B. vor einem neu zu ziehenden Backup.
> Bei Windows als Gast weiß ich allerdings nicht, wie man ständiges TRIM
> im Gast verhindert, weil dann wird jedesmal geschrumpft, wenn
> mindestens 1 MB frei wird.
der Host-SSD unnötig schnell steigen würde, was er so bislang nicht tut.
--
Frank Möller
Jun 16, 2021, 6:55:05 AM6/16/21
to
Bernd Mayer:
Keine Ahnung, müßten wohl die Linuxer eruieren.
--
--
Marc Haber
Jun 17, 2021, 3:05:33 AM6/17/21
to
Shinji Ikari <shi...@gmx.net> wrote:
>Spaeter kam dann die neuere Firmware, die das zugrunde liegende
>Problem selber anging.
>
>Aber mach, was du willst. Da kann dann auch ein Hersteller nicht mehr
>helfen, wenn man die Fehlerbehebungen nicht nutzt.
Ich hab's dann gestern mal gemacht. Schön war das nicht, unetbootin
>Spaeter kam dann die neuere Firmware, die das zugrunde liegende
>Problem selber anging.
>
>Aber mach, was du willst. Da kann dann auch ein Hersteller nicht mehr
>helfen, wenn man die Fehlerbehebungen nicht nutzt.
ist in Debian nicht mehr enthalten und ich habe das vom Upstream
bereitgehaltene Binary benutzt. Ich fühle mich schmutzig.
Aber meine Daten sind noch da.
0 new messages