Re: weniger inodes mit newfs: error

On Wed, Apr 17, 2002 at 10:38:34PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely9.cicely.de> wrote:
> > -b darf man nicht > 64k setzen.
>
> Ich würde es sogar vermeiden, irgendwelche Werte != 16k zu
> verwenden. Aus einer Mail von Joe Greco, in der er ein
> seltsames Fehlverhalten eines Filesystems kommentiert:
>
> <Zitat>
> | > the one unusual thing about the configuration is that the filesystem
> | > we are attempting to build on is a 136GB ccd across 4 scsi disks with
> | > the fsize=8192 and the bsize=65536 (it is mainly to be used for large
> | > data log files):
> |
> | FreeBSD doesn't support fsize/bsize so large. There are ongoing issues
> | within the filesystem code and VM code that will cause such filesystems
> | to break under heavy load. Matt Dillon also talked about this being
> | less-than-optimal for the VM system from some technical points of view.
> | I ran into this years ago, and have been content to live with
> |
> | newfs -c 96 -b 16384 -f 4096 -i 1048576 /dev/rccd${i}e
> </Zitat>

Man sollte mit solchen Parametern kein NFS anbieten.
Lokal läuft das.

Das mit dem weniger Optimal kann ich nachvollziehen, da 64k auch
der Clustergröße entspricht - jedenfalls war das mal so.
Es bezieht sich aber aufs VM - wenn mein Flaschenhals aber nicht
CPU sondern Plattenleistung ist kann das denoch ein Gewinn sein.

> > -f sollte um den Faktor 8 kleiner als -b sein.
>
> Oder kleinere Faktoren (4, 2, 1), was aber nur in bestimm-
> ten Grenzfällen etwas bringt.
>
> > -b ÷ -f < 8 ist nicht so wirkungsvoll, weils lediglich aufs Fileende
> > wirkt und ein bischen die Metadaten reduziert.
>
> Und die Fragmentierung.

Die Fragmentgröße hat fast keinen Einfluß auf die Fragmentierung.
Es verändert sich nur die Restgröße bei der ein Endfragment
eingesetzt wird.
Die Auswirkungen werden insbesonders bei großen Files kleiner.

> Bei einem Faktor von 1 (blocksize == fragmentsize) schließt
> man Fragmentierung völlig aus, hat dafür aber einen gewis-
> sen Verschnitt bei Belegung des Platzes. Bei (relativ) we-

Fragmentierung kann man dadurch nicht ausschliessen.
Man reduziert lediglich die Metadaten, weil ja jedes potentielle
Fragment ein eigenes Belegtflag hat.
Die Metadaten der Dateien selber bleiben absolut gleich.

> nigen, aber dafür großen Dateien dürfte es keine Rolle
> spielen, insbesondere wenn es hauptsächlich »write-once«
> Daten sind, wie z.B. ein mp3-Archiv. In dem Fall würde ich
> sogar noch ein -m 0 dazuschieben.

Je größer die Dateien je kleiner ist der Gewinn durch einen
kleineren Faktor, genau dann könnte man aber eher mit dem größeren
Verschnitt pro Datei leben.
Ich sehe kaum einen sinnvollen Grund einen Faktor != 8 zu nehmen.

> Quintessenz: In den allermeisten Fällen lohnt es sich
> höchstens, mit der -i Option zu spielen. Mit den anderen
> Optionen kann man das FS prima »verschlimmbessern« ... ;-)

Dem kann ich voll zustimmen.

-- 
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-questions" in the body of the message