VM Raw Disk, kein Backup oder Konvertierung auf QEMU möglich

[Buddinski88]

Hallo zusammen,

ich betreibe aktuell drei PVE nodes (8.0.4 mit aktuellen Updates, keine SubscriptioN) und auf einem liegt die VM200 (docker-prod) basierend auf Ubuntu 22.04 LTS.
Die VM läuft soweit reibungslos, aber ich habe ein bzw. zwei Probleme.

Es klappt nicht, dass ich auf TrueNAS (SMB/CFIS) ein Backup der VM mache. Es kommt immer folgende Fehlermeldung. Das immer bei ~ 16,7-9 GB und das finde ich schon recht verdächtig:

INFO: Starting Backup of VM 200 (qemu)
INFO: Backup started at 2023-11-18 04:02:01
INFO: status = running
INFO: VM Name: docker-prod
INFO: include disk 'scsi0' 'data-disk:vm-200-disk-0' 64G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive '/mnt/pve/backup-truenas/dump/vzdump-qemu-200-2023_11_18-04_02_01.vma.zst'
INFO: started backup task 'c500f276-c2c7-488e-8fd4-4ffe7964b923'
INFO: resuming VM again
INFO:   3% (2.2 GiB of 64.0 GiB) in 3s, read: 763.7 MiB/s, write: 330.8 MiB/s
INFO:   4% (2.8 GiB of 64.0 GiB) in 6s, read: 203.0 MiB/s, write: 200.1 MiB/s
INFO:   5% (3.5 GiB of 64.0 GiB) in 9s, read: 235.6 MiB/s, write: 232.0 MiB/s
INFO:   6% (4.2 GiB of 64.0 GiB) in 12s, read: 244.1 MiB/s, write: 238.0 MiB/s
INFO:   7% (4.9 GiB of 64.0 GiB) in 15s, read: 234.4 MiB/s, write: 231.7 MiB/s
INFO:   8% (5.4 GiB of 64.0 GiB) in 18s, read: 170.4 MiB/s, write: 164.9 MiB/s
INFO:   9% (6.0 GiB of 64.0 GiB) in 21s, read: 188.5 MiB/s, write: 187.2 MiB/s
INFO:  10% (6.6 GiB of 64.0 GiB) in 24s, read: 203.0 MiB/s, write: 202.4 MiB/s
INFO:  11% (7.1 GiB of 64.0 GiB) in 27s, read: 181.2 MiB/s, write: 181.1 MiB/s
INFO:  12% (7.8 GiB of 64.0 GiB) in 31s, read: 177.6 MiB/s, write: 176.6 MiB/s
INFO:  13% (8.5 GiB of 64.0 GiB) in 34s, read: 229.6 MiB/s, write: 220.5 MiB/s
INFO:  14% (9.0 GiB of 64.0 GiB) in 37s, read: 198.2 MiB/s, write: 195.2 MiB/s
INFO:  15% (9.6 GiB of 64.0 GiB) in 40s, read: 191.7 MiB/s, write: 191.4 MiB/s
INFO:  16% (10.3 GiB of 64.0 GiB) in 43s, read: 227.6 MiB/s, write: 224.0 MiB/s
INFO:  17% (10.9 GiB of 64.0 GiB) in 46s, read: 211.5 MiB/s, write: 210.8 MiB/s
INFO:  18% (11.8 GiB of 64.0 GiB) in 49s, read: 316.6 MiB/s, write: 206.0 MiB/s
INFO:  19% (12.5 GiB of 64.0 GiB) in 52s, read: 238.0 MiB/s, write: 233.5 MiB/s
INFO:  20% (13.3 GiB of 64.0 GiB) in 55s, read: 257.4 MiB/s, write: 256.2 MiB/s
INFO:  21% (13.9 GiB of 64.0 GiB) in 58s, read: 228.4 MiB/s, write: 224.8 MiB/s
INFO:  22% (14.6 GiB of 64.0 GiB) in 1m 1s, read: 239.2 MiB/s, write: 233.5 MiB/s
INFO:  23% (15.3 GiB of 64.0 GiB) in 1m 4s, read: 220.6 MiB/s, write: 219.2 MiB/s
INFO:  24% (15.9 GiB of 64.0 GiB) in 1m 7s, read: 204.7 MiB/s, write: 203.9 MiB/s
INFO:  25% (16.5 GiB of 64.0 GiB) in 1m 10s, read: 222.3 MiB/s, write: 222.1 MiB/s
INFO:  26% (16.9 GiB of 64.0 GiB) in 1m 13s, read: 127.9 MiB/s, write: 127.8 MiB/s
ERROR: job failed with err -5 - Input/output error
INFO: aborting backup job
INFO: resuming VM again
ERROR: Backup of VM 200 failed - job failed with err -5 - Input/output error
INFO: Failed at 2023-11-18 04:03:39
INFO: Backup job finished with errors
TASK ERROR: job errors

