Datenverlust Ubuntu

[Erich (Gast)]

Hallo
Ich bin grade etwas Ratlos zum 2.Mal verliere ich eine ganze Platte voll 
Daten.
Ich habe 2 Server laufen beide recht neu aufgesetzt mit Ubuntu 20 
Desktop. Ich habe einige Usb platten für Backups. Ich schlisse also 
diese Festplatte an den Server erstelle mit Gparted eine ext4 Partition 
und kopiere die Backup Daten drauf. Passt alles. Ich kann auf die Daten 
zugreifen und ich denke alles ist toll. Dann hänge ich die Partition aus 
stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.
Device     Boot Start        End    Sectors Size Id Type
/dev/sde1           1 4294967295 4294967295   2T ee GPT

Partition 1 does not start on physical sector boundary.
Zurück am U20 Server bleibt die Platte genauso ohne Partition.

Beim ersten mal hatte ich eine Platte am Usb Nachdem ich dann nochmal 
eine Partition erstellt hatte und alles neu kopiert hatte funktionierte 
es. Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem 
Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche 
Problem.

Habt ihr das schon mal erlebt? wie könnte sich das erklären?
Bzw wo könnte der Fehler sein?

Ps Nein es gab keinen Datenverlust weil es sich nur um Backups handelt 
und ich die öfter mache ;)

[🐧 DPA 🐧 (Gast)]

Von welchem Programm kommt die Ausgabe?

Was da angezeigt wird ist eine GPT Protektive Partition in einem 
protektiven MBR.
Versuche mal, dir mit z.B. gdisk oder so die Partitionstabelle anzeigen 
zu lassen. ("gdisk -l /dev/sde").

Schaue auch mal nach, was "ls -l /dev/sde*" liefert. Offset usw., die 
der Kernel für diese effektiv ermittelt hat, kannst du so ermitteln: 
https://unix.stackexchange.com/questions/335690/recovering-partitioning-information-from-block-devices#answer-335697

[bingo (Gast)]

Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das 
Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm 
partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1. 
benutzten Sektor sollten 2048 Sektoren frei sein!

Bei mir sieht das so aus:

Gerät      Boot   Anfang       Ende   Sektoren  Größe Kn Typ
/dev/sda1  *        2048   57738376   57736329  27,5G 83 Linux
/dev/sda3       57739264 1953327103 1895587840 903,9G 83 Linux

[Norbert (Gast)]

Hmm,
gerade mit Debian oldstable getestet, keinerlei Probleme.

# cd /tmp
# truncate -s 2T zweitb
# losetup /dev/loop7 zweitb
# gparted /dev/loop7
GPT erstellen, FS erstellen, alles default.
# sfdisk -l /dev/loop7
Disk /dev/loop7: 2 TiB, 2199023255552 bytes, 4294967296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 06FC14D7-F15B-471A-A93A-0FDD44B9675E

Device       Start        End    Sectors Size Type
/dev/loop7p1  2048 4294965247 4294963200   2T Linux filesystem
# mkdir mnt
# mount /dev/loop7p1 /tmp/mnt/
# df -h /dev/loop7p1 
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop7p1    2,0T     71M  1,9T    1% /tmp/mnt

Würde sagen: Ubuntu oder Fehlbedienung.

[bingo (Gast)]

Norbert schrieb:
 Würde sagen: Ubuntu oder Fehlbedienung.

eindeutig Fehlbedienung, Ubuntu macht das richtig.

Übrigens ist 16.xx EOL !

[foobar (Gast)]

Was ich noch erlebt habe, sind unterschiedliche Blockgrößen, jenachdem 
wie ich die Platte angeschlossen habe.  Per USB-SATA-Adapter 4k-Blöcke, 
direkt an SATA-Port des Motherboards 512-Byte-Blöcke.  Da klappt dann 
auch nichts.

Btw, wenn ich die Platte nur als eine große Partition brauche, spar ich 
mir gerne die Partition-Table und benutze direkt /dev/sdX - kein 
Gewurschtel mit GPT etc ...

[oerks (Gast)]

Bei einer 2 TB-Platte wuerde ich nur einen MBR anlegen und gut ist.
Da braucht man das Gekasper mit GPT noch nicht.

Den MBR natuerlich ganz an den Anfang der Platte.

