XFS: Mount überschreibt Optionen für Sunit und Swidth

2744
Sauron

Ich habe eine 9-TB-XFS-Partition, die aus vier 3-TB-Festplatten in einem RAID-5-Array mit einer Blockgröße von 256 KB besteht und MDADM verwendet.

Als ich die Partition erstellt habe, wurden die optimalen Werte für Stripe-Einheit und Breite (64 und 192 Blöcke) automatisch ermittelt und eingestellt. Dies bestätigt xfs_info:

# xfs_info /dev/md3 meta-data=/dev/md3 isize=256 agcount=32, agsize=68675072 blks = sectsz=512 attr=2 data = bsize=4096 blocks=2197600704, imaxpct=5 = sunit=64 swidth=192 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=64 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

Ich hatte jedoch langsame Übertragungsgeschwindigkeiten, und bei der Untersuchung fiel mir auf -o sunit=64,swidth=192, dass die Stripe-Einheit immer auf 512 und die Breite auf 1536 eingestellt ist, wenn ich die Partition nicht speziell mit einhänge.

# umount /dev/md3 # mount -t xfs -o rw,inode64 /dev/md3 /data # grep xfs /proc/mounts /dev/md3 /data xfs rw,relatime,attr2,delaylog,inode64,logbsize=256k,sunit=512,swidth=1536,noquota 0 0

Ist das beabsichtigtes Verhalten? Ich vermute, ich könnte es einfach sunit=64,swidth=192jedes Mal mit dem Einhängen beginnen, aber würde dies nicht dazu führen, dass die aktuellen Daten (die geschrieben wurden, während sie eingehängt wurden sunit=512,swidth=1536) falsch ausgerichtet sind?

Das Betriebssystem ist Debian Wheezy mit dem Kernel 3.2.51. Alle vier Festplatten sind Festplatten mit fortgeschrittenem Format (sagt Smartctl 512 bytes logical, 4096 bytes physical). Die Tatsache, dass die Werte mit 8 multipliziert werden, lässt mich fragen, ob dies etwas mit dem Problem zu tun hat, da es mit dem Multiplikationsfaktor zwischen 512 und 4096 Festplatten mit Sektorengröße übereinstimmt.

Kann jemand etwas Licht auf dieses werfen? :-)

2
Einhängeoptionen können vorhandene Daten nicht relativ zur zugrunde liegenden Blockgerät-Stripe-Geometrie verschieben. Entweder sind Ihre Daten auf der Festplatte ausgerichtet oder nicht. Glücklicherweise ist das Ausrichten für Schreiben auf RAID5 viel wichtiger als für das Lesen. Es handelt sich also nicht um ein Problem, außer für Dateien wie VM-Images, Swap-Dateien oder andere Dateien, die möglicherweise vor Ort neu geschrieben werden (OHNE Kürzung, z. B. dd `conv = notrunc`). Peter Cordes vor 9 Jahren 0
Informationen zum Erstellen von XFS auf RAID finden Sie unter https://raid.wiki.kernel.org/index.php/RAID_setup#XFS, falls die automatische Erkennung der zugrunde liegenden Stripe-Geometrie nicht funktioniert hat. Peter Cordes vor 9 Jahren 0
Große Streifengrößen sind heutzutage für die meisten Dinge geeignet. 512k Streifenbreite ist angemessen. E / A-Befehle, die an Hardware gesendet werden, können in ziemlich großen Einheiten ausgeführt werden, so dass kleinere Stripe-Größen dazu neigen, zu kleineren Hardware-Befehlen zu führen, als dies optimal wäre. Es gibt einige alte Sachen auf https://raid.wiki.kernel.org/index.php/Performance, und einige der Links sind tot. Kleine Chunks für RAID5 können gerechtfertigt sein, wenn Sie über eine schreibintensive Workload verfügen, die es ermöglicht, Anforderungen in sequenziellen Chunks bis zu einer bestimmten Größe zu bündeln, jedoch nicht größer. Legen Sie die Chunk-Größe fest, um aus einem Schreib-Cover einen vollen Streifen zu machen. Peter Cordes vor 9 Jahren 0

1 Antwort auf die Frage

3
Trevor Cordes

