Re: dd und Dateisystem

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Mon, 7 Dec 2009 22:55:57 +0100

On Mon, Dec 07, 2009 at 08:53:19PM +0100, Oliver Fromme wrote:
>
> Polytropon wrote:
> > Oliver Fromme wrote:
> > > Außerdem kann sich durch diese Aktion der Fragmentierungs-
> > > grad des Dateisystems erhöhen.
> >
> > Fragmentierung... das letzte mal, daß ich dieses Wort
> > gehört habe, hatte das irgendwas mit DOS oder "Windows"
> > zu tun;
>
> Fragmentierung bei FAT ist etwas völlig anderes als bei UFS.
> Das eine hat mit dem andren kaum etwas zu tun, außer dem
> gleichen Wort.
>
> > unter FreeBSD ist es mir bis dato noch nicht begegnet,
>
> Es begegnet Dir bei jedem Boot-Vorgang. Beispiel:
>
> Starting file system checks:
> /dev/mirror/gm0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mirror/gm0s1a: clean, 481895 free (2655 frags, 59905 blocks, 0.5% fragmentation)
> /dev/mirror/gm0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mirror/gm0s1d: clean, 4963344 free (1104 frags, 620280 blocks, 0.0% fragmentation)
> /dev/mirror/gm0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mirror/gm0s1e: clean, 4121557 free (115645 frags, 500739 blocks, 2.3% fragmentation)
> /dev/mirror/gm0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mirror/gm0s1f: clean, 45588244 free (38252 frags, 5693749 blocks, 0.1% fragmentation)
>
> Die 2.3% beim dritten Dateisystem sind schon relativ viel,
> was aber in diesem konkreten Fall zu erwarten ist, da es
> sich um die Partition handelt, auf der sich u.a. ports,
> src, obj und ein paar andere »eklige« Sachen befinden.
>
> > obwohl ich mir durchaus vorstellen kann, daß
> > auch hier im Prinzip ein solches "Problem" vorliegen
> > kann (Problem ja nur bei massiver Fragmentierung).
>
> Bei UFS bezeichnet man als Fragmentierung den Anteil der
> Blöcke, die Fragmente enthalten, am Gesamtplatz. fsck
> zeigt sie an (z.B. beim Booten, siehe oben). Man kann
> den Wert auch im laufenden Betrieb errechen, indem man
> sich die Ausgabe von dumpfs(8) anschaut, z.B.:
>
> # dumpfs /dev/ad0s1a | head
>
> Der Anteil von "nffree" an "blocks" ergibt den gleichen
> Prozentwert, den fsck ausgibt.
>
> Die Fragmentierung hat einen erheblichen Einfluss darauf,
> ob ein UFS-Dateisystem bei der Belegung neuer Blöcke nach
> Zeit oder Platz optimiert (time vs. space optimization).
> Sie ist also maßgeblich für die Performance.
>
> Wenn man beim newfs die Werte für -f -und -v gleichsetzt
> (d.h. Fragment- und Blockgröße sind gleich), kann keine
> Fragmentierung entstehen. Sie ist dann immer 0%, und es
> wird immer nach Zeit optimiert. Der Nachteil ist dann
> natürlich der Platz-Verschnitt. Lohnen tut sich so eine
> Einstellung für Dateisysteme, auf denen hauptsächlich
> wenige, große Dateien liegen sollen (etwas Multimedia-
> Daten, Images o.ä.). Dann sollte man auch die inode-
> Dichte reduzieren (Option -i bei newfs). Dadurch wird
> auch das fsck im Fall der Fälle deutlich beschleunigt.

Neben der Tatsache, dass die space-Optimierung die Bildung von
Fragemnten fördrt gibt es das klassische FAT Problem auch noch.
Der Unterschied bei UFS ist nur, dass es Dateifragmentierung zum Teil
erzwingt und nicht stupide linear vollschreibt, wie FAT und dadurch
später die Fragmentierung zu reduzieren.
Ein FAT fragmentiert sich von selber massiv, was bei UFS ausbleibt,
solange es eben nicht voll ist.
Dieser Mechanismuss wird durch das vollmachen nämlich gestört.
Außerdem kann man die vorher angesprochenen Blockfragmente damit
nicht nullen.

> Oder halt -- wie gesagt -- ZFS verwenden. Dann muss man
> sich um das alles keinen Kopf machen. :-)

Dafür um diverse andere Sachen.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 07 Dec 2009 - 22:56:06 CET

search this site