[Mladen G. (mgira)]

Erich schrieb:
> Beim ersten mal hatte ich eine Platte am Usb Nachdem ich dann nochmal
> eine Partition erstellt hatte und alles neu kopiert hatte funktionierte
> es. Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem
> Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche
> Problem.

Lass mal den Teil mit USB komplett weg.

Die haben manchmal ihre eigenen Treiber für die Umsetzung von SATA auf 
USB, manche (manche WD USB externe laufwerke) verstehen sogar 
Dateisysteme, sind aber keine richtigen Festplatten mehr, nur noch 
extern nutzbar.

D.h. wenn du deine SATA Platten per SATA Verbindung bespielst und danach 
als SATA Platten nutzt, sind deine Chancen am grössten.

[Nano (Gast)]

Erich schrieb:
> Ich kann auf die Daten
> zugreifen und ich denke alles ist toll. Dann hänge ich die Partition aus
> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.
> Device     Boot Start        End    Sectors Size Id Type
> /dev/sde1           1 4294967295 4294967295   2T ee GPT
>
> Partition 1 does not start on physical sector boundary.
> Zurück am U20 Server bleibt die Platte genauso ohne Partition.

> Beim 2. Mal das war eine andere neue Platte. Ich hatte diese aus dem
> Usbgehäuse geholt und per sata Kopiert und jetzt wieder das gleiche
> Problem.
>
> Habt ihr das schon mal erlebt? wie könnte sich das erklären?
> Bzw wo könnte der Fehler sein?

Ja, habe ich.

Und zwar über eSATA.
Ich hatte einmal, nach dem ich meine Rechner aufgerüstet habe vergessen 
im BIOS für den für eSATA vorgesehen Port hot-plug auf enabled 
einzuschalten.
Das führte dann beim Anschließen der Platte dazu, dass die Daten 
scheinbar weg waren.
Außerdem meldete mir der Kernel noch Lesefehler.

Schau also mal ins BIOS/UEFI und sieh da nach, ob für den verwendeten 
SATA Port hot-plug eingeschaltet ist.
Beachte dabei, dass leere Batterien zum Verlust der BIOS Einstellungen 
führen und dann wieder BIOS Defaultwerte eingestellt werden. Wenn hier 
der Default Wert der ist, dass die ganzen SATA ports bezüglich hot-plug 
auf disabled stehen, dann musst du vor jeder Benutzung auch darauf 
achten dass da keine Daten verloren gingen und die Batterie noch 
ausreichend Energie hat.

Die Distri war damals auch Kubuntu 16.04 LTS, falls das wichtig ist.

Wegen GPT könnte es hilfreich sein die Distri upzudaten, so dass du von 
etwaigen Korrekturen in den neuen Softwareversionen profitierst.

Mladen G. Aussage schließe ich mich an. Wenn du die Möglichkeit hast, 
die Platte via (e)SATA an den PC anzuschließen, dann nutze diese 
Möglichkeit. Achte aber wie oben angegeben auf die hot-plug Einstellung 
im UEFI/BIOS.

[Nano (Gast)]

Falls du die Platte vorher anschließt, bevor du den Rechner in Betrieb 
nimmst und dann auch nicht vor dem Ausschalten des Rechners wieder 
abstöpselst, ist das der Hot-Plug Einstellung natürlich egal.
Dennoch könnte es sein, dass man bei laufendem Rechner nicht darauf 
achtet und dann braucht man diese. Also wenn du auf Nummer Sicher gehen 
willst, dann aktiviere Hot-Plug.

[>>> (Gast)]

bingo schrieb:
> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das
> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm
> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.
> benutzten Sektor sollten 2048 Sektoren frei sein!
>

Wenn du Booten willst. Üblich, muss aber nicht so sein.
Einfach vielfache von 8 (4096/512) sollten es auch tun.
(g)parted kann man auch irgendeinen passenden Start geben,
z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.
Dann spielt auf die Sektorgröße auf anderem System keine Rolle.

Neu anlegen wird hier warscheinlich aber schneller gehen.

[bingo (Gast)]

