# [Offtopic] 4kb Sektoren

## papahuhn

Hallo,

kann mir jemand das Problem bei 4kb-Sektor-Festplatten erläutern?: http://www.heise.de/newsticker/meldung/Festplatten-mit-4-KByte-Sektorgroesse-887759.html

Ich verstehe das leider nicht. Für das Mapping der emulierten 512b-Sektoren auf physische 4kb-Sektoren ist doch nicht die Partitionstabelle verantwortlich, sondern die Festplatte selbst. Und die muss das halt so regeln, dass ein emulierter Sektor in nur einem physischen ist.

Was hat das ganze also mit Partitionen zu tun?

Gruß

----------

## kernelOfTruth

anscheinend setzt sich Windows über die physikalische Sektoren-Ausrichtung der Festplatte hinweg (wie so einiges bei Microsoft  :Wink:  )

dieses Problem gibt es aber auch unter Linux und wird zur Zeit recht fleißig auch in der btrfs mailing list diskutiert

 *Quote:*   

> muss die Platte diese zunächst lesen, den betroffenen Teil der Daten ersetzen und kann sie erst dann wieder schreiben. Das erfordert eine zusätzliche Umdrehung der Scheiben und dürfte daher massiv bremsen.

 

hört sich für mich nach COW (copy on write) an und ist bei Btrfs Standard ...

----------

## papahuhn

Hi,

ich hab inzwischen andere Artikel zu dem Thema gelesen, die auf SSDs bezogen waren; das Problem ist aber übertragbar.

Es gibt - nun auch für mich nachvollziehbar - Schwierigkeiten, wenn das Dateisystem clustert, so wie NTFS und FAT32 das machen.

Wenn ein Cluster gegen die physischen Sektorgrenzen verschoben ist, verursacht ein Clusterzugriff jeweils einen Logischer-Sektor Zugriff, aber jeweils zwei Physischer-Sektor Zugriffe.

Btrfs clustert also auch, ja? Mich würde noch interessieren, wie das mit ext3, xfs und co aussieht.

----------

## papahuhn

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sector_Hard_Drives

Einen derart hohen Einfluß hätt ich jetzt nicht erwartet ...

----------

## Hilefoks

Moin,

bei ext [2|3|4], bei NTFS und vielen weiteren Dateisystemen sind Blockgrößen von 1024, 2048 oder 4096 Byte üblich. Meist kann der Anwender beim Erstellen des Dateisystems Einfluss auf diesen Parameter nehmen (mkfs.ext[2|3|4] hat z.B. den Schalter -b).

Eigentlich würden logischer Block und physikalischer Sektor ineinander passen. Aus bestimmten "historischen" Gründen ist dies aber nicht der Fall, zwischen Partitionstabelle und dem Startsektor der entsprechenden logischen Partition ist ein Loch von 63 Sektoren.

Und genau da ist das Problem. 63 * 512 Byte = 32256 Byte. 32256 Byte ist aber kein vielfaches von 4 KByte. 

Das führt dazu das ein logischer Block über zwei physikalische Sektoren verteilt sein kann (und entsprechend häufig auch ist), diesen aber nicht ausfüllt. Wenn nun ein solcher logischer Block geschrieben werden soll, müssen zwei physikalische Blöcke zunächst gelesen werden (um die ebenfalls enthaltenen Daten zu erhalten) und können erst dann geschrieben werden. Und dieser zusätzliche Lesezugriff geht kräftig auf die Performance.

MfG,

Hilefoks

----------

## think4urs11

ein paar weitere Infos dazu: http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

----------

## bookwood

Ich bin in diese Falle getappt und habe mir eine 1,5TB Grosse SATA WD Platte gekauft und meine gesamten Daten umgezogen. Jetzt scheint das Block alignment nicht mehr zu stimmen - was man beim normalen Betrieb kaum merkt. Große Probleme treten jedoch bei VMWare auf. Ich habe unter anderem einen Virtuellen M$ Windoof XP Rechner, der braucht jetzt zum Hochfahren 45 Minuten. Mit dem System kann man fast nicht mehr arbeiten - auch virtuelle Linux Systeme frieren teilweise für 10 - 20 Sekunden ein, weil die Virtuelle Platte nicht mehr hinterher kommt.  Ich nutze unter anderem auf der neuen Platte LVM und dachte es ligt evtl. daran - Fehlanzeige. Sobald ich die alte 1TB dranhänge und die Virtuellen Maschinen von dieser in mein System mounte rennt alles wieder wie früher. Ich nutze übrigens XFS.

Folgendermassen habe ich es getestet:

```
emerge iozone

time iozone -a  -i 0 -i 1 >out.txt
```