Nun habe ich etwas recherchiert, aber leider finde ich keine Anleitung wie ich hier vorgehen kann um z.B. die Festplatte zu prüfen.

Infos:

• Es liegen noch eine andere VM sowie zwei Container auf dem Node. Beide lassen sich problemlos sichern.
• Die Festplatten liegen auf einem ZFS Share "data-disk". Das wiederum ist jeweils eine 1TB SSD innerhalb der NUCs.

Zweites Problem: Ich kann die VM auch nicht replizieren. Dazu kommt immer folgender Fehler:

2023-11-18 14:07:02 200-0: start replication job
2023-11-18 14:07:02 200-0: guest => VM 200, running => 2432148
2023-11-18 14:07:02 200-0: volumes => data-disk:vm-200-disk-0
2023-11-18 14:07:03 200-0: create snapshot '__replicate_200-0_1700312822__' on data-disk:vm-200-disk-0
2023-11-18 14:07:03 200-0: using secure transmission, rate limit: none
2023-11-18 14:07:03 200-0: full sync 'data-disk:vm-200-disk-0' (__replicate_200-0_1700312822__)
2023-11-18 14:07:04 200-0: full send of data-disk/vm-200-disk-0@__replicate_200-0_1700312822__ estimated size is 62.6G
2023-11-18 14:07:04 200-0: total estimated size is 62.6G
2023-11-18 14:07:05 200-0: TIME        SENT   SNAPSHOT data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
2023-11-18 14:07:05 200-0: 14:07:05   80.4M   data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
2023-11-18 14:07:06 200-0: 14:07:06    192M   data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
2023-11-18 14:07:07 200-0: 14:07:07    303M   data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
2023-11-18 14:07:08 200-0: 14:07:08    414M   data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
...
2023-11-18 14:09:29 200-0: 14:09:29   15.7G   data-disk/vm-200-disk-0@__replicate_200-0_1700312822__
2023-11-18 14:09:30 200-0: warning: cannot send 'data-disk/vm-200-disk-0@__replicate_200-0_1700312822__': Input/output error
2023-11-18 14:09:31 200-0: cannot receive new filesystem stream: checksum mismatch
2023-11-18 14:09:31 200-0: cannot open 'data-disk/vm-200-disk-0': dataset does not exist
2023-11-18 14:09:31 200-0: command 'zfs recv -F -- data-disk/vm-200-disk-0' failed: exit code 1
2023-11-18 14:09:31 200-0: delete previous replication snapshot '__replicate_200-0_1700312822__' on data-disk:vm-200-disk-0
2023-11-18 14:09:31 200-0: end replication job with error: command 'set -o pipefail && pvesm export data-disk:vm-200-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_200-0_1700312822__ | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve2' root@10.10.10.22 -- pvesm import data-disk:vm-200-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_200-0_1700312822__ -allow-rename 0' failed: exit code 1

Welche Informationen kann ich noch bereitstellen um dazu eine Lösung zu finden?

Viele Grüße und einen schönen Samstag,
Buddinski88

 

[sb-jw]

Kannst du uns mal was zu deinen Speicherplatzgrößen sagen? Ich hätte ggf. im Verdacht, dass dir hier die Platten voll laufen und es daher nicht geht.

 

[Buddinski88]

Kannst du uns mal was zu deinen Speicherplatzgrößen sagen? Ich hätte ggf. im Verdacht, dass dir hier die Platten voll laufen und es daher nicht geht.

Klar gerne. Das NAS hat noch 21,5 TB Speicher frei
Das dataset auf dem der Share liegt hat keine Speicherbegrenzung.