>>> schrieb:
> bingo schrieb:
>> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das
>> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm
>> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.
>> benutzten Sektor sollten 2048 Sektoren frei sein!
>>
>
> Wenn du Booten willst. Üblich, muss aber nicht so sein.
> Einfach vielfache von 8 (4096/512) sollten es auch tun.
> (g)parted kann man auch irgendeinen passenden Start geben,
> z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.
> Dann spielt auf die Sektorgröße auf anderem System keine Rolle.


Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das 
konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1. 
Sektors auf der Platte (HDD oder SSD) ist 0 !!!

[Heiner (Gast)]

Erich schrieb:
> Device     Boot Start        End    Sectors Size Id Type
> /dev/sde1           1 4294967295 4294967295   2T ee GPT
>
> Partition 1 does not start on physical sector boundary.

Das erscheint mir eine Ausgabe von fdisk zu sein. Du kannst die Version 
mit fdisk -l überprüfen, aber bei Xenial mit den letzten Updates sollte 
das 2.27.1 sein. fdisk kann aber GPT erst seit 2.30.2, und auch das wohl 
nicht vollständig.

Und auch der Rest des Systems könnte vielleicht nicht GPT-fähig sein, 
also würde ich die Platte einfach mal probeweise mit MBR partitionieren.

[Rolf M. (rmagnus)]

bingo schrieb:
> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das
> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.
> Sektors auf der Platte (HDD oder SSD) ist 0 !!!

Eigentlich sollte das sowohl bei 512-Byte-Sektoren, als auch bei 
4k-Sektoren  egal sein. Ein Problem gibt es nur, wenn die Platte zwar 
eigentlich 4k-Sektoren hat, aber nach außen hin so tut, als hätte sie 
512-Byte-Sektoren.

[Norbert (Gast)]

Rolf M. schrieb:
> bingo schrieb:
>> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das
>> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.
>> Sektors auf der Platte (HDD oder SSD) ist 0 !!!
>
> Eigentlich sollte das sowohl bei 512-Byte-Sektoren, als auch bei
> 4k-Sektoren  egal sein. Ein Problem gibt es nur, wenn die Platte zwar
> eigentlich 4k-Sektoren hat, aber nach außen hin so tut, als hätte sie
> 512-Byte-Sektoren.

Selbst dann sollte es funktionieren, allerdings mit einer üblen 
»performance penalty«

Bedenklich finde ich das selbst heutzutage eine Samsung SSD 850 EVO 
250GB das Folgende meldet:

# hdparm -I /dev/sda
ATA device, with non-removable media
  Model Number:       Samsung SSD 850 EVO 250GB               
  Serial Number:      xxxxxxxxxxxxxxx     
  Firmware Revision:  EMT02B6Q
  Transport:          SATA Rev 3.0
Configuration:
  Logical    max  current
  cylinders  16383  16383
  heads    16  16
  sectors/track  63  63
  --
  CHS current addressable sectors:    16514064
  LBA    user addressable sectors:   268435455
  LBA48  user addressable sectors:   488397168
  Logical  Sector size:                   512 bytes
  Physical Sector size:                   512 bytes
  Logical Sector-0 offset:                  0 bytes
  device size with M = 1024*1024:      238475 MBytes
  device size with M = 1000*1000:      250059 MBytes (250 GB)
  cache/buffer size  = unknown
  Form Factor: 2.5 inch
  Nominal Media Rotation Rate: Solid State Device

Man beachte logical und physical sector size…

[(prx) A. K. (prx)]

Norbert schrieb:
> Man beachte logical und physical sector size…

Und was ist daran bedenklich?

[Rolf M. (rmagnus)]

Norbert schrieb:
> Selbst dann sollte es funktionieren, allerdings mit einer üblen
> »performance penalty«

Ja, richtig.

> Bedenklich finde ich das selbst heutzutage eine Samsung SSD 850 EVO
> 250GB das Folgende meldet:

SSDs sind ja sowieso speziell, da sie in der Hinsicht komplett anders 
arbeiten als Festplatten, aber nach außen hin das Verhalten einer 
Festplatte emulieren. Ein Unterschied ist ja schon, dass SSDs intern 
nicht nur die beiden Operationen "lesen" und "schreiben", sondern 
zusätzlich noch eine dritte Operation "löschen" brauchen. Dazu kommt 
noch, dass die Blockgröße, in der das stattfindet, für alle drei 
Operationen unterschiedlich (und insbesondere für das Löschen auch sehr 
viel größer als für die anderen) ist. Somit gibt es dort gar keine 
klassische Sektorgröße. Es bleibt nur noch die quasi virtuelle 
Sektorgröße der emulierten Festplatte übrig. Der SSD-Controller kümmert 
sich dann darum, dass on-the-fly irgendwie passend auf den tatsächlichen 
internen Aufbau zu übersetzen.

