PERFORCE change 152550 for review
Rene Ladan
rene at FreeBSD.org
Wed Nov 5 13:53:52 PST 2008
http://perforce.freebsd.org/chv.cgi?CH=152550
Change 152550 by rene at rene_self on 2008/11/05 21:53:45
MFen handbook/chapter.sgml -> 1.235 plus many local fixes.
Checked whitespace, build
Affected files ...
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/config/chapter.sgml#7 edit
Differences ...
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/config/chapter.sgml#7 (text+ko) ====
@@ -81,7 +81,7 @@
<listitem>
<para>Hoe de instellingenbestanden in <filename>/etc</filename>
- gebruikt worden;</para>
+ gebruikt worden;</para>
</listitem>
<listitem>
@@ -1760,7 +1760,7 @@
security.bsd.see_other_uids=0</programlisting>
</sect2>
</sect1>
-<!--rene-->
+
<sect1 id="configtuning-sysctl">
<title>Optimaliseren met sysctl</title>
@@ -1773,14 +1773,14 @@
</indexterm>
<para>&man.sysctl.8; is een interface waarmee veranderingen gemaakt
- kunnen worden aan een draaiend &os; systeem. Er zijn onder meer
- vele geavanceerde opties voor de TCP/<acronym>IP</acronym> stack
+ kunnen worden aan een draaiend &os;-systeem. Er zijn onder meer
+ vele geavanceerde opties voor de TCP/<acronym>IP</acronym>-stack
en het virtuele geheugensysteem, waarmee een ervaren
systeembeheerder de systeemprestaties drastisch kan verbeteren.
- Met &man.sysctl.8; kunnen meer dan vijfhonderd ststeemvariabelen
+ Met &man.sysctl.8; kunnen meer dan vijfhonderd systeemvariabelen
opgevraagd en ingesteld worden.</para>
- <para>In essentie heeft &man.sysctl.8; twee funkties: het lezen en
+ <para>In essentie heeft &man.sysctl.8; twee functies: het lezen en
wijzigen van systeeminstellingen.</para>
<para>Om alle leesbare variabelen te tonen:</para>
@@ -1800,7 +1800,7 @@
<screen>&prompt.root; <userinput>sysctl kern.maxfiles=5000</userinput>
kern.maxfiles: 2088 -> 5000</screen>
- <para>Waarden van sysctl variabelen zijn doorgaans strings (tekst),
+ <para>Waarden van sysctl-variabelen zijn doorgaans strings (tekst),
getallen of booleans (<literal>1</literal> als waar,
<literal>0</literal> als onwaar).</para>
@@ -1823,28 +1823,28 @@
<title>&man.sysctl.8; alleen-lezen</title>
- <para>In sommige gevallen is het wenselijk zijn om &man.sysctl.8;
- waarden die alleen-lezen zijn toch te wijzigen. Hoewel dit soms
+ <para>In sommige gevallen is het wenselijk om &man.sysctl.8;-waarden
+ die alleen-lezen zijn toch te wijzigen. Hoewel dit soms
onontkoombaar is, kan het alleen bij een (her)start gedaan
worden.</para>
<para>Op sommige laptops is bijvoorbeeld het apparaat
- &man.cardbus.4; niet in staat om geheugenregio's af te tasten,
- met als gevolg foutmeldingen als:</para>
+ &man.cardbus.4; niet in staat om geheugenregio's af te tasten, met
+ als gevolg foutmeldingen als:</para>
<screen>cbb0: Could not map register memory
device_probe_and_attach: cbb0 attach returned 12</screen>
<para>In dergelijke gevallen moeten er meestal enkele
- &man.sysctl.8; instellingen gewijzigd worden die alleen-lezen
- zijn en een standaardwaarde hebben. Dit kan bereikt worden door
+ &man.sysctl.8;-instellingen gewijzigd worden die alleen-lezen zijn
+ en een standaardwaarde hebben. Dit kan bereikt worden door
&man.sysctl.8; <quote>OIDs</quote> in de lokale
<filename>/boot/loader.conf</filename> te zetten.
Standaardinstellingen staan in
<filename>/boot/defaults/loader.conf</filename>.</para>
<para>Om het bovenstaande probleem op te lossen moet in
- in <filename>/boot/loader.conf</filename
+ <filename>/boot/loader.conf</filename>
<literal>hw.pci.allow_unsupported_io_range=1</literal> ingesteld
worden. Dan werkt &man.cardbus.4; wel goed.</para>
</sect2>
@@ -1854,34 +1854,34 @@
<title>Harde schijven optimaliseren</title>
<sect2>
- <title>Sysctl variabelen</title>
+ <title>Sysctl-variabelen</title>
<sect3>
<title><varname>vfs.vmiodirenable</varname></title>
<indexterm><primary><varname>vfs.vmiodirenable</varname></primary></indexterm>
- <para>De sysctl variabele <varname>vfs.vmiodirenable</varname>
+ <para>De sysctl-variabele <varname>vfs.vmiodirenable</varname>
kan de waarde 0 (uit) of 1 (aan) hebben. De standaardwaarde
- is 1. Deze variabele bepaalt hoe mappen door het systeem
- in een cache bewaard worden. De meeste mappen zijn
- klein en gebruiken slechts een klein fragment (typisch
- 1 K) in het bestandssysteem en nog minder (typisch
- 512 bytes) in de buffercache. Als deze variabele
- uit staat (op 0) bewaart de buffercache slechts een bepaald
- aantal mappen in de cache, ook al is er een overvloed aan
- geheugen beschikbaar. Wanneer deze aan staat (op 1), wordt
- de VM pagecache gebruikt, waardoor voor het cachen van mappen
- al het geheugen kan worden gebruikt. Het is echter wel zo
- dat het minimale in-core geheugen dat gebruikt wordt om een
- map te cachen in dat geval de fysieke pagegrootte is
- (typisch 4 K) in plaats van 512 bytes. Het is aan
- te raden deze optie aan te laten staat als gebruik gemaakt
- worden van diensten die met grote aantallen bestanden werken,
- zoals webcaches, grote mailsystemen en newsservers. Als deze
- optie aan blijft staan, verlaagt die de prestaties niet, ook
- al kost het meer geheugen. Door experimenteren is dit voor
- een systeem na te gaan.</para>
+ is 1. Deze variabele bepaalt hoe mappen door het systeem in
+ een cache bewaard worden. De meeste mappen zijn klein en
+ gebruiken slechts een klein fragment (typisch 1 K) in het
+ bestandssysteem en nog minder (typisch 512 bytes) in de
+ buffercache. Als deze variabele uit staat (op 0) bewaart de
+ buffercache slechts een bepaald aantal mappen in de cache, ook
+ al is er een overvloed aan geheugen beschikbaar. Wanneer deze
+ aan staat (op 1), wordt de VM paginacache gebruikt, waardoor
+ voor het cachen van mappen al het geheugen kan worden
+ gebruikt. Het is echter wel zo dat het minimale in-core
+ geheugen dat gebruikt wordt om een map te cachen in dat geval
+ de fysieke paginagrootte is (typisch 4 K) in plaats van
+ 512 bytes. Het is aan te raden deze optie aan te laten
+ staan als gebruik gemaakt wordt van diensten die met grote
+ aantallen bestanden werken, zoals webcaches, grote
+ mailsystemen en newsservers. Als deze optie aan blijft staan,
+ verlaagt die de prestaties niet, ook al kost het meer
+ geheugen. Door experimenteren is dit voor een systeem na te
+ gaan.</para>
</sect3>
<sect3>
@@ -1889,16 +1889,16 @@
<indexterm><primary><varname>vfs.write_behind</varname></primary></indexterm>
- <para>De sysctl variabele <varname>vfs.write_behind</varname>
+ <para>De sysctl-variabele <varname>vfs.write_behind</varname>
staat standaard aan (<literal>1</literal>). Dit betekent dat
- het bestandssysteem gegevens naar het medium gaat schrijven
- op het moment dat er een volledig cluster aan data verzameld
+ het bestandssysteem gegevens naar het medium gaat schrijven op
+ het moment dat er een volledig cluster aan gegevens verzameld
is. Dit is meestal het geval bij het schrijven van grote
sequentiële bestanden. Het idee is om te voorkomen dat
de buffercache verzadigd raakt met vuile buffers zonder dat
- dit bijdraagt aan de I/O prestaties. Dit kan echter
- processen ophouden en onder sommige omstandigheden is het
- wellicht beter deze sysctl uit te zetten.</para>
+ dit bijdraagt aan de I/O-prestaties. Dit kan echter processen
+ ophouden en onder sommige omstandigheden is het wellicht beter
+ deze sysctl uit te zetten.</para>
</sect3>
<sect3>
@@ -1906,20 +1906,20 @@
<indexterm><primary><varname>vfs.hirunningspace</varname></primary></indexterm>
- <para>De sysctl variabele <varname>vfs.hirunningspace</varname>
+ <para>De sysctl-variabele <varname>vfs.hirunningspace</varname>
bepaalt hoeveel nog te schrijven gegevens er in het complete
systeem op elk moment in de wachtrij naar schijfcontrollers
mag staan. De standaardwaarde is meestal voldoende, maar op
- machines met veel schijven, is het beter deze te verhogen
- naar vier of vijf <emphasis>megabyte</emphasis>. Het
- instellen van een te hoge waarde (groter dan de
- schrijfdrempel van de buffercache) kan leiden tot zeer
- slechte prestaties bij clustering. Stel deze waarde niet
- arbitrair hoog in! Hogere schrijfwaarden kunnen vertraging
- veroorzaken in het lezen, als dit tegelijk plaatsvindt.</para>
+ machines met veel schijven, is het beter deze te verhogen naar
+ vier of vijf <emphasis>megabyte</emphasis>. Het instellen van
+ een te hoge waarde (groter dan de schrijfdrempel van de
+ buffercache) kan leiden tot zeer slechte prestaties bij
+ clustering. Stel deze waarde niet arbitrair hoog in! Hogere
+ schrijfwaarden kunnen vertraging veroorzaken in het lezen, als
+ dit tegelijk plaatsvindt.</para>
- <para>Er zijn verscheidene andere sysctls voor buffercache en
- VM pagecache. Het wordt afgeraden deze te wijzigen. Het
+ <para>Er zijn verscheidene andere sysctl's voor buffercache en
+ VM-pagecache. Het wordt afgeraden deze te wijzigen. Het
VM-systeem is zeer goed in staat zichzelf automatisch te
optimaliseren.</para>
</sect3>
@@ -1929,14 +1929,14 @@
<indexterm><primary><varname>vm.swap_idle_enabled</varname></primary></indexterm>
- <para>De sysctl variabele
+ <para>De sysctl-variabele
<varname>vm.swap_idle_enabled</varname> is nuttig in grote
- multi-user systemen met veel gebruikers die af- en aanmelden
+ meergebruikersystemen met veel gebruikers die af- en aanmelden
en veel onbenutte processen. Dergelijke systemen hebben de
neiging om voortdurend de vrije geheugenreserves onder druk
te zetten. Het is mogelijk om de prioriteit van
- geheugenpages die verband houden met onbenutte processen
- sneller te laten dalen dan met het normale pageout algoritme,
+ geheugenpagina's die verband houden met onbenutte processen
+ sneller te laten dalen dan met het normale pageout-algoritme,
door deze sysctl aan te zetten en via
<varname>vm.swap_idle_threshold1</varname> en
<varname>vm.swap_idle_threshold2</varname> de swapout
@@ -1947,7 +1947,7 @@
wisselbestand- en schijfbandbreedte kost. In een klein
systeem heeft deze optie een voorspelbaar effect, maar in
grote systemen waar al sprake is van een matige paging kan
- deze optie het mogelijk maken voor het VM systeem om hele
+ deze optie het mogelijk maken voor het VM-systeem om hele
processen gemakkelijk in en uit het geheugen te halen.</para>
</sect3>
@@ -1957,25 +1957,25 @@
<indexterm><primary><varname>hw.ata.wc</varname></primary></indexterm>
<para>Ten tijde van &os; 4.3 is er geflirt met het
- uitzetten van IDE schrijfcaching. Hierdoor neemt de
- bandbraadte naar IDE schijven af, maar het werd als
+ uitzetten van IDE-schrijfcaching. Hierdoor neemt de
+ bandbraadte naar IDE-schijven af, maar het werd als
noodzakelijk beschouwd vanwege ernstige problemen met
gegevensinconsistentie die door harde schijfproducenten
- geëintroduceerd waren. Het probleem is dat IDE schijven
+ geëintroduceerd waren. Het probleem is dat IDE-schijven
niet de waarheid vertellen over wanneer een schrijfactie
- klaar is. Door IDE schrijfcaching wordt data niet alleen
+ klaar is. Door IDE-schrijfcaching wordt data niet alleen
ongeordend geschreven, maar soms kan zelfs het schrijven van
- sommige blokken voortdurend uitgesteld worden als er sprake
- is van een hoge schijfbelasting. Een crash of stroomstoring
- kan dan ernstige corruptie van het bestandssysteem
- veroorzaken. Daarom werd de standaardinstelling van &os;
- voor alle zekerheid gewijzigd. Helaas was het resultaat een
- groot verlies aan prestaties en na die release is de
- standaardwaarde weer terug veranderd. Met de sysctl
- variabele <varname>hw.ata.wc</varname> kan gecontroleerd
- worden of schrijfcaching aan of uit staat. Als
- schrijfcaching uit staat, het die weer aangezet worden door
- <varname>hw.ata.wc</varname> naar 1 te zetten. Aangezien dit
+ sommige blokken voortdurend uitgesteld worden als er sprake is
+ van een hoge schijfbelasting. Een crash of stroomstoring kan
+ dan ernstige corruptie aan het bestandssysteem veroorzaken.
+ Daarom werd de standaardinstelling van &os; voor alle
+ zekerheid gewijzigd. Helaas was het resultaat een groot
+ verlies aan prestaties en na die uitgave is de
+ standaardwaarde weer terug veranderd. Met de sysctl-variabele
+ <varname>hw.ata.wc</varname> kan gecontroleerd worden of
+ schrijfcaching aan of uit staat. Als schrijfcaching uit
+ staat, kan het die weer aangezet worden door
+ <varname>hw.ata.wc</varname> op 1 te zetten. Aangezien dit
een kernelvariabele is, moet deze ingesteld worden vanuit de
bootloader tijdens het opstarten. Nadat de kernel eenmaal
opgestart is, heeft het wijzigen van deze sysctl geen
@@ -1996,10 +1996,10 @@
<secondary><literal>SCSI_DELAY</literal></secondary>
</indexterm>
- <para>De <literal>SCSI_DELAY</literal> kernelinstelling kan
+ <para>De kernelinstelling <literal>SCSI_DELAY</literal> kan
gebruikt worden om de opstarttijd te versnellen. De
standaardwaarde is nogal hoog en kan <literal>15</literal>
- seconden vertraging veroorzaken. Met modernere SCSI systemen
+ seconden vertraging veroorzaken. Met modernere SCSI-systemen
is <literal>5</literal> seconden al voldoende. Nieuwere
versies van &os; (5.0 en hoger) gebruiken de opstartvariabele
<varname>kern.cam.scsi_delay</varname>. Zowel deze als de
@@ -2026,26 +2026,26 @@
&prompt.root; <userinput>tunefs -n disable /filesystem</userinput></screen>
<para>Een bestandssysteem kan niet met &man.tunefs.8; gewijzigd
- worden als het gemount is. Softupdates aanzetten wordt dus in
- het algemeen gedaan vanuit single-user modus, voordat partities
- gemount zijn.</para>
+ worden als het aangekoppeld is. Softupdates aanzetten wordt dus
+ in het algemeen gedaan vanuit enkelegebruikermodus, voordat
+ partities aangekoppeld zijn.</para>
<para>Softupdates zorgen voor een drastische verbetering van de
- meta-data prestaties, met name het aanmaken en verwijderen van
- bestanden, door gebruik van een geheugencache. Het wordt dan
- ook aangeraden om op alle bestandssystemen softupdates te
- gebruiken. Er zijn twee nadelen aan softupdates: softupdates
- garandeert een consistent bestandssysteem in geval van een
- crash, maar het kan makkelijk enkele seconden (zelfs een
- minuut) achter liggen met het daadwerkelijk bijwerken op de
- fysieke harde schijf. Als een systeem crasht wordt wellicht
- meer werk verloren dan anders het geval zou zijn. Daarnaast
- vertraagt softupdates het vrijgeven van bestandssysteemblokken.
- Als een bestandssysteem (zoals de root partitie) bijna vol is,
- dan kan het verrichten van een grote update, zoals
- <command>make installworld</command>, ertoe leiden dat het
- bestandssysteem ruimtegebrek krijgt en dat daardoor de operatie
- mislukt.</para>
+ prestaties met betrekking tot metagegevens, met name het
+ aanmaken en verwijderen van bestanden, door gebruik van een
+ geheugencache. Het wordt dan ook aangeraden om op alle
+ bestandssystemen softupdates te gebruiken. Er zijn twee nadelen
+ aan softupdates: softupdates garanderen een consistent
+ bestandssysteem in geval van een crash, maar het kan makkelijk
+ enkele seconden (zelfs een minuut) achter liggen met het
+ daadwerkelijk bijwerken op de fysieke harde schijf. Als een
+ systeem crasht gaat wellicht meer werk verloren dan anders het
+ geval zou zijn. Daarnaast vertragen softupdates het vrijgeven
+ van bestandssysteemblokken. Als een bestandssysteem (zoals de
+ rootpartitie) bijna vol is, dan kan het verrichten van een grote
+ update, zoals <command>make installworld</command>, ertoe leiden
+ dat het bestandssysteem ruimtegebrek krijgt en dat daardoor de
+ operatie mislukt.</para>
<sect3>
<title>Meer over softupdates</title>
@@ -2056,56 +2056,57 @@
<secondary>details</secondary>
</indexterm>
- <para>Er zijn traditioneel twee methodes om de metadata van een
- bestandssysteem terug naar de schijf te schrijven. Het
- bijwerken van metadata houdt het bijwerken van van
- niet-inhoudelijke data zoals inodes of mappen in.</para>
+ <para>Er zijn traditioneel twee methodes om de metagegevens van
+ een bestandssysteem terug naar de schijf te schrijven. Het
+ bijwerken van metagegevens houdt het bijwerken van van
+ niet-inhoudelijke gegevens zoals inodes of mappen in.</para>
- <para>Historisch gezien was het gebruikelijk om metadataupdates
- synchroon weg te schrijven. Als een map bijvoorbeeld
- gewijzigd was, wachtte het systeem totdat de verandering
- daadwerkelijk naar de schijf geschreven was. De databuffers
- (de inhoud van een bestand) werden doorgeschoven naar de
- buffercache en op een later moment asynchroon op de schijf
- opgeslagen. Het voordeel van deze benadering is dat ze
- altijd veilig is. Als het systeem faalt tijdens het
- bijwerken, is de metadata nog altijd consistent. Een bestand
- kan volledig gecreëerd zijn of helemaal niet. Als de
- datablokken van een bestand nog niet van de buffercache naar
- de schijf geschreven zijn ten tijde van de crash, is
- &man.fsck.8; in staat om dit te herkennen en het
- bestandssysteem te repareren door de lengte van het bestand
- nul te maken. Deze implementatie is ook helder en eenvoudig.
- Het nadeel is echter dat het wijzigen van metadata een traag
- proces is. Een <command>rm -r</command> commando benadert
- bijvoorbeeld alle bestanden in een map sequentiëel, maar
- elke mapverandering (verwijderen van een bestand) wordt
- synchroon naar de schijf geschreven. Dit omvat ook het
- bijwerken van de map zelf, van de inodetabel en mogelijk ook
- van indirecte blokken die voor het bestand in kwestie
- zijn gealloceerd. Gelijksoortige processen spelen zich af
- bij een commando als <command>tar -x</command>, waarbij een
- grote bestandshiëearchie wordt uitgepakt.</para>
+ <para>Historisch gezien was het gebruikelijk om updates aan
+ metagegevens synchroon weg te schrijven. Als een map
+ bijvoorbeeld gewijzigd was, wachtte het systeem totdat de
+ verandering daadwerkelijk naar de schijf geschreven was. De
+ gegevensbuffers (de inhoud van een bestand) werden
+ doorgeschoven naar de buffercache en op een later moment
+ asynchroon op de schijf opgeslagen. Het voordeel van deze
+ benadering is dat ze altijd veilig is. Als het systeem faalt
+ tijdens het bijwerken, zijn de metagegevens nog altijd
+ consistent. Een bestand kan volledig gecreëerd zijn of
+ helemaal niet. Als de gegevensblokken van een bestand nog
+ niet van de buffercache naar de schijf geschreven zijn ten
+ tijde van de crash, is &man.fsck.8; in staat om dit te
+ herkennen en het bestandssysteem te repareren door de lengte
+ van het bestand nul te maken. Deze implementatie is ook
+ helder en eenvoudig. Het nadeel is echter dat het wijzigen
+ van metagegevens een traag proces is. Een
+ <command>rm -r</command> benadert bijvoorbeeld alle bestanden
+ in een map sequentiëel, maar elke mapverandering
+ (verwijderen van een bestand) wordt synchroon naar de schijf
+ geschreven. Dit omvat ook het bijwerken van de map zelf, van
+ de inodetabel en mogelijk ook van indirecte blokken die voor
+ het bestand in kwestie zijn gealloceerd. Gelijksoortige
+ processen spelen zich af bij een commando als
+ <command>tar -x</command>, waarbij een grote
+ bestandshiëearchie wordt uitgepakt.</para>
- <para>De tweede mogelijkheid is om het bijwerken van metadata
- asynchroon weg te schrijven. Dit is standaard in
- &linux;/ext2fs en als een *BSD ufs bestandssysteem met
- <command>mount -o async</command> gemount is, is de werking
- hetzelfde. Alle bijwerkingen aan metagegevens worden
+ <para>De tweede mogelijkheid is om het bijwerken van
+ metagegevens asynchroon weg te schrijven. Dit is standaard in
+ &linux;/ext2fs en als een *BSD UFS-bestandssysteem met
+ <command>mount -o async</command> aangekoppeld is, is de
+ werking hetzelfde. Alle bijwerkingen aan metagegevens worden
eenvoudigweg doorgegeven aan de buffercache en vermengd met
inhoudelijke updates van de bestandsgegevens. Het voordeel
- is een grote winst aan snelheid, omdat er niet telkens
- gewacht hoeft te worden op het bijwerken van metagegevens tot
- deze daadwerkelijk naar de schijf geschreven zijn. De
+ is een grote winst aan snelheid, omdat er niet telkens gewacht
+ hoeft te worden op het bijwerken van metagegevens tot deze
+ daadwerkelijk naar de schijf geschreven zijn. De
implementatie is ook in dit geval helder en eenvoudig. Het
grote nadeel is uiteraard dat er geen enkele garantie is voor
de consistentie van het bestandssysteem. Als het systeem
faalt tijdens een operatie waarbij veel metagegevens worden
bijgewerkt (bijvoorbeeld door een stroomstoring of iemand
drukt op de resetknop), blijft het bestandssysteem in een
- onvoorspelbare toestand achter. Er is geen mogelijkheid om
- de toestand van het bestandssysteem te onderzoeken als het
- systeem weer opstart, want de datablokken van een bestand
+ onvoorspelbare toestand achter. Er is geen mogelijkheid om de
+ toestand van het bestandssysteem te onderzoeken als het
+ systeem weer opstart, want de gegevensblokken van een bestand
kunnen al weggeschreven zijn geweest terwijl het wegschrijven
van bijwerkingen aan de inodetabel of de bijhorende map nog
niet plaats heeft gevonden. Het is zelfs onmogelijk om een
@@ -2119,56 +2120,56 @@
<para>De gebruikelijke oplossing voor dit probleem is het
implementeren van <emphasis>dirty region logging</emphasis>,
ook wel <emphasis>journaling</emphasis> genoemd, hoewel deze
- term niet consistent gebruikt wordt en soms ook wordt
- gebruikt voor andere vormen van transactielogging. Het
- bijwerken van metagegevens wordt nog steeds synchroon
- geschreven, maar slechts naar een klein gebied van de schijf.
- Later worden ze dan naar de juiste locatie verplaatst. Omdat
- het loggebied klein is, hoeven de koppen van de schijf zelfs
- tijdens schrijfintensieve operaties nog maar over een kleine
- fysieke afstand te bewegen en door deze snellere respons zijn
- dit soort operaties sneller dan op de traditionele manier.
- De extra complexiteit van de implementatie is nogal beperkt,
- dus het risico van introductie van extra bugs valt mee. Een
+ term niet consistent gebruikt wordt en soms ook wordt gebruikt
+ voor andere vormen van transactielogging. Het bijwerken van
+ metagegevens wordt nog steeds synchroon geschreven, maar
+ slechts naar een klein gebied van de schijf. Later worden ze
+ dan naar de juiste locatie verplaatst. Omdat het loggebied
+ klein is, hoeven de koppen van de schijf zelfs tijdens
+ schrijfintensieve operaties nog maar over een kleine fysieke
+ afstand te bewegen en door deze snellere respons zijn dit
+ soort operaties sneller dan op de traditionele manier. De
+ extra complexiteit van de implementatie is nogal beperkt, dus
+ het risico van introductie van extra bugs valt mee. Een
nadeel is dat alle metagegevens tweemaal geschreven worden
(eerst naar het loggebied en later nog eens naar de
definitieve locatie). Dus bij normaal gebruik kan er sprake
zijn van wat men wel noemt een <quote>performance
pessimization</quote>. Anderzijds kunnen in geval van een
crash alle nog uitstaande metagegevensoperaties snel worden
- teruggedraaid of vanuit het loggebied alsnog worden
- afgemaakt, wanneer de machine weer opstart. Het
- bestandssysteem start dan snel op.</para>
+ teruggedraaid of vanuit het loggebied alsnog worden afgemaakt
+ wanneer de machine weer opstart. Het bestandssysteem start
+ dan snel op.</para>
<para>Kirk McKusick, de vader van het Berkeley FFS, loste dit
probleem op met softupdates, wat betekent dat alle uitstaande
acties voor het bijwerken van metagegevens in het geheugen
bewaard worden en dan geordend naar de schijf geschreven
worden. Dit heeft het gevolg dat in geval van intensieve
- operaties met betrekking tot metagegevens, latere
- bijwerkingen aan een item eerdere bewerkingen opvangen
+ operaties met betrekking tot metagegevens, latere bijwerkingen
+ aan een item eerdere bewerkingen opvangen
(<quote>catch</quote>) als deze nog in het geheugen zitten en
- nog niet weggeschreven waren. Dus alle operaties,
- op bijvoorbeeld een map, worden in het algemeen eerst in het
+ nog niet weggeschreven waren. Dus alle operaties, op
+ bijvoorbeeld een map, worden in het algemeen eerst in het
geheugen uitgevoerd voordat er wordt bijgewerkt naar schijf.
- De datablokken worden geordend conform hun positie, zodat ze
- nooit weggeschreven worden voordat hun metagegevens
+ De gegevensblokken worden geordend conform hun positie, zodat
+ ze nooit weggeschreven worden voordat hun metagegevens
geschreven zijn. Als het systeem een crash ondervindt,
veroorzaakt dat impliciet het terugdraaien van uitstaande
operaties (<quote>log rewind</quote>): alle operaties die nog
niet weggeschreven waren lijken nooit gebeurd te zijn. Zo
wordt een consistent bestandssysteem in stand gehouden dat
eruit ziet alsof het 30 tot 60 seconden eerder was. Het
- gebruikte algoritme garandeert dat alle bronnen die in
- gebruik zijn als zodanig gemarkeerd worden in hun daarvoor
- geschikte bitmaps: blokken en inodes. Na een crash is de
- enige allocatiefout die kan optreden dat bronnen gemarkeerd
- kunnen zijn als in gebruik (<quote>used</quote>), terwijl ze
+ gebruikte algoritme garandeert dat alle bronnen die in gebruik
+ zijn als zodanig gemarkeerd worden in hun daarvoor geschikte
+ bitmaps: blokken en inodes. Na een crash is de enige
+ allocatiefout die kan optreden dat bronnen gemarkeerd kunnen
+ zijn als in gebruik (<quote>used</quote>), terwijl ze
feitelijk alweer beschikbaar (<quote>free</quote>) zijn.
&man.fsck.8; herkent deze situatie en stelt dergelijke vrij
te maken bronnen opnieuw beschikbaar. Het is volkomen veilig
- om na een crash te negeren dat het bestandssysteem niet
- schoon is en het tot mounten te dwingen met
+ om na een crash te negeren dat het bestandssysteem niet schoon
+ is en het tot aankoppelen te dwingen met
<command>mount -f</command>. Om niet langer gebruikte
bronnen vrij te maken moet later &man.fsck.8; uitgevoerd
worden. Dit is dan ook het idee achter <emphasis>background
@@ -2176,38 +2177,39 @@
opstarten is, wordt er alleen een
<emphasis>snapshot</emphasis> van het systeem bewaard.
<command>fsck</command> kan later uitgevoerd worden. Alle
- bestandssystemen kunnen <quote>dirty</quote> gemount worden
- en het systeem kan gewoon verder opstarten naar multi-user
- modus. Vervolgens zijn er <command>fsck</command>s
- gepland die in de achtergrond draaien voor elk
- bestandssysteem dat niet schoon is en waarmee bezette bronnen
- vrijgegeven worden. Bestandssystemen die geen gebruik maken
- van softupdates moeten echter nog steeds gebruik maken van de
- normale <command>fsck</command> in de voorgrond.</para>
+ bestandssystemen kunnen <quote>dirty</quote> aangekoppeld
+ worden en het systeem kan gewoon verder opstarten naar
+ meergebruikermodus. Vervolgens zijn er
+ <command>fsck</command>s gepland die in de achtergrond draaien
+ voor elk bestandssysteem dat niet schoon is en waarmee
+ bezette bronnen vrijgegeven worden. Bestandssystemen die geen
+ gebruik maken van softupdates moeten echter nog steeds gebruik
+ maken van de normale <command>fsck</command> in de
+ voorgrond.</para>
<para>Het voordeel van softupdates is dat operaties op
metagegevens bijna net zo snel zijn als asynchrone updates
- (dat wil zeggen sneller dan met
- <emphasis>logging</emphasis>, waarbij de metagegevens keer
- keer geschreven worden). Nadelen zijn de complexiteit van
- de code (wat een groter risico op bugs impliceert in een
- gebied dat bijzonder gevoelig is voor verlies van
- gebruikersgegevens) en een groter geheugenverbruik. Tevens
- moet de gebruiker wennen aan enkele eigenaardigheden. Na
- een crash lijkt de toestand van het bestandssysteem wat
- <quote>ouder</quote>. In situaties waar de standaard
- synchrone benadering een aantal lege bestanden zou hebben
- achtergelaten na <command>fsck</command>, is het met
- softupdates juist zo dat dergelijke bestanden er helemaal
- niet zijn, omdat de metadata of de bestandsinhoud nooit naar
- de schijf is geschreven. Schijfruimte wordt pas vrijgegeven
- als de bijwerkingen aan metagegevens en inhoudelijke
- bestandsdata weggeschreven zijn, wat mogelijk pas enige tijd
- na het uitvoeren van <command>rm</command> plaatsvindt. Dit
- kan problemen veroorzaken als er grote hoeveelheden data
- naar een bestandssysteem geschreven worden dat onvoldoende
- vrije ruimte heeft om alle bestanden twee keer te kunnen
- bevatten (bijvoorbeeld in <filename>/tmp</filename>).</para>
+ (dat wil zeggen sneller dan met <emphasis>logging</emphasis>,
+ waarbij de metagegevens keer op keer geschreven worden).
+ Nadelen zijn de complexiteit van de code (wat een groter
+ risico op bugs impliceert in een gebied dat bijzonder
+ gevoelig is voor verlies van gebruikersgegevens) en een
+ groter geheugenverbruik. Tevens moet de gebruiker wennen aan
+ enkele eigenaardigheden. Na een crash lijkt de toestand van
+ het bestandssysteem wat <quote>ouder</quote>. In situaties
+ waar de standaard synchrone benadering een aantal lege
+ bestanden zou hebben achtergelaten na
+ <command>fsck</command>, is het met softupdates juist zo dat
+ dergelijke bestanden er helemaal niet zijn, omdat de
+ metagegevens of de bestandsinhoud nooit naar de schijf zijn
+ geschreven. Schijfruimte wordt pas vrijgegeven als de
+ bijwerkingen aan metagegevens en inhoudelijke
+ bestandsgegevens weggeschreven zijn, wat mogelijk pas enige
+ tijd na het uitvoeren van <command>rm</command> plaatsvindt.
+ Dit kan problemen veroorzaken als er grote hoeveelheden
+ gegevens naar een bestandssysteem geschreven worden dat
+ onvoldoende vrije ruimte heeft om alle bestanden twee keer te
+ kunnen bevatten (bijvoorbeeld in <filename>/tmp</filename>).</para>
</sect3>
</sect2>
</sect1>
@@ -2230,30 +2232,28 @@
<indexterm><primary><varname>kern.maxfiles</varname></primary></indexterm>
<para><varname>kern.maxfiles</varname> kan worden verhoogd of
- verlaagd, afhankelijk van de systeembehoeften. Deze
- variabele geeft het maximale aantal bestandsdescriptors op
- een systeem. Als de bestandsdescriptortabel vol is,.toont de
- systeembuffer meerdere malen <errorname>file: table is
- full</errorname>, hetgeen achteraf te zien is net
- <command>dmesg</command>.</para>
+ verlaagd, afhankelijk van de systeembehoeften. Deze variabele
+ geeft het maximale aantal bestandsdescriptors op een systeem.
+ Als de bestandsdescriptortabel vol is, toont de systeembuffer
+ meerdere malen <errorname>file: table is full</errorname>, het
+ geen achteraf te zien is met <command>dmesg</command>.</para>
<para>Elk geopend bestand, socket of fifo heeft een
bestandsdescriptor. Een grote produktieserver kan makkelijk
enige duizenden bestandsdescriptors nodig hebben, afhankelijk
van het soort en aantal diensten die tegelijk draaien.</para>
- <para>In oudere versies van &os;, werd de standaard waarde van
- <varname>kern.maxfiles</varname> afgeleid van de
- <option>maxusers</option> optie in het kernel configuratie
- bestand.
+ <para>In oudere versies van &os; werd de standaard waarde van
+ <varname>kern.maxfiles</varname> afgeleid van de optie
+ <option>maxusers</option> in het kernelconfiguratiebestand.
<varname>kern.maxfiles</varname> groeit evenredig met de
waarde van <literal>maxusers</literal>. Als een aangepaste
- kernel wordt gebouwd, is het een goed idee om deze
- kerneloptie in te stellen afhankelijk van het gebruikt van
- een systeemhet (maar niet te laag). Hoewel een
- produktieserver misschien niet 256 gebruikers gelijktijdige
- gebruikers heeft, kunnen de benodigde systeembronnen best
- vergelijkbaar zijn met een grootschalige webserver.</para>
+ kernel wordt gebouwd, is het een goed idee om deze kerneloptie
+ in te stellen afhankelijk van het gebruikt van een systeem
+ (maar niet te laag). Hoewel een produktieserver misschien
+ niet 256 gelijktijdige gebruikers heeft, kunnen de benodigde
+ systeembronnen het beste vergeleken worden met een
+ grootschalige webserver.</para>
<para>De optie <literal>maxusers</literal> stelt de grootte van
een aantal belangrijke systeemtabellen in. Dit aantal moet
@@ -2264,23 +2264,26 @@
automatisch ingesteld tijdens het opstarten gebaseerd op de
hoeveelheid beschikbare geheugen in het systeem en kan worden
vastgesteld tijdens het draaien door te kijken naar de
- alleen-lezen <varname>kern.maxusers</varname> sysctl. Sommige
+ alleen-lezen sysctl <varname>kern.maxusers</varname>. Sommige
configuraties hebben grotere of kleinere waarden nodig van
<varname>kern.maxusers</varname>, deze kunnen worden gezet
- als een opstart variabele. Waardes van 64, 128 en 256 zijn
+ als een opstartvariabele. Waardes van 64, 128 en 256 zijn
daarin niet ongewoon. We raden aan om niet boven de 256 te
- gaan tenzij er heel veel filedescriptors benodigd zijn; veel
- van de aanpasbaare waarden die standaard worden bepaald door
- <varname>kern.maxusers</varname> kunnen individueel worden
- overschreven tijdens het opstarten en/of tijdens het draaien
- van het systeem in <filename>/boot/loader.conf</filename>
- (zie de &man.loader.conf.5; handleiding of het
- <filename>/boot/defaults/loader.conf</filename> bestand voor
- een paar aanwijzingen) of zoals ergens anders beschreven in
- dit document. Systemen die ouder zijn dan &os; 4.4
- moeten deze waardes zetten via de kernel &man.config.8; optie
+ gaan tenzij er heel veel bestandsdescriptors benodigd zijn;
+ veel van de aanpasbaare waarden die standaard worden bepaald
+ door <varname>kern.maxusers</varname> kunnen individueel
+ worden overschreven tijdens het opstarten en/of tijdens het
+ draaien van het systeem in
+ <filename>/boot/loader.conf</filename> (zie de handleiding
+ &man.loader.conf.5; of het bestand
+ <filename>/boot/defaults/loader.conf</filename> voor een paar
+ aanwijzingen) of zoals elders beschreven in dit document.
+ <!--(rene) kill next sentence-->
+ Systemen die ouder zijn dan &os; 4.4 moeten deze waarden
+ instellen via de kerneloptie &man.config.8;
<option>maxusers</option>.</para>
+ <!--(rene) kill next sentence-->
<para>Voor oudere versies stelt het systeem deze waarde zelf in
als deze uitdrukkelijk op <literal>0</literal> is gezet.
@@ -2292,9 +2295,9 @@
</footnote>
<para>Als het gewenst is om deze waarde zelf aan te geven, wordt
- aangeraden om <literal>maxusers</literal> minstens op 4 te zetten, met
- name als het X Window systeem in gebruik is of als er
- software gecompileerd wordt. De reden hiervoor is dat de
+ aangeraden om <literal>maxusers</literal> minstens op 4 te
+ zetten, met name als het X Window systeem in gebruik is of als
+ er software gecompileerd wordt. De reden hiervoor is dat de
belangrijkste tabel die door <literal>maxusers</literal>
ingesteld wordt, het maximum aantal processen is, dat
ingesteld wordt op <literal>20 + 16 * maxusers</literal>, dus
@@ -2320,7 +2323,7 @@
<note>
<para><literal>maxusers</literal> stelt
<emphasis>geen</emphasis> grens aan het aantal gebruikers
- dat op de machine kan aanmelden. Het stelt gewoon
+ dat zich op de machine kan aanmelden. Het stelt gewoon
verschillende tabelgroottes in op redelijke waardes,
uitgaande van het maximum aantal gebruikers dat
waarschijnlijk de machine gebruikt en van het aantal
@@ -2329,7 +2332,7 @@
gelijktijdige aanmeldingen op afstand en X-terminalvensters
begrensd is <link
linkend="kernelconfig-ptys"><literal>pseudo-device pty
- 16</literal></link>. In &os; 5.X kan dit getal
+ 16</literal></link>. In &os; 5.X kan dit getal
genegeerd worden omdat daar het stuurprogramma &man.pty.4;
<quote>auto-cloning</quote> is. Er kan eenvoudig gebruik
worden gemaakt van de regel <literal>device pty</literal>
@@ -2342,20 +2345,20 @@
<indexterm><primary><varname>kern.ipc.somaxconn</varname></primary></indexterm>
- <para>De sysctl variabele <varname>kern.ipc.somaxconn</varname>
+ <para>De sysctl-variabele <varname>kern.ipc.somaxconn</varname>
beparkt de grootte van de luisterwachtrij voor het accepteren
- van nieuwe TCP verbindingen. De standaardwaarde van
+ van nieuwe TCP-verbindingen. De standaardwaarde van
<literal>128</literal> is meestal te laag voor robuuste
behandeling van nieuwe verbindingen in een zwaarbeladen
- webserver omgeving. Voor zulke omgevingen wordt aangeraden
+ webserveromgeving. Voor zulke omgevingen wordt aangeraden
deze waarde te verhogen tot <literal>1024</literal> of hoger.
De dienstdaemon beperkt misschien zelf de luisterwachtrij
(bijvoorbeeld &man.sendmail.8; of
<application>Apache</application>), maar heeft vaak een
mogelijkheid in een configuratiebestand de wachtrijgrootte
- aan te passen. Grote luisterwachtrijen zijn
- ook beter in het ontwijken van Ontzegging van Dienst
- (<abbrev>DoS</abbrev>) aanvallen.</para>
+ aan te passen. Grote luisterwachtrijen zijn ook beter in het
+ ontwijken van Ontzegging van Dienst (<abbrev>DoS</abbrev>)
+ aanvallen.</para>
</sect3>
</sect2>
@@ -2363,7 +2366,7 @@
<title>Netwerkbeperkingen</title>
<para>De kerneloptie <literal>NMBCLUSTERS</literal> bepaalt het
- aantal netwerk Mbufs dat beschikbaar is voor een systeem. Een
+ aantal netwerk-Mbufs dat beschikbaar is voor een systeem. Een
veel bezochte server met een laag aantal Mbufs beperkt de
mogelijkheden van &os;. Elk cluster staat voor ongeveer
2 K geheugen, dus een waarde van 1024 stelt 2 megabyte
@@ -2371,33 +2374,33 @@
netwerkbuffers. Een simpele berekening geeft aan hoeveel er
nodig is. Stel dat een webserver met een maximum van 1000
simultane verbindingen voor elke verbinding 16 K aan
- ontvangst netwerkbuffers en 16 K aan zendbuffers kost, dan
+ ontvangstnetwerkbuffers en 16 K aan zendbuffers kost, dan
is ongeveer 32 MB aan netbuffers nodig voor de webserver.
- Een goede vuistregel is te vermeniguldigen met twee,
- dus 2x32 MB / 2 KB = 64 MB /
+ Een goede vuistregel is te vermeniguldigen met twee, dus
+ 2x32 MB / 2 KB = 64 MB /
2 kB = 32768. Voor machines met veel geheugen wordt
4096 tot 32768 aangeraden. Er moet in geen geval een arbitrair
hoge waarde voor deze sysctl opgegeven worden, want dat kan
leiden tot een crash tijdens het opstarten. Met de optie
- <option>-m</option> van &man.netstat.1; kan clustergebruik
+ <option>-m</option> van &man.netstat.1; kan het clustergebruik
van het netwerk bekeken worden.</para>
<para>De loaderparameter <varname>kern.ipc.nmbclusters</varname>
- moet gebruikt worden om dit tijdens het opstarten toe te
- passen. Alleen voor oudere versies van &os; is het nodig om de
+ moet gebruikt worden om dit tijdens het opstarten toe te passen.
+ Alleen voor oudere versies van &os; is het nodig om de
kerneloptie <literal>NMBCLUSTERS</literal> te gebruiken.</para>
<para>Voor drukke servers die extensief gebruik maken van de
systeemaanroep &man.sendfile.2;, kan het nodig zijn het aantal
- &man.sendfile.2; buffers te verhogen via de kerneloptie
+ &man.sendfile.2;-buffers te verhogen via de kerneloptie
<literal>NSFBUFS</literal> of door de waarde in te stellen in
<filename>/boot/loader.conf</filename> (in &man.loader.8; staan
details). Als er in de procestabel processen staan met een
status <literal>sfbufa</literal> is dat een algemene indicator
- dat deze parameter aangepast moet worden. De sysctl variabele
- <varname>kern.ipc.nsfbufs</varname> is alleen-lezen en
- laat zien op welke waarde deze kernelvariabele is ingesteld.
- Deze parameter schaalt engiszins met de variabele
+ dat deze parameter aangepast moet worden. De sysctl-variabele
+ <varname>kern.ipc.nsfbufs</varname> is alleen-lezen en laat zien
+ op welke waarde deze kernelvariabele is ingesteld. Deze
+ parameter schaalt engiszins met de variabele
<varname>kern.maxusers</varname>, maar het kan nodig zijn om
deze bij te stellen.</para>
@@ -2414,10 +2417,10 @@
<indexterm><primary>net.inet.ip.portrange.*</primary></indexterm>
- <para>De sysctle variabelelen
- <varname>net.inet.ip.portrange.*</varname> bepalen welke
- reeks poortnummers automatisch gebonden wordt aan TCP en UDP
- sockets. Er zijn drie gebieden: een laag gebied, een
+ <para>De sysctl-variabelen
+ <varname>net.inet.ip.portrange.*</varname> bepalen welke reeks
+ poortnummers automatisch gebonden wordt aan TCP- en
+ UDP-sockets. Er zijn drie gebieden: een laag gebied, een
(standaard) middengebied en een hoog gebied. De meeste
netwerkprogramma's gebruiken het standaardbereik, wat
begrensd wordt door
@@ -2425,24 +2428,24 @@
<varname>net.inet.ip.portrange.last</varname> met
standaardwaarden van respectievelijk 1024 en 5000. Gebonden
poortreeksen worden gebruikt voor uitgaande verbindingen en
- het is onder bepaalde omstandigheden mogelijk dat poorten
- op raken. Dit gebeurt meestal in het geval van een zwaar
- belaste webproxy. Poortbereik is niet van belang als vooral
- diensten draaien die zich bezighouden met inkomende
- verbindingen, zoals een normale webserver, of als het aantal
- uitgaande verbindingen beperkt is, zoals bij een mailrelay.
- Voor situaties waarin een tekort aan poorten dreigt, wordt
+ het is onder bepaalde omstandigheden mogelijk dat poorten op
+ raken. Dit gebeurt meestal in het geval van een zwaar belaste
+ webproxy. Poortbereik is niet van belang als vooral diensten
+ draaien die zich bezighouden met inkomende verbindingen, zoals
+ een normale webserver, of als het aantal uitgaande
+ verbindingen beperkt is, zoals bij een mailrelay. Voor
+ situaties waarin een tekort aan poorten dreigt, wordt
aangeraden om <varname>net.inet.ip.portrange.last</varname>
bescheiden op te hogen. Een waarde van
<literal>10000</literal>, <literal>20000</literal> of
<literal>30000</literal> is redelijk. Er moet ook rekening
met effecten op firewalls gehouden worden als de poortreeks
- gewijzigd wordt. Sommige firewalls kunnen grote
- poortreeksen blokkeren, meestal de lagere poorten, en
- verwachten dat andere systemen hogere poorten gebruiken voor
- uitgaande verbindingen. Om deze reden wordt het niet
- aanbevolen om <varname>net.inet.ip.portrange.first</varname>
- te verlagen.</para>
+ gewijzigd wordt. Sommige firewalls kunnen grote poortreeksen
+ blokkeren, meestal de lagere poorten, en verwachten dat andere
+ systemen hogere poorten gebruiken voor uitgaande verbindingen.
+ Om deze reden wordt het niet aanbevolen om
+ <varname>net.inet.ip.portrange.first</varname> te
+ verlagen.</para>
</sect3>
<sect3>
@@ -2455,50 +2458,51 @@
<secondary><varname>net.inet.tcp.inflight.enable</varname></secondary>
</indexterm>
- <para>De TCP bandbreedtevertragingsproduct limitatie lijkt op
- TCP/Vegas in NetBSD. Het kan aangezet worden door de sysctl
- variabelel <varname>net.inet.tcp.inflight.enable</varname>
- de waarde <literal>1</literal> te geven. Het systeem
- tracht dan het bandbreedtevertragingssprodukt te berekenen
- voor elke verbinding en beperkt dan de hoeveelheid gegevens
- in de wachtrij naar het netwerk tot de hoeveelheid die
- vereist is om maximale doorvoer te kunnen handhaven.</para>
+ <para>De TCP-bandbreedtevertragingsproductlimitatie lijkt op
+ TCP/Vegas in NetBSD. Het kan aangezet worden door de
+ sysctl-variabele
+ <varname>net.inet.tcp.inflight.enable</varname> de waarde
+ <literal>1</literal> te geven. Het systeem tracht dan het
+ bandbreedtevertragingssprodukt te berekenen voor elke
+ verbinding en beperkt dan de hoeveelheid gegevens in de
+ wachtrij naar het netwerk tot de hoeveelheid die vereist is om
+ maximale doorvoer te kunnen handhaven.</para>
<para>Dit is nuttig bij gebruik van modems, Gigabit Ethernet of
- zelfs bij hoge snelheid WAN links (of elke andere link met
- een groot bandbreedtevertragingsprodukt), in het bijzonder
- als ook windowschaling of een groot verzendwindow gebruikt
- wordt. Als deze optie aangezet wordt, dient ook
- <varname>net.inet.tcp.inflight.debug</varname> de waarde
- <literal>0</literal> te krijgen (geen debugging) en voor
- produktiegebruik kan het instellen van
+ zelfs bij WAN-verbindingen met hoge snelheid (of elke andere
+ verbinding met een groot bandbreedtevertragingsprodukt), in
+ het bijzonder als ook windowschaling of een groot
+ verzendwindow gebruikt wordt. Als deze optie aangezet wordt,
+ dient ook <varname>net.inet.tcp.inflight.debug</varname> de
+ waarde <literal>0</literal> te krijgen (geen debugging) en
+ voor produktiegebruik kan het instellen van
<varname>net.inet.tcp.inflight.min</varname> naar minstens
- <literal>6144</literal> voordeel opleveren. Het instellen
- van hoge minima kan effectief het beperken van bandbreedte
- ondermijnen, afhankelijk van de link. De mogelijkheid tot
- limitering zorgt ervoor dat de hoeveelheid data die opgebouwd
- wordt, in tussentijdse route- en switchwachtrijen verlaagd
- kan worden en tevens kan de hoeveelheid gegevens die
+ <literal>6144</literal> voordeel opleveren. Het instellen van
+ hoge minima kan effectief het beperken van bandbreedte
+ ondermijnen, afhankelijk van de verbinding. De mogelijkheid
+ tot limitering zorgt ervoor dat de hoeveelheid gegevens die
+ opgebouwd wordt, in tussentijdse route- en switchwachtrijen
+ verlaagd kan worden en tevens kan de hoeveelheid gegevens die
opgebouwd wordt in de interfacewachtrij van de lokale host
- verlaagd worden. Met minder pakketten in wachtrijen, kunnen
+ verlaagd worden. Met minder pakketten in wachtrijen kunnen
interactieve verbindingen opereren met lagere
- <emphasis>Round Trip</emphasis> tijden, met name over
- langzame modems. Deze optie gaat alleen over datatransmissie
- (upload / serverkant) en heeft geen effect gegevensontvangst
- (download / clientkant).</para>
+ <emphasis>Round Trip</emphasis> tijden, met name over langzame
+ modems. Deze optie gaat alleen over datatransmissie (upload /
+ serverkant) en heeft geen effect gegevensontvangst (download /
+ cliëntkant).</para>
<para>Aanpassen van
<varname>net.inet.tcp.inflight.stab</varname> wordt
<emphasis>niet</emphasis> aangeraden. Deze parameter krijgt
- standaard een waarde van 20, wat 2 maximale pakketten
- opgeteld bij de bandbreedtevensterberekening representeert.
- Het extra venster is nodig om het algoritme stabiel te houden
- en om de reactietijd bij veranderende omstandigheden te
- verbeteren, maar het kan ook leiden tot langere pingtijden
- over langzame verbindingen (zonder het inflight algoritme kan
- dit echter nog erger zijn). In dergelijke gevallen kan deze
- parameter misschien verlaagd worden naar 15, 10 of 5 en
- misschien moet voor het gewenste effect ook
+ standaard een waarde van 20, wat 2 maximale pakketten opgeteld
+ bij de bandbreedtevensterberekening representeert. Het extra
+ venster is nodig om het algoritme stabiel te houden en om de
+ reactietijd bij veranderende omstandigheden te verbeteren,
+ maar het kan ook leiden tot langere pingtijden over langzame
+ verbindingen (zonder het inflight-algoritme kan dit echter nog
+ erger zijn). In dergelijke gevallen kan deze parameter
+ misschien verlaagd worden naar 15, 10 of 5 en misschien moet
+ voor het gewenste effect ook
<varname>net.inet.tcp.inflight.min</varname> verlaagd worden
(bijvoorbeeld naar 3500). Het verlagen van deze parameters
moet pas in laatste instantie overwogen worden.</para>
@@ -2512,15 +2516,15 @@
<title><varname>kern.maxvnodes</varname></title>
<para>Een vnode is de interne representatie van een bestand of
- een map. Het verlagen van het aantal beschikbare vnodes
- voor het besturingssysteem leidt dus tot een daling van disk
- I/O. Normaliter wordt dit door het besturingssysteem
- afgehandeld en hoeft de instelling niet gewijzigd te worden.
- Im sommige gevallen kan disk I/O de beperkende factor zijn en
- kan het systeem alle beschikbare vnodes in gebruik hebben.
- Dan dient deze instelling gewijzigd te worden. De
- hoeveelheid inactief en beschikbaar RAM dient meegenomen te
- worden in de beslissing.</para>
+ een map. Het verlagen van het aantal beschikbare vnodes voor
+ het besturingssysteem leidt dus tot een daling van schijf-I/O.
+ Normaliter wordt dit door het besturingssysteem afgehandeld en
+ hoeft de instelling niet gewijzigd te worden. Im sommige
+ gevallen kan schijf-I/O de beperkende factor zijn en kan het
+ systeem alle beschikbare vnodes in gebruik hebben. Dan dient
+ deze instelling gewijzigd te worden. De hoeveelheid inactief
+ en beschikbaar RAM dient meegenomen te worden in de
+ beslissing.</para>
<para>Het huidige aantal gebruikte vnodes kan als volgt bekeken
worden:</para>
@@ -2540,8 +2544,8 @@
gehouden te worden. Als de waarde weer tot aan het maximum
stijgt, dan moet <varname>kern.maxvnodes</varname> verder
opgehoogd worden. Er dient een verschuiving op te treden in
- het door &man.top.1; gerapporteerde geheugengebruik. Er
- hoort meer geheugen actief te zijn.</para>
+ het door &man.top.1; gerapporteerde geheugengebruik. Er hoort
+ meer geheugen actief te zijn.</para>
</sect3>
</sect2>
</sect1>
@@ -2558,23 +2562,21 @@
een wisselbestand maken op een bestaande (UFS of andere)
partitie.</para>
- <para>Voor informatie over het beveiligen van het wisselbestand,
- welke opties hiervoor bestaan, en waarom dit gedaan zou moeten
- worden, kijk dan in <xref linkend="swap-encrypting"> van het
- handbook.</para>
+ <para>Kijk voor informatie over het beveiligen van het
+ wisselbestand, welke opties hiervoor bestaan, en waarom dit gedaan
+ zou moeten worden in <xref linkend="swap-encrypting"> van het
+ handboek.</para>
<sect2 id="new-drive-swap">
- <title>Wisselbestand (partitie) op een nieuwe harde
- schijf</title>
+ <title>Wisselbestand (partitie) op een nieuwe harde schijf</title>
- <para>Dit is natuurlijk de beste manier om de
- wisselbestandsruimte te vergroten en een goed excuus om een
- extra harde schijf toe te voegen. Die komt immers altijd wel
- van pas. In dat geval kan het beste de discussie over
- wisselbestandruimte in <xref linkend="configtuning-initial">
- nog eens herlezen worden om wat suggesties te krijgen over hoe
- wisselbestandpartitie(s) het beste ingedeeld kunnen
- worden.</para>
+ <para>Dit is natuurlijk de beste manier om de wisselbestandsruimte
+ te vergroten en een goed excuus om een extra harde schijf toe te
+ voegen. Die komt immers altijd wel van pas. In dat geval kan
+ het beste de discussie over wisselbestandruimte in <xref
+ linkend="configtuning-initial"> nog eens herlezen worden om
+ wat suggesties op te doen over hoe wisselbestandpartitie(s) het
+ beste ingedeeld kunnen worden.</para>
</sect2>
<sect2 id="nfs-swap">
@@ -2582,18 +2584,18 @@
<para>In het algemeen wordt swappen over NFS niet aangeraden
behalve als het onmogelijk is om naar een lokale schijf te
- swappen. NFS swappen wordt gelimiteerd door de hoeveelheid
- beschikbare bandbreedte en belast het de NFS server.</para>
+ swappen. NFS-swappen wordt gelimiteerd door de hoeveelheid
+ beschikbare bandbreedte en belast het de NFS-server.</para>
</sect2>
>>> TRUNCATED FOR MAIL (1000 lines) <<<
More information about the p4-projects
mailing list