SMART-Benutzerkapazität und fdisk -l-Größenwert unterscheiden sich. Warum? Sicherheitsproblem?

SMART-Benutzerkapazität und fdisk -l-Größenwert unterscheiden sich. Warum? Sicherheitsproblem?

Ich frage mich nur, warum die von smartctl („User Capacity“) angezeigte Größe meines Laufwerks von dem Wert abweicht, den fdisk -l, dmesg, hdparm anzeigt, und von den Laufwerksspezifikationswerten im Datenblatt abweicht. Ich brauche einige Hinweise zur Interpretation dieser Werte.

Zuerst machte ich ein

dd_rescue /dev/zero /dev/sdf 

bis dd_rescue mit der Meldung „Kein Speicherplatz mehr auf dem Gerät“ abbrach.

Die übertragene Menge betrug 3000558944256 Bytes. Das ist vergleichbar mit der Bytemenge von fdisk -l und dmesg.

smartctl -x sagt:

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (Adv. Format)
(...)
Firmware Version: 80.00A80
User Capacity:    3.000.559.428.096 bytes [3,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ACS-2 (revision not indicated)
Local Time is:    Thu Jul  3 19:10:34 2014 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

fdisk -l sagt:

Note: sector size is 4096 (not 512)

Disk /dev/sdf: 3000.6 GB, 3000558944256 bytes
255 heads, 63 sectors/track, 45599 cylinders, total 732558336 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

dmesg sagt:

[  176.168005] sd 5:0:0:0: [sdf] Spinning up disk.............ready
[  186.352957] sd 5:0:0:0: [sdf] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB)

hdparm -I -g /dev/sdf

/dev/sdf:
 geometry      = 364797/255/63, sectors = 5860466688, start = 0             