[Norbert (Gast)]

(prx) A. K. schrieb:
> Norbert schrieb:
>> Man beachte logical und physical sector size…
>
> Und was ist daran bedenklich?

Sie haben im Falle aller mir bekannten SSDs eine physikalische 
›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige) 
›erase-block-size‹ von 2MiB.
Wenn sich das Betriebssystem nach den Angaben richten würde, so könnte 
ein ›block-misalign‹ stattfinden (performance penalty, write 
amplification)

Glücklicherweise schaut Linux (und soweit ich weiß mittlerweile auch 
Win) nicht darauf und fängt bei den bereits zuvor mal erwähnten 
2048*512B also 1MiB Grenzen an.

[(prx) A. K. (prx)]

Norbert schrieb:
> Sie haben im Falle aller mir bekannten SSDs eine physikalische
> ›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige)
> ›erase-block-size‹ von 2MiB.

Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee 
war, eine Partition an Block #63 beginnen zu lassen (bis Win XP), ist 
zumindest die 4K Thematik vom Tisch. Denn die üblichen Filesysteme wie 
NTFS, ext4, xfs etc verwenden sowieso eine Blockgrösse von 4K.

Es ist wohl kein Problem, in hdparm 4K als physikalische Sektorgrösse 
anzugeben, denn das machen diverse HDDs. Aber mehr als Schmuck fürs Auge 
ist das nicht. Oder gibt es irgendeine Stelle in Betriebssystemen, die 
sich für die Angabe der physikalischen Sektorgrösse interessiert, die 
hdparm auswirft? Zumal der Mechanismus, den hdparm für 
Informationsbeschaffung verwendet, bei meiner NVMe SSD nicht 
funktioniert.

[Norbert (Gast)]

(prx) A. K. schrieb:
> Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee
> war, eine Partition an Block #63 beginnen zu lassen …

Nun, ich kann mich noch gut an MFM und RLL Controller und die dazu 
passenden Platten erinnert. Damals (letztes Jahrtausend) war es 'ne 
clevere Idee die cylinder,head,sector Informationen zu nehmen. Dann kam 
irgendwann der geschmeidige Übergang von CHS -> LBA. Der hätte einen 
wirklich harten Schnitt gebraucht.

Verdammt, jetzt bin ich deprimiert. ;-)

[(prx) A. K. (prx)]

Norbert schrieb:
> Nun, ich kann mich noch gut an MFM und RLL Controller und die dazu
> passenden Platten erinnert.

Wobei es allerdings auch Disks, die in ihrer Schnittstelle in CHS 
adressiert wurden, ziemlich schnuppe war, wo eine Partition anfing. Das 
hatte keine nennenswerten Folgen für die Performance. Partitionen an 
Zylindern auszurichten war so gesehen nie wirklich nötig.

Obendrein wurde auf der CHS-Ebene bald gelogen, dass sich die Balken 
biegen, sobald die Dinger gross genug waren um das Bitformat zu 
sprengen. Da gab es dann eine echte phsikalische Struktur und eine 
simulierte.

> irgendwann der geschmeidige Übergang von CHS -> LBA. Der hätte einen
> wirklich harten Schnitt gebraucht.

Eigentlich nicht, denn bereits die Cluster-Nummerierung des FAT 
Filesystems war von der CHS-Nummerierung losgelöst. Die Filesysteme 
waren also von Anfang an unabhängig vom physikalischen Aufbau.

[Norbert (Gast)]

(prx) A. K. schrieb:
> Eigentlich nicht, denn bereits die Cluster-Nummerierung des FAT
> Filesystems war von der CHS-Nummerierung losgelöst. Die Filesysteme
> waren also von Anfang an unabhängig vom physikalischen Aufbau.