Kann es sein, dass ein Image an einer bestimmten Stelle einen "Knacks" hat?

 

[sb-jw]

Wie sieht es denn lokal auf den Nodes aus? Ist das Volumen wirklich gemountet und die Daten landen wirklich auf dem Storage selbst oder womöglich doch auf der lokalen Platte?

 

[Buddinski88]

Wie sieht es denn lokal auf den Nodes aus? Ist das Volumen wirklich gemountet und die Daten landen wirklich auf dem Storage selbst oder womöglich doch auf der lokalen Platte?

Das Volume liegt auf der "data-disk", welche ich als Basis für die Replizierung nutze bzw. in diesem Fall nutzen möchte. Ich hoffe das beantwortet deine Frage?

 

[sb-jw]

Ich hoffe das beantwortet deine Frage?

Nein nicht direkt. Ich führe aber mal anders aus.

Möglicherweise wird das Backup erst mal unter "/var/lib/vz/dump/" abgelegt ehe es nach "backup-truenas" verschoben wird. Schau doch mal beim Backupen selbst ob das File direkt auf dem "backup-truenas" liegt oder ob es erst mal lokal erstellt wird.

Die VM 100 hat ja z. B. weniger Speicherplatz, möglicherweise hast du also weniger als die ~64 GB frei.

 

[Buddinski88]

Nein nicht direkt. Ich führe aber mal anders aus.

Möglicherweise wird das Backup erst mal unter "/var/lib/vz/dump/" abgelegt ehe es nach "backup-truenas" verschoben wird. Schau doch mal beim Backupen selbst ob das File direkt auf dem "backup-truenas" liegt oder ob es erst mal lokal erstellt wird.

Die VM 100 hat ja z. B. weniger Speicherplatz, möglicherweise hast du also weniger als die ~64 GB frei.

Habe es eben mal geprüft. Unter "/var/lib" gibt es das Verzeichnis "dump" nicht. Ein Backup erzeugt direkt auf dem NAS das archiv.





Es kommt dann wieder folgende Fehlermeldung:

