mdadm und 4k Sektoren (erweitertes Format)

Es gibt zahlreiche Fragen zu Serverfault zum Ausrichten von 4k-Sektor-Festplatten, aber eines ist mir noch nicht wirklich klar.

Ich habe mein RAID1 + LVM erfolgreich ausgerichtet. Eines der Dinge, die ich getan habe, war die Verwendung von mdadm superblock Version 1.0 (in der der Superblock am Ende der Festplatte gespeichert ist).

Die Manpage sagt dies:

Die verschiedenen Unterversionen speichern den Superblock an verschiedenen Stellen auf dem Gerät, entweder am Ende (für 1.0), am Anfang (für 1.1) oder 4K von Anfang an (für 1.2). "1" entspricht "1.0". "default" entspricht "1.2".

Ist die Standardversion 1.2 für Laufwerke mit 4.000 Sektoren ausgelegt? So wie ich es sehe, ist es nicht so, weil 4k von Anfang an + die Länge des Superblocks keine Menge von 4k ist (der Superblock ist ungefähr 200 Bytes lang, wenn ich mich richtig erinnere).

Jeder Einblick in diese ist willkommen.

bearbeiten:

unten wurde geantwortet, dass mdadm superblock 1.1 und 1.2 für die 4k-ausrichtung gedacht sind. Ich habe gerade einen Ganzgeräte-Raid erstellt mit:

mdadm --create /dev/md4 -l 1 -n 2 /dev/sdb /dev/sdd

Dann habe ich ein logisches Volume hinzugefügt:

vgcreate universe2 /dev/md4

Das Array wird mit 16 MB / s synchronisiert:

md4 : active raid1 sdd[1] sdb[0]
      1465137424 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.8% (13100352/1465137424) finish=1471.6min speed=16443K/sec

Ich bezweifle also, dass es richtig ausgerichtet ist.

(Festplatten sind 1,5 TB WD EARS. Ich habe sie in meinem Desktop-PC und sie werden mit ca. 80 MB / s synchronisiert.)

Edit2:

Hier ist - Prüfung Ausgabe:

# mdadm --examine /dev/sdb
/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 79843828:7d939cce:1c8f0b32:cf339870
           Name : brick:4  (local to host brick)
  Creation Time : Sat Jul  9 10:47:33 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 2930275120 (1397.26 GiB 1500.30 GB)
     Array Size : 2930274848 (1397.26 GiB 1500.30 GB)
  Used Dev Size : 2930274848 (1397.26 GiB 1500.30 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : dd2e3b5f:33214b96:1cb88169:25deb050

    Update Time : Sat Jul  9 10:49:06 2011
       Checksum : 4f7cd785 - correct
         Events : 1


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)

Der Datenversatz beträgt 2048 Sektoren, was durch 8 teilbar ist. Man könnte also denken, dass dies in Ordnung ist. Die Volumengruppe hat eine physische Ausdehnungsgröße von 4 MiB, die ebenfalls durch 8 teilbar ist. Dies wäre jedoch nicht einmal von Bedeutung, da die Neusynchronisierung nicht mit dem Inhalt des Geräts zusammenhängt.

Eine weitere Änderung: Es scheint kein Ausrichtungsproblem zu sein. da hdparm -t eine sehr niedrige Lesegeschwindigkeit für eine der Festplatten anzeigt (30 MB / s). Etwas anderes stimmt nicht.

Edit2: Ich erinnere mich nie daran, diesen Beitrag zu aktualisieren, als ich die Antwort gefunden habe. Alles ist gut ausgerichtet. Eine der Scheiben war kaputt. Anscheinend war es auf der letzten Etappe und sogar das brach irgendwann. Eine Ersatzdiskette hat einwandfrei funktioniert.

Ja, es ist für die 4k-Sektorausrichtung ausgelegt.

Bei den Superblocks 1.1 und 1.2 wird am Anfang jeder Festplatte Speicherplatz reserviert, damit der Superblock nicht mit Füßen getreten wird. Der Superblock-Erstellungscode erzwingt, dass dieser reservierte Speicherplatz ein Vielfaches von 4 KB ist. Alle physischen Lesevorgänge werden vom Ende dieses reservierten Speicherplatzes und nicht vom Ende des Superblocks versetzt. Dadurch bleibt die Ausrichtung für jede Sektorgröße erhalten, die sich gleichmäßig in 4 kB aufteilt.

Wenn Sie interessiert sind, ist hier der Beweis aus dem mdadm-Quellcode ( super1.c):

/* force 4K alignment */
reserved &= ~7ULL;
sb->data_offset = __cpu_to_le64(reserved);

Und dieser data_offsetParameter wird vom RAID1-Code im Kernel verwendet , um die physischen Lesevorgänge zu versetzen, z. B. im Lesepfad :

read_bio->bi_sector = r1_bio->sector + mirror->rdev->data_offset