Filesysteme ja, aber eine Etage tiefer?
Wenn ich mir den Krampf im MBR vorstelle, da haben wir selbst im 21. 
Jahrhundert noch CHS Einträge. Kein Bezug zur Realität mehr, da steht 
heute drin »Bitte weitergehen, hier gibt's nichts zu sehen«

[(prx) A. K. (prx)]

Norbert schrieb:
> Filesysteme ja, aber eine Etage tiefer?

Welche API-Ebene wäre das? Der Disk-Interrupt adressierte CHS, die 
Filesysteme lineare Cluster. Was liegt dazwischen, das eine an Zylindern 
orientierte Partitionierung sinnvoll machte? Also ausser geistiger 
Trägheit oder mangelndem Abstraktionsvermögen.

Bei IBMs Mainframes rechnete man noch ewig in Zylindern. Ein User bekam 
in den frühen Systemen einen Platz von soundsoviel Zylindern zugewiesen. 
Das hielt sich auch noch, als das längst keine echten Zylinder mehr 
waren, sondern bloss eine obskure Messeinheit für Plattenplatz.

[Rolf M. (rmagnus)]

(prx) A. K. schrieb:
> Seit Partitionierungstools kapiert haben, dass es eine saudumme Idee
> war, eine Partition an Block #63 beginnen zu lassen (bis Win XP), ist
> zumindest die 4K Thematik vom Tisch. Denn die üblichen Filesysteme wie
> NTFS, ext4, xfs etc verwenden sowieso eine Blockgrösse von 4K.

Ja, umso unsinniger ist es ja, wenn zwischen den logischen 4k-Blöcken 
des Dateisystems und den internen 4k-Blöcken der Platte ein Layer liegt, 
das das in imitierte 512-Byte-Sektoren um- und wieder zurückwandelt.
Es gibt ja durchaus Festplatten, die 4k-Sektoren haben und die auch nach 
außen als solche durchreichen. Aber das scheint außer Mode gekommen zu 
sein. Probleme mit Alignment der Sektoren kommen wie gesagt auch nur 
dadurch. Warum man allerdings ausgerechnet Sektor 63 als Start gewählt 
hat, hab ich auch nie verstanden.

> Es ist wohl kein Problem, in hdparm 4K als physikalische Sektorgrösse
> anzugeben, denn das machen diverse HDDs. Aber mehr als Schmuck fürs Auge
> ist das nicht. Oder gibt es irgendeine Stelle in Betriebssystemen, die
> sich für die Angabe der physikalischen Sektorgrösse interessiert, die
> hdparm auswirft? Zumal der Mechanismus, den hdparm für
> Informationsbeschaffung verwendet, bei meiner NVMe SSD nicht
> funktioniert.

Funktioniert er wirklich nicht, oder gibt die SSD einfach nur 
Phantasiewerte an?

[(prx) A. K. (prx)]

Rolf M. schrieb:
> Funktioniert er wirklich nicht, oder gibt die SSD einfach nur
> Phantasiewerte an?

 HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device

[Rolf M. (rmagnus)]

Hast du es mal mit smartctl versucht?

[(prx) A. K. (prx)]

nvme id-ns:

 LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)

smartctl:

Model Number:                       Samsung SSD 970 EVO Plus 1TB
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1.000.204.886.016 [1,00 TB]
Namespace 1 Utilization:            377.055.621.120 [377 GB]
Namespace 1 Formatted LBA Size:     512

[>>> (Gast)]

> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.
> Device     Boot Start        End    Sectors Size Id Type
> /dev/sde1           1 4294967295 4294967295   2T ee GPT

> Partition 1 does not start on physical sector boundary.
> Zurück am U20 Server bleibt die Platte genauso ohne Partition.


sde1 ist doch die Partion, GPT ist der Typ.

Soll er sdpasseshalber den nächsten Superblock nehmen,
der jenseits der  gpt liegt. mount auf den Weg geben.

dumpe2fs /dev/sde1 |grep -i superblock

mount ... sb=xy ...

---

[Tim S. (Firma: tsx89) (freak_ts)]

Ich habe ab und zu auch das Problem wie der TO. Es kam hier zwei mal vor 
bis jetzt. Linux Ext FS kopiert zuerst den Inhalt in Blöcken, und 
schreibt erst danach die 'sichtbaren Dateien' (zugewiesen zu den 
Blöcken) in das Dateisystem Journal - Mehr oder weniger.