INFO: starting new backup job: vzdump 200 --storage backup-truenas --notes-template '{{cluster}}, {{guestname}}, {{node}}, {{vmid}}' --mode snapshot --compress zstd --node pve1 --remove 0
INFO: Starting Backup of VM 200 (qemu)
INFO: Backup started at 2023-11-18 15:51:54
INFO: status = running
INFO: VM Name: docker-prod
INFO: include disk 'scsi0' 'data-disk:vm-200-disk-0' 64G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive '/mnt/pve/backup-truenas/dump/vzdump-qemu-200-2023_11_18-15_51_54.vma.zst'
INFO: started backup task 'a98b6166-daac-4443-bc4a-582433f499e0'
INFO: resuming VM again
INFO:   3% (2.3 GiB of 64.0 GiB) in 3s, read: 780.6 MiB/s, write: 347.7 MiB/s
INFO:   4% (2.9 GiB of 64.0 GiB) in 6s, read: 219.9 MiB/s, write: 215.6 MiB/s
INFO:   5% (3.6 GiB of 64.0 GiB) in 9s, read: 238.0 MiB/s, write: 235.7 MiB/s
INFO:   6% (4.4 GiB of 64.0 GiB) in 12s, read: 253.8 MiB/s, write: 247.2 MiB/s
INFO:   7% (5.0 GiB of 64.0 GiB) in 15s, read: 221.1 MiB/s, write: 218.5 MiB/s
INFO:   8% (5.6 GiB of 64.0 GiB) in 18s, read: 183.7 MiB/s, write: 178.7 MiB/s
INFO:   9% (6.2 GiB of 64.0 GiB) in 21s, read: 209.0 MiB/s, write: 207.4 MiB/s
INFO:  10% (6.7 GiB of 64.0 GiB) in 24s, read: 192.1 MiB/s, write: 191.9 MiB/s
INFO:  11% (7.3 GiB of 64.0 GiB) in 27s, read: 187.3 MiB/s, write: 186.8 MiB/s
INFO:  12% (7.8 GiB of 64.0 GiB) in 30s, read: 182.5 MiB/s, write: 181.4 MiB/s
INFO:  13% (8.5 GiB of 64.0 GiB) in 33s, read: 246.5 MiB/s, write: 237.5 MiB/s
INFO:  14% (9.1 GiB of 64.0 GiB) in 36s, read: 200.6 MiB/s, write: 197.6 MiB/s
INFO:  15% (9.7 GiB of 64.0 GiB) in 39s, read: 200.6 MiB/s, write: 200.2 MiB/s
INFO:  16% (10.4 GiB of 64.0 GiB) in 42s, read: 245.3 MiB/s, write: 241.6 MiB/s
INFO:  17% (11.1 GiB of 64.0 GiB) in 45s, read: 217.5 MiB/s, write: 216.3 MiB/s
INFO:  18% (11.9 GiB of 64.0 GiB) in 48s, read: 299.7 MiB/s, write: 189.5 MiB/s
INFO:  19% (12.7 GiB of 64.0 GiB) in 51s, read: 268.2 MiB/s, write: 263.9 MiB/s
INFO:  21% (13.5 GiB of 64.0 GiB) in 54s, read: 270.7 MiB/s, write: 269.2 MiB/s
INFO:  22% (14.2 GiB of 64.0 GiB) in 57s, read: 242.9 MiB/s, write: 234.4 MiB/s
INFO:  23% (15.0 GiB of 64.0 GiB) in 1m, read: 246.5 MiB/s, write: 245.8 MiB/s
INFO:  24% (15.6 GiB of 64.0 GiB) in 1m 3s, read: 204.2 MiB/s, write: 202.2 MiB/s
INFO:  25% (16.2 GiB of 64.0 GiB) in 1m 6s, read: 211.5 MiB/s, write: 211.3 MiB/s
INFO:  26% (16.8 GiB of 64.0 GiB) in 1m 9s, read: 223.5 MiB/s, write: 223.2 MiB/s
INFO:  26% (16.9 GiB of 64.0 GiB) in 1m 10s, read: 79.4 MiB/s, write: 79.4 MiB/s
ERROR: job failed with err -5 - Input/output error
INFO: aborting backup job
INFO: resuming VM again
ERROR: Backup of VM 200 failed - job failed with err -5 - Input/output error
INFO: Failed at 2023-11-18 15:53:05
INFO: Backup job finished with errors
TASK ERROR: job errors

Mit "df" sehe ich auch, dass nur auf dem MNT der Speicher geringer wird.
Lokal verändert sich da nichts.

 

[Falk R.]

Dann könnte tatsächlich die Platte einen defekten Sektor haben. Dann solltest du zum Zeitpunkt des Abbruchs einen hohen I/O Delay sehen.

 

[Buddinski88]

Dann könnte tatsächlich die Platte einen defekten Sektor haben. Dann solltest du zum Zeitpunkt des Abbruchs einen hohen I/O Delay sehen.

Ich habe es eben mal beobachtet, auf dem pve1 geht das I/O Delay auf 0,76 hoch. Normalerweise ist es bei 0,02-0,06. Das dürfte also auch nicht das Problem sein oder?

 

[Buddinski88]

Update: Ich habe noch folgendes rausgefunden. Wenn ich das Volume von dem ZFS "data-disk" storage auf "local-lvm" verschieben möchte, bricht das auch bei 16,7 GB ab. I/O Delay liegt während des verschieben bei: Mittelwertwert 30 %, Peak 45 %.

Wenn ich mal schauen wo das Volume liegt, dann taucht es hier überall auf:



Ist das so korrekt?

Mein Plan war es das Volume per Hand zu sicher und ich habe nur eine Datei und keine geteilten Dateien erwartet.
Anschließend hätte ich versucht das Volume mal per CLI zu verkleinern auf seine damals ursprünglichen 32 GB.