Iozone ist ein Disk Benchmark der auf Dateisystem Ebene Arbeitet (die Daten in out.txt kann man mit gnuplot visualisieren). Bei einem meiner Kunden, er fährt eine Gentoo Maschine mit Software Raid1 LVM und XFS, braucht der Test 5 Minuten, bei meiner alten Platte 7.5 Minuten. Auf meiner neuen Platte 35 - 40 Minuten. Ein Freund von mir hatte ähnliche Symptome und dort brauchte der Test 75 Minuten. Ein 

```
dd if=/dev/zero of=/test.dd bs=64 count=1000000

1000000+0 Datensätze ein

1000000+0 Datensätze aus

64000000 Bytes (64 MB) kopiert, 1,68868 s, 37,9 MB/s

```

 ist hingegen genauso schnell wie eine SATA Platte sein sollte. Das Problem tritt dann zu Tage wenn viele kleine Stellen geschrieben und dann wieder gelesen werden. Werden grosse Mengen in einem Rutsch geschrieben verhält sich die Platte normal.

Ich hoffe dieser Test hilft anderen nicht in die gleiche Falle zu tappen.

----------

## slick

Ich fände es sehr hilfreich wenn mal einer von euch jetzt zusammenfassen könnte was das konkret für die Praxis bedeutet. 

Also falls jemand sich so eine Platte gekauft hat, was muss er jetzt tun, beachten, etc?

----------

## bookwood

Die Lösung besteht aus einer geänderten Geometrie, die die Partitions Anfänge immer durch 4k Teilbar schreibt:

```
fdisk -H 224 -S 56 /dev/sdX
```

Das kann allerdings bei einem Dualboot System mit Window$ zu Problemen führen (WD stellt für XP ein Tool bereit). Meine ist übrigens eine WDC WD15EARS-00Z5B1 1.5 TB Platte. Fdisk meckert zwar das die Werte nicht mit den empfohlenen vom Kernel übereinstimmt, da die WD Platte dem Kernel Schei... erzählt (Die Hardware dröselt die 4K Sektoren wieder in 8 512 Byte Sektoren um - aus kompatibilitäts Gründen   :Confused:  warum auch immer ). 

Alle Infos habe ich unter http://www.brain4free.org/wiki/doku.php/blog:wd_advanced_format_hd_mit_linux gefunden. Iozone liefert wieder normale Werte:

```
# time iozone -a  -i 0 -i 1 >out.txt

real    5m56.898s

user    0m0.520s

sys     1m4.040s
```

Es soll in Kürze ein neues fdisk rauskommen, welches die Probleme beseitigt. Ich habe linux-tools-ng versucht zu kompilieren - es geht aber nur mit einem Kernel >2.6.31, zumindest brach er bei mir immer mit einem komischen Fehler beim kompilieren ab.

Sorry, das ich erst jetzt die Lösung poste, aber ich musste mir erstmal 1.5TB Platten organisieren um mein System von der WD Platte zu sichern  :Sad: 

----------

## py-ro

Das mit der Geometrie ist kein guter Tipp, ich weiss das er oft verklinkt ist, in der Diskussion auf der Mailingliste wird auch irgendwo erklärt warum es eine schlechte Idee ist.

Bei einem neuen fdisk reicht ein bestimmter Parameter um an MB grenzen auszurichten, welcher in ganz neuen Versionen auch der Standard ist.

Leider habe ich gerade keine Zeit die Quellen heraus zu suchen.

Py

----------

## bookwood

Ich kann nach einem Wochenende Testen mit der veränderten Geometrie keine Probleme feststellen. Das System läuft schnell und stabil. Eine kleine Anmerkung jedoch noch am Rande. Ich nutze nur 4 Primäre Partitionen, wobei ich auf sda3 mein Root Filesystem habe, und auf sda4 den gesammten Rest mit LVM nutze. Die anderen beiden für /boot und swap. Alle weiteren von mir benötigten Partitionen sind als LVM's definiert und somit 4Kib mässig korrekt ausgerichtet. 

Für die VMWare Nutzer noch ein kleiner Tipp: Ich habe mit XFS und 4K Blöcken für die Partition auf der die Gast Systeme laufen, die beste Erfahrung gemacht. Definiert man dort eine Virtuelle Platte und partitioniert sie, ist diese natürlich auch wieder falsch aligned. Es gelten hier die gleichen Regeln wie für das Hauptsystem. Für ein Linux Gastsystem geht man wie oben beschrieben vor, für ein Window$ XP Gastsystem ist hier ein Szenario bei Western Digital beschrieben (habe ich allerdings noch nicht getestet): http://support.wdc.com/product/download.asp?groupid=805&lang=en

----------

## mattes

http://lwn.net/Articles/377895/

----------