Es schreibt aber leider den neuen Datei Index nicht immer in sein 
Journal. Und aktualisiert das Dateisystem nicht. Der Inhalt der Datei 
ist aber (irgendwo in den Blöcken) vollständig vorhanden.

Am problematischsten ist es, wenn man einen Ordner mit vielen Dateien 
darin kopiert: Es sind ggf alle Dateien vorhanden, aber der eigentliche 
Ordner ist nirgendwo zu sehen. Und somit hat man keinen Zugriff.

Man soll ja das Kommando 'synch' absetzen, um den Festplattencache 
fertig rein zu schreiben bzw zu leeren. Um ggf noch offene schreibende 
'Filehandles' zu schließen. Vor allem bei USB und Hotplug Geschichten. 
Aber trotz sauberen 'unmount' und sogar 'synch' danach, gibt es 
irgendwie "Verluste".

Habe mir daher angewöhnt, den Rechner komplett herunter zu fahren. Da 
klappt es bislang immer. Aber bei Servern ist das natürlich 
ausgeschlossen.

Man kann es anscheinend umstellen, dass Linux zuerst das Journal noch 
vor den Blöcken schreibt. (Wie bei Windows) Der Nachteil ist aber, falls 
das Kopieren abbricht (Stromausfall usw) dass dann Schrott im Filesystem 
steht und Speicher irgendwie reserviert ist, zudem es aber keinen 
richtigen Bezug in den Blöcken gibt. (...weil es noch nicht kopiert 
wurde, aber trotzdem als 'falsche' und 'fehlerhafte' Datei im System 
auffindbar ist.)

Hat jemand eine Idee was man da noch machen oder optimieren kann?

[bingo (Gast)]

Norbert schrieb:
> Sie haben im Falle aller mir bekannten SSDs eine physikalische
> ›sector-size‹ von mindestens 4096B (4KiB) und eine (weniger wichtige)
> ›erase-block-size‹ von 2MiB.

Dann sind hier Dein 1. und 2. Fall (zugegeben schon etwas betagt):

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-84-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Plextor M3/M5/M6/M7 Series SSDs
Device Model:     PLEXTOR PX-128M6S
Serial Number:    P02413100098
LU WWN Device Id: 5 002303 1001988aa
Add. Product Id:  HC7020R0
Firmware Version: 1.08
User Capacity:    128.035.676.160 bytes [128 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ATA/ATAPI-7 T13/1532D revision 4a
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Sep 15 16:21:34 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

.

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-84-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SV300S37A120G
Serial Number:    50026B7759094800
LU WWN Device Id: 5 0026b7 759094800
Firmware Version: 603ABBF0
User Capacity:    120.034.123.776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Sep 15 16:24:42 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

[bingo (Gast)]

Tim S. schrieb:
> Aber trotz sauberen 'unmount' und sogar 'synch' danach, gibt es
> irgendwie "Verluste".

Andersrum: zuerst sync und dann umount

[(prx) A. K. (prx)]

Wobei ein umount den sync bereits enthält.

[bingo (Gast)]

(prx) A. K. schrieb:
> Wobei ein umount den sync bereits enthält.

Sollte theoretisch so sein, ich bin ich mir aber nicht sicher.

[>>> (Gast)]

bingo schrieb:
>>>> schrieb:
>> bingo schrieb:
>>> Das Problem ist, dass /dev/sde1 am Sektor 1 beginnt, da stimmt das
>>> Alignment nicht. Evtl. hast Du die Platte mit einem alten Programm
>>> partitioniert, mach das mal mit einem neuen Gparted. Vor dem 1.
>>> benutzten Sektor sollten 2048 Sektoren frei sein!
>>>
>>
>> Wenn du Booten willst. Üblich, muss aber nicht so sein.
>> Einfach vielfache von 8 (4096/512) sollten es auch tun.
>> (g)parted kann man auch irgendeinen passenden Start geben,
>> z.B. verschieben auf Anfang 8Mb sollte so ein Prob. auch lösen.
>> Dann spielt auf die Sektorgröße auf anderem System keine Rolle.
>
>
> Seine Partitionen fangen aber bei Sektor 1 an, das ist ganz schlimm, das
> konvergiert weder mit 512- noch mit 4k-Sektoren, denn die Nummer des 1.
> Sektors auf der Platte (HDD oder SSD) ist 0 !!!

Nö.

Sektorgröße logisch/physisch u. Wahl des Startsektor haben mit dem 
Problem hier doch nichts zu tun. GPT das warum auch immer hier die 
gesamte Platte einnimmt ist halt kein extFS, 83/LINUX
Falls da drin tatsächlich ein extFS drinstecken sollte wird z.B. 
dumpe2fs die Signaturen schon finden, wenn nich gibts dort auch keine 
Daten, wo immer sie dann auch gelandet sein mögen.



Dein Vorredner hatte das schon richtig erkannt:
>>> Was da angezeigt wird ist eine GPT Protektive Partition in einem
protektiven MBR.
----


>>>> Ich habe ab und zu auch das Problem wie der TO.
?

>>>> Es kam hier zwei mal vor

Darin erschöpft sich die Geminsamkeit ;)