Ich bin echt ratlos. Im aktuellen Zustand wäre es fatal, wenn die VM einfach defekt gehen würde, denn ich habe nicht mal eine Sicherung :-(

 

[Falk R.]

Wenn er immer an der gleichen Stelle abbricht, sind die Daten da defekt. Entweder einfach die Nutzdaten aus der VM in eine andere kopieren. Entweder fehlt dir dann eine Datei, oder du hast Glück, dass auf dem defekten Block nichts wichtiges liegt.

 

[sb-jw]

Klick mal auf den Node selbst, dann auf Disks und dort wählst du mal deine entsprechende Disk aus. Oben in der Leiste kannst du dann auf "Show S.M.A.R.T. values" klicken. Das Popup machst du mal groß und davon einen Screenshot und lädst den hier mal hoch.

Ggf. siehst du auch direkt auf der Übersicht ob S.M.A.R.T. als "PASSED" aufgeführt ist oder nicht, auch das Wearout ist ein relevanter Indikator, insbesondere bei Flashspeicher.

Vielleicht hast du auch Glück und ein Scrub kann den Fehler beheben.

 

[Falk R.]

Scrub kann den aber nur beheben, wenn ein RAID (Mirror) da ist. Theoretisch sollte bei jedem Zugiff, also Abbruch der Zähler bei Hard Read Errors hochzählen. Leider sind die Ausgaben von SMART je nach Hersteller unterschiedlich, erst bei NVMe wurde das standardisiert.

 

[Buddinski88]

Klick mal auf den Node selbst, dann auf Disks und dort wählst du mal deine entsprechende Disk aus. Oben in der Leiste kannst du dann auf "Show S.M.A.R.T. values" klicken. Das Popup machst du mal groß und davon einen Screenshot und lädst den hier mal hoch.

Ggf. siehst du auch direkt auf der Übersicht ob S.M.A.R.T. als "PASSED" aufgeführt ist oder nicht, auch das Wearout ist ein relevanter Indikator, insbesondere bei Flashspeicher.

Vielleicht hast du auch Glück und ein Scrub kann den Fehler beheben.

Ich sehe hier keine größeren Probleme. 3 % Wareout sind doch in Ordnung oder?

Wenn er immer an der gleichen Stelle abbricht, sind die Daten da defekt. Entweder einfach die Nutzdaten aus der VM in eine andere kopieren. Entweder fehlt dir dann eine Datei, oder du hast Glück, dass auf dem defekten Block nichts wichtiges liegt.

Das wollte ich eigentlich vermeiden Bin aber froh das ich alles sauber dokumentiert habe. Werde das morgen früh mal in Ruhe in Angriff nehmen.

Bzgl. Scrub muss ich mal schauen wie das geht. Gibt es da ein bestimmtes Vorgehen?

 

[sb-jw]

Ich sehe hier keine größeren Probleme. 3 % Wareout sind doch in Ordnung oder?

Laut den SMART values hast du kein Wearout von 3 % sondern 97 %. Das Feld heißt "lifetime remaining". Es ist jetzt die Frage ob es der Hersteller korrekt implementiert hat oder nicht.
Die Hersteller machen das teils wie sie wollen, der eine fängt bei 100 % an der von 0 %.

Nach LBA Written hast du auch bereits 4,66 TB geschrieben.
https://www.virten.net/2016/12/ssd-total-bytes-written-calculator/

 

[Buddinski88]

Laut den SMART values hast du kein Wearout von 3 % sondern 97 %. Das Feld heißt "lifetime remaining". Es ist jetzt die Frage ob es der Hersteller korrekt implementiert hat oder nicht.
Die Hersteller machen das teils wie sie wollen, der eine fängt bei 100 % an der von 0 %.

Nach LBA Written hast du auch bereits 4,66 TB geschrieben.
https://www.virten.net/2016/12/ssd-total-bytes-written-calculator/

Angenommen der Hersteller hat es richtig implementiert, dann die Platte wohl kurz vor dem Tod? :-(
Wenn ja, dann würde ich asap eine neue Bestellen und schauen wie ich das noch geschickt austauschen kann.

Hab mich ein bisschen mit zpool belesen. Schaut man sich den Status an, dann sagt der ja schon das es einen Fehler gibt:

root@pve1:~# zpool status
  pool: data-disk
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub in progress since Sun Nov 19 19:38:27 2023
        84.1G scanned at 0B/s, 17.3G issued at 352M/s, 84.1G total
        0B repaired, 20.59% done, 00:03:14 to go
config:

        NAME                                STATE     READ WRITE CKSUM
        data-disk                           ONLINE       0     0     0
          ata-CT1000MX500SSD1_2307E6AC9D88  ONLINE       0     0    10

Mit `zpool scrub data-disk` hab ich mal einen scrub gestartet.

root@pve1:~# zpool status -v
  pool: data-disk
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub repaired 0B in 00:04:22 with 2 errors on Sun Nov 19 19:42:49 2023
config:

        NAME                                STATE     READ WRITE CKSUM
        data-disk                           ONLINE       0     0     0
          ata-CT1000MX500SSD1_2307E6AC9D88  ONLINE       0     0    14

errors: Permanent errors have been detected in the following files:

        <0x1613>:<0x1>
        <0x1519>:<0x1>
        <0xd1f>:<0x1>
        <0x1043>:<0x1>
        <0x1256>:<0x1>
        <0x35e>:<0x1>
        <0x761>:<0x1>
        <0xd73>:<0x1>
        <0x5579>:<0x1>
        data-disk/vm-200-disk-0:<0x1>
        <0x1780>:<0x1>
        <0x598b>:<0x1>
        <0x108d>:<0x1>
        <0x4a8>:<0x1>
        <0x5b1>:<0x1>
        <0x6c4>:<0x1>
        <0x15cf>:<0x1>
        <0xae2>:<0x1>
        <0x3e8>:<0x1>

Da kann ich wohl nicht mehr viel machen oder?

 

[Buddinski88]

Kurzes Update: Habe heute morgen alles auf eine neue VM umgezogen. Zum Glück liegt mittlerweile der größte Teil auf TrueNAS. Dementsprechend ging es relativ einfach. Docker ist schon was cooles.

Eine neue Festplatte habe ich vorsichtshalber mal bestellt.

 

[sb-jw]

Gerade mal nach Infos vom Hersteller geschaut: https://www.crucial.de/support/articles-faq-ssd/ssds-and-smart-data

Ich denke die Aussage "Es ist was es heißt" ist da eindeutig. Die Platte ist durch.
Was ich aber bedenklich finde, die zeigt gerade mal 2010 Stunden PoH an. Ich habe SSDs in nem CEPH am laufen, die schon weit mehr Stunden haben und nicht mal 5 % verloren haben. Ich habe daher mal Google mit "crucial mx500 lifetime" gefüttert und einige Reddit Artikel gefunden, die eine schnelle Abnutzung oder Bug beschreiben.

Wenn du noch Garantie / Gewährleistung hast dann schick die ein mit der Begründung "wird vom RAID nicht mehr akzeptiert" so lange noch Lebenszeit übrig ist sollte das noch klappen.

Ich würde dir aber nun auch dringend von einer weiteren Mx500 abraten.

 

[UdoB]

Die Platte ist durch.

Die "nackt" gelieferten Werte waren schon immer herstellerspezifisch. Weil das bereits früh als Problem erkannt wurde, werden seit langem alle Werte auf 100% normiert: 100 = optimal gesund, abnehmend = sich verschlechternd. Nahe Null (unterhalb "Threshold") = ganz schlecht.

Ich habe noch nie eine Platte gesehen, deren normierte Werte "andersherum" arbeiteten. Obwohl https://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology das anscheinend für möglich hält.

"202 Percent_Lifetime_Ramin: Raw Value=3 Normalized=97" würde ich immer als "noch 97% verfügbar" lesen.

Just my 2€¢...

 

[news]

Guten Tag,

ich schaue mir bei den Crucial MX500 500GB immer die geschriebenen Blöcke an.

Das ist mit smartctl -a <device> der Parameter "246 Total_LBAs_Written"

Dann rechne ich lieber selber:

sei LBA_Written = "Total_LBAs_Written" in 512 Byte Einheiten

die W Abnutzung (wearout) ist wie folgt zu berechnen:

W = LBA_Written * 512 (B) /1024^4 (T) /180 (TB) ; in Prozent P = W * 100;

Smartctl -a gibt unter dem Parameter "202 Percent_Lifetime_Remain" nur den rechnerisch ganzen Teil (E |N) zurück, die Nachkommastelle wird abgeschnitten.

Z.B. meine CT500MX500SSD1 als ZFS Special Device im Mirror:
9 Power_On_Hours 5614
202 Percent_Lifetime_Remain 2
246 Total_LBAs_Written 8288100359