Ihr Rätsel Multiplikation-by-8 liegt darin, dass xfs_info in B-Size-Blöcken Sunit / Swidth zeigt, normalerweise 4096 Bytes. Wenn Sie sunit / swidth in mount mit -o oder fstab angeben, werden sie in 512-Byte-Einheiten angegeben. Beachten Sie die Zeichenfolge "blks" nach den sunit / swidth-Nummern in Ihrer Beispielausgabe xfs_info. 4096/512 = 8, daher der Mystery-Multiplikator.

man 5 xfs schreibt dies in der sunit-Zeilengruppe genauso wie mkfs.xfs in Bezug auf 512B-Einheiten.

man xfs_growfs, die auch als Manpage für xfs_info dient, beschreibt, wie die Einheiten für xfs_info bsize bytes sind.

Verwirrend, ja. Sehr schlechte Designauswahl aus Sicht der Benutzeroberfläche, ja.

Die Angabe von "-o sunit = 64, swidth = 192" war wahrscheinlich eine schlechte Idee, da Sie eigentlich 64/8 = 8 und 192/8 = 24 wollten. Möglicherweise haben Sie die 8-fach höheren Werte in den FS "hartcodiert", nachdem sie jetzt mit den größeren Zahlen montiert wurden. Die Manpage ist ziemlich explizit, dass man nie zu einem niedrigeren Sunit wechseln kann. Sie könnten jedoch wahrscheinlich versuchen, zu sehen, ob Sie Mount-Fehler erhalten. Mount für XFS sollte (aber keine Garantien) robust genug sein, um Ihre Daten nicht zu verzehren: Es sollte lediglich ein Fehler ausgespuckt werden, der Mount wird abgelehnt oder mit vernünftigen Optionen gemountet, wobei die angegebenen Werte ignoriert werden. Machen Sie zuerst Sicherungen.

Das heißt, mit 8-fach größeren Sunit / Swidth-Werten ist tatsächlich nichts auszusetzen, da es hier um Ausrichtung geht und diese Zahlen immer noch ausgerichtet sind. Möglicherweise gibt es Fragmentierungsprobleme oder Probleme, wenn die meisten Ihrer Dateien winzig sind.

Nebenbei: Woran ich gerade arbeite und es faszinierend finde, was Sie ändern sollten, wenn Sie Ihr MD-RAID vergrößern / umgestalten, indem Sie 1 Festplatte hinzufügen. Auf der Manpage wird angezeigt, dass Sie Sunit nicht ändern können, es sei denn, Sie verdoppeln buchstäblich die Anzahl der Festplatten. Es scheint jedoch, dass die Änderung von swidth noch möglich ist. Ob dies in den meisten Fällen zu einer korrekten Ausrichtung führt, bleibt abzuwarten. Informationen von Leuten, die dies tatsächlich tun, scheinen rar zu sein.

http://xfs.org/index.php/XFS_FAQ#Q:_How_to_calculate_the_correct_sunit.2Cswidth_values_for_optimal_performance. Die Mount-Optionen liegen in Einheiten von 512B vor. Die korrekte Einstellung für seine HW lautet "sunit = 256 * 1024/512 = 512" und "swidth = sunit * 4 = 2048". Peter Cordes vor 9 Jahren 0
re: Umformung nach dem Hinzufügen einer RAID-Disk. Richtig, Sunit ändert sich nicht, nur die Weite. sunit ändert sich nur, wenn Sie "mdadm --grow --chunk something_new" verwenden. Und mach dir keine Sorgen. Wenn Sie es falsch verstehen, schreiben Daten und Metadaten langsamer, während ein FS mit einer Geometrie gemountet wird, die nicht mit dem zugrunde liegenden Speicher übereinstimmt. Es besteht jedoch keine Möglichkeit, dass dies zu Datenverlust führt. Und geringe Wahrscheinlichkeit, dass die Leseleistung beeinträchtigt wird, wenn Sie die Daten später verwenden. Peter Cordes vor 9 Jahren 0
Hey, a Cordes. Ich weiß, dass Kommentare nicht der richtige Ort für eine Diskussion sind, aber ich treffe eigentlich nie jemanden mit demselben Nachnamen, auch online. Peter Cordes vor 9 Jahren 0

Verwandte Probleme