[Norbert (Gast)]

bingo schrieb:
> (prx) A. K. schrieb:
>> Wobei ein umount den sync bereits enthält.
>
> Sollte theoretisch so sein, ich bin ich mir aber nicht sicher.

Iss so!
Aber der Hardware Buffer könnte (rein theoretisch) eventuell bei 
externen USB-Drives noch Probleme machen. Habe ich aber noch nie 
beobachten können.

hdparm -fF <device>
 -f     Sync and flush the buffer cache for the device on exit.
 -F     Flush the on-drive write cache buffer

[Rolf M. (rmagnus)]

>>> schrieb:
>> stecke die Platte an ein Ubuntu 16 Rechner und sehe keine Partition.
>> Device     Boot Start        End    Sectors Size Id Type
>> /dev/sde1           1 4294967295 4294967295   2T ee GPT
>
>> Partition 1 does not start on physical sector boundary.
>> Zurück am U20 Server bleibt die Platte genauso ohne Partition.
>
> sde1 ist doch die Partion, GPT ist der Typ.

Ja, aber GPT ist der Typ der Partitionstabelle. Normalerweise müsste da 
der Typ der Partition stehen.

[Bauform B. (bauformb)]

Rolf M. schrieb:
>> sde1 ist doch die Partion, GPT ist der Typ.
>
> Ja, aber GPT ist der Typ der Partitionstabelle. Normalerweise müsste da
> der Typ der Partition stehen.

Nicht aber, beides heißt abgekürzt GPT. Als Partitionstyp (ID ee) ist 
GPT die Abkürzung für "Dies ist eine Partition, in der man 
GPT-Partitionen verstecken kann".

Alte Programme und Betriebssysteme, die keine GPT-Tabelle kennen, sehen 
genau eine unbekannte Partition. Aktuelle Software ignoriert den alten 
MBR und liest die GPT-Tabelle.

Edit:
https://en.wikipedia.org/wiki/GUID_Partition_Table#Protective_MBR_(LBA_0)

[>>> (Gast)]

�� DPA �� schrieb:

> z.B. gdisk
>

hat eine interessante Option das Tool;

recovery and transformation
GPT to MBR  (r,g,[w])

g

Convert  GPT  into  MBR and exit.
This option converts as many partitions as possible into MBR form,
destroys the GPT data structures, saves the new MBR, and exits.
Use this option if you've tried GPT and find that  MBR  works better for 
you....


----

Kommt halt drauf an was und wieviel tatsächlich drauf ist
 und ob es ins alte Schema paßt.

thanks, bye.

[dummschwaetzer (Gast)]

>Device     Boot Start        End    Sectors Size Id Type
>/dev/sde1           1 4294967295 4294967295   2T ee GPT

Das ist die Information des MBR in Sektor 0.
Der macht eine Partition des Typs GPT (ID 0xEE) von Sektor eins bis zum 
letzten Sektor. Dadurch ist die komplette Platte "voll"

Dein BS sollte also so clever sein,die GPT einzulesen, und diese 
Informationen zu nutzen.

Idee: steht eventuell in deinem Sektor 0 am Ende (Adresse 510..511) 
nicht 55 AA