Re: FS-Fragmentierung

On Sat, Apr 06, 2002 at 10:26:47AM +0200, Peter Ross wrote:
> Hallo,
>
> als Admin (wenn es denn sein muss, auch mal Win NT), bin ich auch Leser
> einer NT-Liste. Dort wurde die Frage nach einem Defragmentierer gestellt.
>
> Mein seit etwa zwei Jahren laufendes FreeBSD-System behauptet bei "fsck
> -p" (z.B. beim Booten) 0,0% (/), 0,2% (/usr) und 0,6% (/var)
> Fragmentierung.

Fragmente nicht Fragmentierung.
FreeBSD plaziert Dateien in Blöcke (default 8k) und das Ende bei
Bedarf in einen Teilblock auch Fragment genannt.
Ein Fragment ist default n*1k groß und kleiner als ein Block.
Eine 8205 Byte große Datei belegt also einen 8k Block und ended mit
einem 1k Fragment.
Wird die Datei größer und das Fragment kann nicht vergrößert werden
wird dieses neu allociert.
Zumindest unter -current haben sich die defaults allerdings geändert
und hängen von der Partitionsgröße ab.
Physikalische Blöcke werden übrigens bei *BSD Sektor genannt.

> Ich habe eigentlich immer vorausgesetzt, daß sich der FS-Treiber um eine
> sinnvolle Plazierung der Daten auf der Platte kümmert, so daß
> Defragmentierer kaum sinnvoll sind (unter Unixen ist mir auch nie einer
> begegnet).

FreeBSD Fragmentiert Dateien absichtlich.
D.h. die Partition wird in gleichgroße Teile sog. Zylindergruppen
aufgeteilt. Wenn nun eine Datei n Blöcke in einer Zylindergruppe
belegt werden weitere Blöcke in einer anderen Zylindergruppe belegt.
Das hat den Vortteil, das andere Dateien die in der gleichen
Zylindergruppe liegen noch Platz zum Lokalen erweitern finden.
UFS braucht dafür statistisch 20% freien Platz.
FreeBSD geht mit 10% Zwangsreserve einen Kompromiss ein.
Andere Systeme wie NetBSD und Solaris machen sogar noch weniger.
Wenn man (z.B. als root) ein Filesystem volllaufen läßt kann die
Strategie nicht funktionieren und es dauert einige Zeit bis sich
das Filesystem davon wieder erholt.
Am besten löscht man die während dieser Engphase entstandenen Dateien,
da ja genau diese Fehlplaziert werden mussten.

> Nun verwendet auch die Firma Microsoft seit einiger Zeit ein Filesystem
> (NTFS) statt dem Uralt-FAT-Kram, ich vermute mal, daß es sich dabei um
> eine Implementation handelt, die ein wenig von den Entwicklungen auf dem
> Gebiet ringsum profitiert hat und nicht ganz Steinzeitniveau besitzt.

Microsoftjünger sind geil auf Platz und Microsoft hat auf die
Zwangsreserve verzichtet.
Im Grundegenommen hat aber auch Microsoft einige gute Methoden
um die Fragmentierung zur Laufzeit in den Griff zu bekommen.
Bei vollen Platten können aber auch diese nur wenig greifen.
Nicht zuletzt hat NTFS durch die grundsätzlich verwendeten
ACL Listen einen größeren Metadatenbedarf, was FreeBSD in der Inode
abwickelt.
Problematisch ist allerdings auch die Echtzeitkomprimierung oft
geänderter Dateien, da die Kompressionsabschnitte dann oft Ihren
physikalischen Platzbedarf ändern.
Die typischen Defragmentierer für NT lesen Dateien und schreiben diese
gleich wieder, was die natürliche Defragmentierung des Filesystems
aktiviert und bei sachgemässer Filesystembehandlung nicht nötig
wäre.

> Danach müßten Defragmentierer auch unter neueren Microsoft-Systemen kaum
> sinnvoll sein.

Bei gut gepflegten NTFS Systemen braucht man diese normalerweise nicht.

> Liege ich mit diesen Gedankengängen irgendwo falsch?

Wer ein NTFS System gut pflegen kann wird es kaum einsetzen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message