(that's the fdisk -l value / 512)

 LBA48  user addressable sectors: 5860467633 
(that's the SMART reported value / 512)

Laufwerksspezifikation von der WD-Website:

User sectors per drive: 5860533168
(That is LBA48 Value + 65 535) (?!)

hdparm --dco-identify /dev/sdf

DCO Revision: 0x0002
(...)
Real max sectors: 5860533168

hdparm -N /dev/sdf

/dev/sdf:
 READ_NATIVE_MAX_ADDRESS_EXT failed: Input/output error    

Das Problem: Es besteht ein Unterschied von 483840 Bytes zwischen den SMART-Informationen und den dd_rescue-, fdisk- und dmesg-Werten. Und die Produktspezifikation zeigt, dass das Laufwerk 65535 Sektoren größer ist als von SMART angegeben und nicht über LBA angesprochen werden kann. Ich habe also 3 Größenwerte, die ich nicht verstehe.

Ich habe herumgerechnet und herausgefunden, dass

483840 / 4096 = 118
483840 / 512 = 945
(483840 / 63 (sectors/track) = 7 680)

Vielleicht hat es eine Bedeutung, dass die fehlenden Bytes n-mal so groß sind wie die Sektorgröße? Sind einige Sektoren nicht adressierbar? Warum? Liegt es an der LBA -> CHS-Übersetzung?

Das Laufwerk ist neu aus dem Geschäft. SMART zeigt keine ausstehenden Sektoren, keine Neuzuweisungsereignisse und keine neu zugewiesenen Sektoren an.

Ich habe noch ein paar zusätzliche Experimente gemacht:
Auf meiner internen Festplatte "Hitachi Deskstar T7K500" unterscheiden sich die SMART- und fdisk-Werte nicht.
Auf meiner externen USB-Festplatte "SAMSUNG SpinPoint F2 EG" unterscheiden sich die SMART- und fdisk-Werte nicht. Das ist nur bei meiner externen USB-Festplatte (Western Digital My Book) der Fall.

Vielleicht gibt es reservierten Speicherplatz? Wofür? Vielleicht hat es etwas mit der Hardware-Verschlüsselungsfunktion zu tun (nicht eingeschaltet)?

Könnte es sein, dass sich auf dem Laufwerk fehlerhafte Sektoren befinden, die die Firmware intern neu zugeordnet und nicht an SMART gemeldet hat?

Das Laufwerk hatte ein fehlerhaftes NTFS-Dateisystem, das reparierbar war. Aber eine neue Festplatte sollte meiner Meinung nach kein beschädigtes Dateisystem haben. Vielleicht gab es hier eine interne Neuzuordnung der Sektoren?

Ich habe gerade festgestellt, dass mein anderes externes USB-Laufwerk von Western Digital (Western Digital My Passport Essential SE) dasselbe Problem hat. Zwischen der SMART-Ausgabe und der fdisk -l-Ausgabe fehlen 2.842.624 Bytes. (Auf diesem Laufwerk befinden sich jedoch ausstehende Sektoren.)

Ich denke, dies könnte sogar ein Sicherheitsproblem sein:

Normalerweise können Sie mit dem Befehl dd_recue sicher sein, dass die gesamte Festplatte überschrieben wird, aber aufgrund des Byte-Differenzproblems bin ich mir nicht sicher, ob alles überschrieben wurde (ich weiß, dass physisch fehlerhafte Sektoren und wahrscheinlich intern neu zugeordnete Sektoren und ausstehende Sektoren möglicherweise nicht zugänglich sind und nicht überschrieben werden können, aber im SMART-Protokoll sind keine neu zugeordneten Sektoren aufgeführt).

Zwischendurch habe ich vom Konzept „Host Protected Area“ und DCO gehört, aber dmesg hat keinen Hinweis darauf angezeigt. Das Betriebssystem ist OpenSuse 12.2 und die Kernel-Version (uname -r) ist „3.4.11-2.16-desktop“.

Außerdem habe ich diese Seite gefunden:
https://unix.stackexchange.com/questions/139705/warum sieht hdparm zwei unterschiedliche Werte für die Größe eines Laufwerks?
was auch ein Hinweis sein könnte. Habe aber für meine Werte ein wenig herumgerechnet und bin nicht auf die Lösung gekommen.

Hat jemand Hinweise oder eine Erklärung dazu?

Die Fragen lauten:
1. Warum besteht ein Unterschied von 483840 Bytes zwischen SMART Info und dmesg?
2. Warum besteht ein Unterschied von 65535 Sektoren zwischen der HD-Spezifikation und den LBA-Sektoren?
3. Gibt es einen Host-geschützten Bereich oder ein DCO auf dem Laufwerk? Wie finde ich das heraus?
4. Wie groß ist meine Festplatte tatsächlich und wie kann ich sie sicher löschen (ich gehe davon aus, dass ATA SECURITY ERASE UNIT über USB nicht funktioniert, ich werde es später versuchen)

Danke!

Antwort1

Dies ist zwar keine Antwort, könnte aber helfen. Ich habe eine ähnliche Situation mit einer externen USB-Festplatte, die bei unterschiedlichen Abfragen unterschiedliche Kapazitäten meldet.

smartctl -i -d scsi /dev/sdbgibt:

smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.14.27-std-def-alt1] (ALT Linux 6.2-alt0.M70P.1)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               BUFFALO
Product:              HD-PNTU3
Revision:             0001
User Capacity:        1,000,173,428,736 bytes [1.00 TB]
Logical block size:   512 bytes
Logical Unit id:      0x6000039426a846b30000000000000000
Device type:          disk
Local Time is:        Thu Jan 22 19:57:29 2015 JST
SMART support is:     Unavailable - device lacks SMART capability.

Allerdings smartctl -i -d sat /dev/sdbergibt sich:

smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.14.27-std-def-alt1] (ALT Linux 6.2-alt0.M70P.1)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 2.5" HDD MQ01ABD...
Device Model:     TOSHIBA MQ01ABD100
Serial Number:    72D7F1JHS
LU WWN Device Id: 5 000039 426a846b3
Firmware Version: AX0A1U
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Jan 22 19:57:36 2015 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Sie unterscheiden sich nicht nur in der Kapazität, sondern auch im Modellnamen und darin, ob die physische Sektorgröße 4096 Byte beträgt oder nicht. In meinem Fall:

  • hdparm -I /dev/sdbscheint die Informationen zur größeren Kapazität/zum 4-KiB-physischen Sektor zu sehen.

  • hdparm -g /dev/sdb, fdisk -l /dev/sdb, cat /sys/block/sdb/sizeund cat /sys/block/sdb/queue/physical_block_sizezeigen alle die kleinere Kapazität / 512B-physische Sektorinformationen an.

Was das Sicherheitsproblem angeht, sollte es in Ordnung sein, wenn niemand jemals vertrauliche Daten in die „unzugänglichen“ Sektoren geschrieben hat. fdiskkann sie nicht sehen, und in meinem Fall sieht Windows sie auch nicht. Wahrscheinlich haben sie nie zu einer Partition gehört.

Es scheint jedoch, dass einige LVM-Tools durch die Diskrepanz verwirrt werden:https://unix.stackexchange.com/questions/139705/why-does-hdparm-see-two-different-values-for-the-size-of-a-drive/180808

verwandte Informationen