Hallo Sysadmins,

Defragmentieren, Reorganisieren … OK: nennen wir es Optimieren.

All das geht bei VxFS natürlich online!

So um das Jahr 2000 habe ich mal für einen Automobilzulieferer zwei damals schon veraltete SUN Ultra 1 als Web Proxy Server mit squid aufgesetzt. Die hatten leider kein Kleingeld für ein VxFS übrig und UFS machte zwei Probleme: Durch die hohe Anzahl an kleinen Files musste das UFS mit einer höheren Anzahl von Inodes angelegt werden. Sonst waren die Inodes schon voll, aber eigentlich wäre noch Platz für Daten da. Tja und nach jeweils ca. 4 Wochen war das UFS Filesystem so defragmentiert, das ein “newfs” fällig war. Beides wäre damals schon mit VxFS vermeidbar gewesen.

Es gibt zwei Arten der Optimierung:

• für Verzeichnisse

fsadm -F vxfs -D <mountpoint>

zeigt einen “Directory Fragmentation Report” an:

hugo.global:/# fsadm -F vxfs -D /hirschhome

Directory Fragmentation Report
Dirs        Total      Immed    Immeds   Dirs to   Blocks to
Searched    Blocks     Dirs     to Add   Reduce    Reduce
total          9515      6622      5412       230       276         619

fsadm -F vxfs -d <mountpoint>

führt dann die Optimierung durch:

hugo.global:/# fsadm -F vxfs -d /hirschhome
hugo.global:/# fsadm -F vxfs -D /hirschhome

Directory Fragmentation Report
Dirs        Total      Immed    Immeds   Dirs to   Blocks to
Searched    Blocks     Dirs     to Add   Reduce    Reduce
total          9515      6204      5421       221       226         227

• für Extents

fsadm -F vxfs -E <mountpoint>

zeigt wieder einen Report an:

hugo.global:/# fsadm -F vxfs -E /hirschhome
Extent Fragmentation Report
Total    Average      Average     Total
Files    File Blks    # Extents   Free Blks
99773         164           1    56827427
blocks used for indirects: 1312
% Free blocks in extents smaller than 64 blks: 0.18
% Free blocks in extents smaller than  8 blks: 0.05
% blks allocated to extents 64 blks or larger: 97.00
Free Extents By Size
1:       3933            2:       4241            4:       4235
8:       2101           16:       1567           32:       1033
64:        577          128:        485          256:        386
512:        291         1024:        215         2048:        822
4096:        273         8192:        153        16384:         82
32768:         31        65536:         23       131072:         22
262144:          9       524288:          2      1048576:          2
2097152:          1      4194304:          1      8388608:          0
16777216:          0     33554432:          1     67108864:          0
134217728:          0    268435456:          0    536870912:          0
1073741824:          0   2147483648:          0

fsadm -F vxfs -e <mountpoint>

führt die Optimierung durch:

Keine Panik, das kann eine Weile dauern, weil zum Teil mehrere Durchläufe stattfinden (kann man mit -p <passes> ändern, default ist 5; mit -s wird am Ende jeden Durchlaufs eine Zusammenfassung angezeigt).

hugo.global:/# fsadm -F vxfs -e /hirschhome
hugo.global:/# fsadm -F vxfs -E /hirschhome

Extent Fragmentation Report
Total    Average      Average     Total
Files    File Blks    # Extents   Free Blks
99798         165           1    56609775
blocks used for indirects: 1120
% Free blocks in extents smaller than 64 blks: 0.06
% Free blocks in extents smaller than  8 blks: 0.01
% blks allocated to extents 64 blks or larger: 97.21
Free Extents By Size
1:        529            2:        395            4:        422
8:        604           16:        589           32:        572
64:        656          128:        600          256:        559
512:        413         1024:        270         2048:        462
4096:        300         8192:        215        16384:        127
32768:         26        65536:         21       131072:         13
262144:          7       524288:          2      1048576:          1
2097152:          2      4194304:          1      8388608:          0
16777216:          0     33554432:          1     67108864:          0
134217728:          0    268435456:          0    536870912:          0
1073741824:          0   2147483648:          0

Empfohlen wird die Optimierung vor allem für Datenbank Files. Ein guter Zeitpunkt soll vor dem Backup sein.  Dabei soll eine verifizierbare Performance Steigerung zu Tage treten. Mir fehlt leider im Augenblick eine adäquate Testumgebung um hier Daten liefern zu können ….

Eine weitere Anwendung der Optimierung ist natürlich vor dem Verkleinern eines Veritas Filesystems.

Viele Grüße

Michael

Hallo Sysadmins,

vor ein paar Tagen habe ich ein VxFS Filesystem erweitert und df -h hat mir komische Werte anschließend angezeigt.  Jedenfalls meinte das der Kunde. Das Filesystem wurde um 300GB erweitert. Vorher hatten wir 20GB frei und anschließend – nein – nicht etwa 320GB sondern etwa 318GB. Der arme Kunde fühlte sich um 2GB betrogen und fing morgens um 4.30h eine lebhafte Diskussion an.

