SSD Haltbarkeit | SMART-Daten | Schreibaktivität

[heisenberg]

Hallo,

ich habe hier eine NVMe-SSD und zwar diese hier:

Code: Alles auswählen

 smartctl -i /dev/nvme0
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.13.19-6-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 970 EVO Plus 250GB
Serial Number:                      S4EUNF0M978441N
Firmware Version:                   2B2QEXM7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 250,059,350,016 [250 GB]
Unallocated NVM Capacity:           0
Controller ID:                      4
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          250,059,350,016 [250 GB]
Namespace 1 Utilization:            119,649,845,248 [119 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 5991b3e93d
Local Time is:                      Wed Apr 19 22:45:31 2023 CEST

Die gibt mir bei smartctl -A /dev/nvmen0n1 das aus:

Code: Alles auswählen

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        38 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    2,728,665 [1.39 TB]
Data Units Written:                 7,001,563 [3.58 TB]
Host Read Commands:                 71,358,703
Host Write Commands:                124,207,364
Controller Busy Time:               544
Power Cycles:                       6
Power On Hours:                     405
Unsafe Shutdowns:                   0
Media and Data Integrity Errors:    0
Error Information Log Entries:      1
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               38 Celsius
Temperature Sensor 2:               39 Celsius

Was mich dabei wundert ist zum einen dass der OUTPUT so ganz anders aussieht, wie bei normalen SATA-SSDs oder Festplatten. Ist das eine Besonderheit von NVMe oder macht bei SSDs sowieso jeder, was er will?

Das zweite ist der Wert "DATA Units Written". Wenn ich da die Grösse eines Data Units berechne anhand der TB-Größe, die auch noch steht ist das also ca. 562.269 Bytes. Was ist denn das für eine komische Größe? Ist das Hersteller-Willkür?

Der Power_On_Hours Wert ist auch völlig falsch.

Ansonsten habe ich noch zwei weitere SATA-SSDs (China-Billigware) in dem System, auf dem das OS ist (Software-RAID) und zwar dieses Modell:

Code: Alles auswählen

smartctl -i /dev/sde
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.13.19-6-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SSD 64GB
Serial Number:    NB202029163049
Firmware Version: S0221A0
User Capacity:    64,023,257,088 bytes [64.0 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      mSATA
TRIM Command:     Available, deterministic, zeroed
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Apr 19 22:50:40 2023 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Hier sagt mir smartctl -A:

Code: Alles auswählen

=== START OF READ SMART DATA SECTION ===
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
  1 Raw_Read_Error_Rate     0x0032   100   100   050    Old_age   Always       -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   050    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   050    Old_age   Always       -       25541
 12 Power_Cycle_Count       0x0032   100   100   050    Old_age   Always       -       42
160 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       0
161 Unknown_Attribute       0x0033   100   100   050    Pre-fail  Always       -       100
163 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       7
164 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       319781
165 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       820
166 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       283
167 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       363
168 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       7000
169 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       95
175 Program_Fail_Count_Chip 0x0032   100   100   050    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   050    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0032   100   100   050    Old_age   Always       -       0
178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   050    Old_age   Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   050    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   050    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       31
194 Temperature_Celsius     0x0022   100   100   050    Old_age   Always       -       36
195 Hardware_ECC_Recovered  0x0032   100   100   050    Old_age   Always       -       8717
196 Reallocated_Event_Count 0x0032   100   100   050    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   050    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0032   100   100   050    Old_age   Always       -       0
232 Available_Reservd_Space 0x0032   100   100   050    Old_age   Always       -       100
241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       150584
242 Total_LBAs_Read         0x0030   100   100   050    Old_age   Offline      -       81681
245 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       246761

Da steht Total_LBAs_Written 150584. Bei einer logischen Sektorgröße von 512 Bytes sind das ~ 73 MB. Der Witz ist gut! Wie kann die SSD bei 11 GB belegtem Speicher nur mit 73 MB beschrieben worden sein?

[cosinus]

Vllt misst er nicht in LBAs sondern in einer anderen Einheit - nur smartctl weiß das nicht?
Wer weiß ob da die Smartdaten der China-SSD auch wirklich verlässlich sind?

Der Output bei meiner NVMe-SSD sieht jedenfalls ähnlich aus wie bei dir:

Code: Alles auswählen

# smartctl -x /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-7-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       SAMSUNG MZVLB256HBHQ-000L7
Serial Number:                      S4ELNF1M909266
Firmware Version:                   4M2QEXH7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 256.060.514.304 [256 GB]
Unallocated NVM Capacity:           0
Controller ID:                      4
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          256.060.514.304 [256 GB]
Namespace 1 Utilization:            106.295.144.448 [106 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 8991b98623
Local Time is:                      Wed Apr 19 23:35:58 2023 CEST
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x03):         S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     84 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     8.00W       -        -    0  0  0  0        0       0
 1 +     6.30W       -        -    1  1  1  1        0       0
 2 +     3.50W       -        -    2  2  2  2        0       0
 3 -   0.0760W       -        -    3  3  3  3      210    1200
 4 -   0.0050W       -        -    4  4  4  4     2000    8000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        39 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    4.056.837 [2,07 TB]
Data Units Written:                 3.954.479 [2,02 TB]
Host Read Commands:                 54.142.599
Host Write Commands:                51.964.544
Controller Busy Time:               249
Power Cycles:                       420
Power On Hours:                     754
Unsafe Shutdowns:                   34
Media and Data Integrity Errors:    0
Error Information Log Entries:      865
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               39 Celsius
Temperature Sensor 2:               39 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS
  0        865     0  0x4013  0x4004      -            0     0     -

[heisenberg]

Der Byte-Wert einer Data-Unit scheint aber bei Dir identisch zu sein. Kann man mangels exakter Werte aber nicht verifizieren.

[cosinus]

Der Byte-Wert einer Data-Unit scheint aber bei Dir identisch zu sein. Kann man mangels exakter Werte aber nicht verifizieren.

Bei den NVMe-SSDs kommt das doch genau hin...?!

Deine SSD

Code: Alles auswählen

Data Units Read:                    2,728,665 [1.39 TB]
Data Units Written:                 7,001,563 [3.58 TB]

2.728.665 * 512 = 1,397 * 10⁹
7.001.563 * 512 = 3,585 * 10⁹

Meine SSD

Code: Alles auswählen

Data Units Read:                    4.056.837 [2,07 TB]
Data Units Written:                 3.954.479 [2,02 TB]

4.056.837 * 512 = 2,07 *10⁹
3.954.479 * 512 = 2,02 *10⁹

Was deine Billig-SSD angeht:

Code: Alles auswählen

241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       150584
242 Total_LBAs_Read         0x0030   100   100   050    Old_age   Offline      -       81681

Sieht aus als ob die nicht LBA als Einheit nimmt (also 512-Blöcke) sondern GB - du also den Wert mit 10⁹ multiplizieren musst. Komtm das denn hin, 150 TB geschriebene Daten?

[heisenberg]

Bei den NVMe-SSDs kommt das doch genau hin...?!

Ups. Leichter Knick in meiner Rechenoptik...

Sieht aus als ob die nicht LBA als Einheit nimmt (also 512-Blöcke) sondern GB - du also den Wert mit 10⁹ multiplizieren musst. Komtm das denn hin, 150 TB geschriebene Daten?

150 TB: Mit Sicherheit nicht. Das ist nur eine OS-SSD. Da werden maximal Logs geschrieben. Vielleicht 150 GB, dann wäre MB die Einheit. Das kann ich ja mal durch einen gezielten Schreibvorgang testen.

[cosinus]

Ähh nun hab ich mich doch vertan
10⁹ Byte ist ein GB, nicht ein TB (=10¹² Byte). Hinkommen würde die Rechnung, wenn eine DATA UNIT aus 512.000 Byte besteht, also Tausend Sektoren...

[heisenberg]

Ich habe bei den China-SSDs mal nachgemessen:

Code: Alles auswählen

smartctl -A /dev/sdf | grep -i written
dd </dev/zero bs=1M count=1000 >test.raw
sync
rm test.raw
sync
smartctl -A /dev/sdf| grep -i written

# Ausgabe #1

241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       152299
1000+0 Datensätze ein
1000+0 Datensätze aus
241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       152331

Ich habe mehrere Testläufe gemacht mit gleichem Ergebnis. Der Zähler erhöht sich immer um 31-32. Ich habe auch mal den 10-fachen Wert geschrieben. Die Zahl erhöht sich entsprechend (313 bei 10000 MB). D. h. die SSD optimiert das schreiben von identischen Daten (Null) also nicht weg.

Die Einheitengröße von Total_LBAs_Written ist also ca. 32 MB. D. h. der bisherige Schreibdatenverbrauch auf den SSDs ist also ca. 4,5 TB. Der Wert scheint mir plausibel. Wenn ich also als Vergleichswert mal 1 DPWD/5 Jahre ansetze, dann wären das bei der Speicherkapazität der SSD (64 GB) ~120 TB, die man darauf schreiben kann. Aber die billigen China-SSDs haben nie im Leben 1 DPWD (also zumindest nicht garantiert vom Hersteller bzw. als Auslegungsspezifikation).

Im Endeffekt ist es also doch besser auf für das OS eine größere SSD zu nehmen, weil die Kapazität auch die Langlebigkeit bestimmt. Und ob man jetzt eine 64 GB oder eine 256 GB nimmt, dass macht preislich im Vergleich zum restlichen Server jetzt eher fast gar nix aus.

Btw. das ist das Script, dass die Daten via smartctl extrahiert:

Code: Alles auswählen

#!/bin/bash

declare -rx PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
declare -rx LC_ALL=C

get_disks() {
         lsblk -J | jq -j -r '.blockdevices[] | select(.type=="disk") | .name + " "'
}

get_smart_info_json() {

        local dev="$1"
        smartctl -i $dev -j
}

get_smart_data_json() {

        local dev="$1"
        smartctl -A $dev -j
}

device_is_ssd() {

        local disk_json="$1"
        local disk="$2"

        [  "$(jq -r .rotation_rate <<<"$disk_json")" == "0"    ] && return 0
        [[ "$(jq -r .model_name  <<<"$disk_json")" =~ "SSD"   ]] && return 0
        [[ "$(jq -r .model_family  <<<"$disk_json")" =~ "SSD" ]] && return 0
        return 1
}

main() {

        local disk_info_json
        local disk_data_json
        local total_lbas_written
        local bytes_written
        local logical_block_size
        local device_id
        local last_update
        local last_bytes_written
        local bytes_second_text
        local bytes_second
        local bytes_second_year

        for disk in $(get_disks);do
                disk_info_json="$(get_smart_info_json /dev/$disk)"
                if device_is_ssd "$disk_info_json" "$disk"; then

                        logical_block_size=$(jq '. | .logical_block_size ' <<<"$disk_info_json")
                        disk_data_json="$(get_smart_data_json /dev/$disk)"

                        device_model_name="$(jq -r '.model_name' <<<"$disk_info_json")"
                        device_serial="$(jq -r '.serial_number' <<<"$disk_info_json")"

                        # manually set logical block size to 32 MB for GoldenFir 64 GB SATA SSD
                        if [[ $device_model_name == "SSD 64GB" ]] && [[ $device_serial =~ ^NB2 ]] ; then
                                logical_block_size="33554432"
                        fi

                        # manually set logical block size to 562.269 Bytes for Samsung SSD 970 EVO Plus 250GB
                        # and use individual extraction command
                        if [[ $device_model_name == "Samsung SSD 970 EVO Plus 250GB" ]]; then

                                total_lbas_written="$(jq '. | .nvme_smart_health_information_log.data_units_written' <<<"$disk_data_json")"
                                logical_block_size=562269

                        else
                                total_lbas_written="$(jq '.ata_smart_attributes.table[]|select(.name=="Total_LBAs_Written") | .raw.value' <<<"$disk_data_json")"

                        fi

                        bytes_written=$(( $logical_block_size * $total_lbas_written ))

                        device_id="$(jq '"type: "+ .model_name + " serial: " + .serial_number' <<<"$disk_info_json")"
                        now=$(date +%s)
                        if [ -f /dev/shm/${disk}_last_value ] ; then
                                last_update=
                                last_bytes_written=
                                bytes_second_text=""
                                . /dev/shm/${disk}_last_value
                                ((diff_time=$now - $last_update))
                                ((diff_bytes=$bytes_written - $last_bytes_written))
                                ((bytes_second=$diff_bytes/$diff_time))
                                ((bytes_second_year=$bytes_second*31536000))
                                bytes_second_text="|bytes_written_per_second=$bytes_second|bytes_written_per_second_scaled_year=$bytes_second_year"
                        fi
                        echo -e "last_update=$now\nlast_bytes_written=$bytes_written" >/dev/shm/${disk}_last_value
                        echo "P ssd_write_$disk bytes_written=$bytes_written$bytes_second_text written data for $device_id"

                fi
        done

}

main

[heisenberg]

Ich verlinke hier gerade nochmal den Beitrag zum Thema preisgünstige Server-SSDs im ServerSupportForum:

https://serversupportforum.de/threads/p ... aet.60799/

Und ansonsten nochmal ein paar Beispielgrafiken, die die tatsächliche Schreibaktivität von verschiedenen Nutzungsarten von SSDs visualisieren:

1. Das sind die Billig-SSDs die als ProxmoxVE OS-Disks eingesetzt werden
   
   
   .
2. Das ist eine einzelne Mariadb-Datenbank mit dedizierter SSD
   
   
   .
3. Das ist eine Daten-SSD aus einem RAID-10 Verbund (4 SSDs) eines derzeit noch nicht sonderlich stark ausgelasteten VMHosts. Da geht schon wesentlich mehr.
   
   

Nachtrag

Bzgl. des Datenformates bei SSDs scheint bei SATA-SSDs grundsätzlich das normale SATA-Format Anwendung zu finden wie bei Festplatten auch. Bei NVMe wird da wohl das NVMe-Log des Gerätes ausgelesen, was strukturell etwas anders als erstgenanntes aufgebaut ist, aber vermutlich für alle NVMe-Typen ähnlich sein wird. Das NVMe-Log kann man auch direkt mit nvme-cli auslesen.