Re: newfs: -f frag-size

From: Martin Cracauer <cracauer(at)cons.org>
Date: Mon, 10 Apr 2000 13:10:25 +0200

In <owner-de-bsd-questionsATDE.FreeBSD.ORG--001401bfa138$e87ab6a0$bdff08c3(at)bitracer>, "Stefan Fischer" wrote:
> Kann mir einer oben genannte Option genauer erklären? Ich wollte beim
> Erstellen wie unter Linux gewohnt die Blocksize und Bytes/inode
> einstellen um die Performance (Read/Write wie auch CPU-Last) ein
> bisschen zu optimieren, nun entdecke ich aber eben diese Möglichkeit,
> welche ich unter Linux (welches ich aber seit 1 Jahr nicht mehr nutze)
> nicht kannte.
 
BSD FFS kann die Enden von mehreren Files zusammen in einem Block
speichern. Das spart Plattenplatz.

Angenommen, Du hast eine Blockgroesse von 8 KB und Dein Filesystem so
angelegt, dass 4 Fragmente mit je 2 K moeglich sind.

Wenn Du dann 4 Files hast, die jeweils (> 8KB && <= 10KB) sind, dann
passen diese 4 Files in 5 Bloecke, verbrauchen also 40KB, weil alle 4
Enden < 2KB zusammen in einen Block gestopft werden. Wenn Du keine
Fragmente zulaesst, dann wuerde jedes File 2 Bloecke brauchen, also 8
Bloecke, also 64KB. Wenn Du viele kleine Files hast
(z.B. traditioneller Newsspool, CVS-Trees, ausgepackte Sourcen), dann
kann das ganz schoen was am Plattenplatz ausmachen.

Das ext2fs keine Fragmente kann ist uebrigens auch der Grund fuer die
hirnlos kleinen Bloecke, die ueberlicherweise in Linux verwendet
werden. Bei 8 KB Blockgroesse und ueberlichen durchschnittlichen
Filegroessen wuerde von einer Platte ca. 30% verschenkt werden. Das
war 1994-1995 nicht tragbar und seither sind die Linuxer fast immer
mit 2KB Bloeckgroesse dabei. Auf Platten mit megabyteweise Cache...

Die Performanceauswirkungen hab ich nie gemessen, denke aber dass sie
eher klein sind, weil die Fragmentiererei nur einmal pro File vorkommt
und das Lesen kaum behindert. Bei groessen Files (bei denen ich die
Performance brauche) ist's also wurscht und wer staendig viele kleine
FIles schreibt sollte seine Anwendung, nicht sein Filesystem aendern.

Auswirkungen haben die Fragmente aber auf die Empfindlichkeit gegen
Schaeden bei Crashes. Fuer hoechste Ansprueche an Zuverlaessigkeit
sollte man die Fragmente ganz weglassen (Empfehlung John Dyson).
Zusammen mit Softupdates wird das weglassen von Fragmenten sicherlich
dazu fuehren, dass die Softupdates im Crashfall zeitlich wesentlich
naeher am letzten Stand waren als wenn noch Fragmente
hinterhergehechelt wuerden (meine Theorie). Fragemente zusammen mit
asychronen Metadaten a'la' Linux sind auf jeden Fall Selbstmord. Wer
IDE - Platten und/oder kein Parity/ECC - Ram hat, der kann sich die
Muehe allerdings schenken, dann sind andere Fehlerquellen weit
dringlicher.

> Auch ein Hinweis über Dokumentationen in Sachen Auswirkungen der Options
> in Bezug auf die Performance wäre mir recht...

Ich habe traditionell oft an den Parametern rumgebastelt, aber bei
modernen Maschinen und modernen Platten nuetzen die Aenderungen
eigentlich nur was, wenn man nur eine Anwendung auf dem Filesystem
faehrt, und dann auch nicht viel. Die Defaultoptions sind fuer alle
Anwendungen ziemlich gut und oft hat Tuning fuer eine Anwendung zur
Folge, dass diese minimal schneller und viele andere wesentlich
langsamer werden.

Bei den defaultoptions zu bleiben hat auch den Vorteil, dass man dem
Pfad folgt, der am besten ausgetrampelt ist. Wer z.B. von den 8K
Blockgroesse abweicht, kann in ggf. mal gebissen werden, wenn ein
Committer irgendwo gebastelt hat und nur mit defaults getestet hat.

Gilt wie ueblich noch mehr fuer Linux. Als ich testweise mal ext2fs
mit > 2KB Bloeckgroesse auf dem Software-RAID probiert habe, hagelte
es Panics und auch Datenverluste (Filesystem sortiert die Bloecke
nicht mehr richtig zu Files).

Martin

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 10 Apr 2000 - 13:11:07 CEST

search this site