Heute ging es meinen Kollegen ähnlich. Das VxFS Filesystem war brandneu erzeugt und es gab eine signifikante Lücke zwischen ‘size’ ‘used’ und ‘avail’. Darauf hin ging die Suche los: Bei UFS (und bei ext2 unter LINUX) werden schon mal 10% des verfügbaren Platzes im Filesystem für root reserviert. Also wo bitte kann man bei VxFS bzw. bei vxtunefs die Reservierung einstellen? Die Kollegen haben einen Call bei Symantec eröffnet – bin mal gespannt was dabei raus kommt … Ein kleiner gemeiner Test für den Support

Zur Sache Schätzen:

Da VxFS unter Solaris nie als Filesystem boot fähig ist/war – machen auch Reservierungen wie bei UFS üblich keinen Sinn. Wenn root und var Filesystem vom User fast voll geschrieben wurden (bis auf den reservierten Bereich), ist es von Vorteil, wenn für den root-User noch etwas Platz übrig ist. So kann man sich noch einloggen und für Abhilfe sorgen.  Der Default Wert für UFS liegt übrigens bei (64MBytes/volumesize)*100, liegt immer zwischen 1 und max 10% und kann natürlich schon beim Erzeugen des UFS per ‘mkfs -o free=99 …. ‘ beeinflusst werden . Ebenso mit ‘tunefs -m [0-10] % <filesystem>’ geändert werden. Für VxFS gibt es das nicht!

Woher kommt er nun – der fehlende freie Plattenplatz bei leeren VxFS Filesystemen? VxFS ist ein Extent basiertes Filesystem. Es gibt keine vorher festgelegten (beim Anlegen) Strukturen von Inodes und DataBlocks wie bei UFS. Sondern nur dynamische Strukturen. Zur Verwaltung des freien Platzes gibt es eine extent_map. Das ist ein File, was für den Nutzer und auch für den Administrator im Verborgenen liegt (außer ncheck Utility). In dieser extent_map werden alle Permutationen der möglichen Extent Längen vorgehalten. Je mehr freier Platz vorhanden ist, desto größer wird diese Tabelle. Füllt sich das Filesystem im Laufe der Zeit, werden die möglichen Permutationen weniger  und die Tabelle wird kleiner. Wenn das Filesystem schließlich zu 100% gefüllt ist, wird die Tabelle nicht mehr benötigt.

Bei VxFS ist es also möglich den gesamten  Platz des Filesystems vollständig für Daten auszunutzen. Abzüglich des kleinen Bereichs der beim neu angelegten Filesystems schon als ‘used’ ausgewiesen wird. Im Gegensatz zum UFS Filesystem (gutes altes Berkeley FFS übrigens), sind die Verwaltungsinformationen relativ klein ( bei 500GB nur ca. 191M statt UFS imerhin ca. 8GB für Verwaltung). Außerdem ist durch die dynamische Struktur sichergestellt, das sowohl kleine als auch sehr große Files gut verwaltet werden können. UFS macht bei Extremwerten keine gute Figur.  Ganz zu Schweigen von den Möglichkeiten der Online Reorganisation oder auch dem Vergrößern und Verkleinern im laufenden Betrieb.

Vielleicht schreibe ich demnächst noch was über weitere Features von VxFS: Storage Checkpoints, Reorganisation oder die Konvertierung eines UFS in VxFS (das allerdings nicht Online im gemounteten Zustand). Dran bleiben und RSS Feed abonnieren …

Wer sich selber tiefer in VxFS und VxVM einarbeiten möchte, für den habe ich noch einen Buch Tip:

“Storage Management in Data Centers” von Voker Herminghaus und Albrecht Scriba. Frisch im Springer Verlag erschienen!

Viele Grüße

Michael

Hallo

Kennen Sie Dan Ariely?

Nicht? – Ändern Sie das!

Dan Ariely ist Professor für Verhaltensökomik am Massachusetts Institue of Technology (MIT). Und er schreibt Bücher. Zum Beispiel: Pedictably Irrational.Im Deutschen ein bisschen komisch übersetzt mit: Denken Hilft zwar, nützt aber nichts.

Der Mann hat Humor! Das ist eine Warnung! Wenn Sie keinen haben – mmmmmmmm – ok: googeln Sie mal nach Oliver Pocher – der gefällt Ihnen vielleicht

Abgesehen davon macht er klasse Videos. Also los geht’s:

Immer noch hier?

Ok – hier ist der Link zum YouTube Kanal von Dan Ariely.

Aber vergessen Sie nicht auch das Buch zu lesen.

Wehrte Kollegen,

wir bemühen uns ja alle darum keine bekannten Sicherheitslücken auf unseren System offen zu lassen – hoffe ich jedenfalls.  Aber unsere Chef’s und Auftraggeber sind auch nur Menschen und räumen uns manchmal nicht die nötige Zeit oder die nötige Tools ein um den Hackern den notwendigen Schritt voraus zu sein. In meinen Augen ist das eine echte Dummheit!

Ich persönlich würde lieber mit jedem Hacker der mir Lücken im System offen mitteilt ein Bierchen trinken, als ihm der Rechtsabteilung zum Fraß vorzuwerfen. Dazu braucht man natürlich “cojones”

Und wie man an diesem schönen Beispiel sieht, gibt es Unternehmen die mit ihren Sicherheitslücken angemessen umgehen:

Im übrigen empfehle ich den Genuss der Tweets von Hackerinfo auf Twitter: Macht immer wieder Spaß!

Viele Grüße

Michael