Het hoe en waarom van Linux partities

[Verwijderd]

Ben eindelijk begonnen met Linux, heb hiervoor RedHat 7.3 gedownload en het installeren ging vrijwel probleemloos.

Het enige waar ik op vastliep was het partitioneren. Uit een aantal FAQ's had ik begrepen dat je het beste Linux over verschillende partities kon verdelen. Ik had hiervoor speciaal een 12GB schijf leeg gemaakt.

Maar handmatig kreeg ik het niet gepartitioneerd/geinstalleerd. Dus maar automatisch met DiskDruid geprobeerd.
Op zich ging dat ook niet zo geweldig, alleen als ik de root op die 12GB zette kon ik verder.

Uiteindelijk is alles ge-installeerd maar het draait nu vreselijk langzaam. Opstarten kost ong. 8 minuten op een 400 Mhz AMD K6 machine met 256MB RAM.

Als ik Knoppix op dezelfde machine draai gaat het aanzienlijk vlotter, terwijl dat regelmatig naar de CD-ROM moet kijken. Beide draaien dan KDE.

Dus begin ik te twijfelen of het wel zo verstandig is geweest om alles op 1 partitie van 12GB te stoppen.

Maar in alle FAQ's en HOWTO's staat wel hoe je moet partitioneren maar niet zozeer waarom dit zo zou moeten.

Ik ben vooral benieuwd wat voor invloed dit partitioneren heeft op de performance.

Bijvoorbeeld de swap partitie, als die 512MB wordt op een eigen partitie, gaat het dan echt een stuk vlotter?

[Acropia]

SWAP moet je zoiezo een eigen partitie geven. Vergelijk het partitioneren maar eens met een archief...

Als jij 1237234 A4tjes door elkaar hebt liggen, is 1 bepaald velletje moeilijk terug te vinden. Verdeel je nu alles per beginletter, op alphabetische volgorde in archiefkasten, dan kun je het al veel sneller vinden
Verdeel je het binnen die kasten ook nog eens alphabetische op 2e letter, dan kun je het nog weer sneller vinden...

Dus SWAP een eigen partitie, verder zou je /boot een eigen partitie kunnen geven, en /home en /var ook... denk dat de performance van je systeem dan al een stuk beter zou zijn...

[Allochtoon]

Toen ik met linux begon zat ik ook met dezelfde vraag, immers bij windows had je geen aparte partitie nodig voor de swap! Het word door elke distrobouwer aangeraden dus ik zou idd een partitie voor swap aanmaken.

[kroeske]

een swap partitie aanmaken is altijd verstandig en zou de boel ook wel enigszins kunnen versnellen. daarnaast is het misschien handig om te kijken of dma aanstaat (hdparm /dev/hdx om te kijken wat de stand van zaken is en hdparm -c1 -d1 /dev/hdx om dma en i/o support aan te zetten (hdx ff vervangen met het juiste device (meestal hda of hdb met een IDE drive)) bij de eerste boot wil ook nog wel eens eea geconfigureerd worden, bij mandrake bijvoorbeeld kan je eerste boot nog wel eens een tijdje duren als je sendmail geinstalleerd hebt.

[Gomez12]

Volgens mij heeft partitioneren weinig invloed op een harde schijf qua performance ( behalve dan dat het binnenste gedeelte van je hdd sneller is dan het buitenste gedeelte ( dacht ik)) maar het langzaam opstarten heeft denk ik meer te maken met het feit dat in knoppix een aantal services aanstaan en dat jij in Redhat een hele zooi extra modules / services opstart. Knoppix is geoptimaliserd voor een pc. Redhat kan je alles zelf installeren dus kijk eens goed wat je bij redhat geinstalleerd hebt.

vb : Heb je bij redhat opgegeven dat je je ip via dhcp krijgt dan 10 sec wachten als er geen dhcp server in je netwerk draait etc. etc.

Ik denk dus niet dat het met je partities te maken heeft maar meer met het feit dat je bij redhat te veel hebt aangeklikt om te installeren.

Kijk bij je redhat install eens goed naar je /etc/init.d dir en zoek uitwat je hiervan echt gebruikt.

[Verwijderd]

een leuk vertragend element is sendmail, als je die hebt geinstalleerd....die wil nog wel eens een tijdje 'vastlopen' als hij dnslookups gaat doen die hij niet kan vinden.
Kan je tijdens het booten aan de messages zien die over je beeld lopen of er een specifiek programma of init procedure is die er lange tijd over doet?

[JaQ]

Acropia schreef op 06 augustus 2003 @ 12:33:
SWAP moet je zoiezo een eigen partitie geven. Vergelijk het partitioneren maar eens met een archief...

<<snip>>

Dus SWAP een eigen partitie, verder zou je /boot een eigen partitie kunnen geven, en /home en /var ook... denk dat de performance van je systeem dan al een stuk beter zou zijn...

Disk-druid maakt automagisch in ieder geval een / en een swap aan (zo dom zijn die partitie tooltjes nou ook weer niet, nofi). Denk dus niet dat de performance in dit geval aan de partitionering ligt.

Bovendien op een 12 GB schijf je disk-access je bottle-neck?.. come on.. RedHat gebruikt volgens mij automagisch ext3, dus bijna geen fragmentatie en hoezo zou een partitie helpen bij performance bij zo'n kleine schijf?

Waaruit concludeer je dat je partities of je schijf je probleem zijn? Denk zelfs dat dat je probleem helemaal niet is. Wat heb je voor processen draaien? Iets meer info daarover zou handig zijn.

[hereweare67893]

Ik heb zelf ook een aparte partitie voor swap en voor /, echter had ik bij een vorige installatie ook een aparte partitie voor /home, maar dat vond ik erg vervelend werken. Ik had te veel ruimte toebedeeld aan /home, zodat mijn / volliep en op een gegeven moment te weinig ruimte had. Erg vervelend had om dat te fixen, iig toen wel voor mij
Van performance verschil merk ik eerlijk gezegd weinig.

[Verwijderd]

Snelheidswinst/performancewinst????

Dat is lijkt me alleen maar waar als je 2 fysiek verschillende schijven (en controllers) hebt.

Dat het verstandig is om te partitioneren (als is 't alleen maar vanwege 't overzicht. Zie Acropia's antwoord) staat als een paal boven water. Beter is 't om meerdere fysieke hd's te hebben en dan slim 't een en ander te verdelen.

Misschien een beetje off-topic, maar kijk eens naar hfs, daar staat beschreven wat waar zou moeten staan:

http://www.pathname.com/fhs/2.2/

[Acropia]

Die performance zal bij een schijf/partitie van 12GB inderdaad zowat te verwaarlozen zijn... Maar in het geval van schijven boven de 40GB, die constant vol en leeg gepompt worden via verschillende wegen, is die performance zeker wel te merken...

De oorzaak van dat trage opstarten ligt iig niet aan die partities... zal inderdaad eerder een niet de vinden dhcp server of iets dergelijks zijn...

[Verwijderd]

Verwijderd schreef op 06 August 2003 @ 12:38:
een leuk vertragend element is sendmail, als je die hebt geinstalleerd....

Inderdaad, tot aan SendMail loopt alles vlot. Maar SendMail zelft duurt bijna 3 minuten. Zal dus eens kijken of dat uit kan, is toch een SMTP server?

Goed, dat alles op 1 partitie staat kan dus niet de oorzaak zijn van de traagheid.

Ik heb RedHat ge-installeerd met de standaard instellingen van DeskTop. Ik snapte ook al niet waarom SendMail gestart werd. Wel heb ik KDE en Gnome er op staan om te kijken welke nou het lekkerst werkt.

Ik heb ook een CPU meter gevonden die aangaf dat de computer op idle al zo'n 20% CPU verbruikte. Toen ik TuxRacer erbij opstarte was dit niet vooruit te branden. Alleen al het introscherm met muziek gaf al 90% CPU (User + System).

Als ik het goed begrijp is er geen technische/performance noodzaak om verschillende partities te gebruiken. Het is alleen aan te bevelen vanuit dezelfde redenen waarom het verstandig is om onder windows je OS, Data, Programmatuur en swap op verschillende partities te zetten.
Alleen Linux is daar iet meer sturend in terwijl je onder Windows nog wel een C: schijf van 80GB vind.

[deadinspace]

Verwijderd schreef op 06 August 2003 @ 12:28:
Het enige waar ik op vastliep was het partitioneren. Uit een aantal FAQ's had ik begrepen dat je het beste Linux over verschillende partities kon verdelen. Ik had hiervoor speciaal een 12GB schijf leeg gemaakt.

Ik vind het gebruik van veel partities overrated

Het gebruik van veel partities heeft enkele voordelen:
• Als bijvoorbeeld je /tmp partitie volloopt, dan beïnvloedt dat andere partities, zoals /var (waar bijvoorbeeld logs op staan) niet. Dit is echter ook te bereiken met goed ingestelde quota's.
• Als je veel partities gebruikt, dan kun je in principe voor elke partitie een filesystem kiezen dat bij het beste bij het gebruik van die partitie past. XFS voor /usr, ReiserFS voor /var en ext3 voor /home, om maar wat te noemen. In theorie kun je hiermee wat snelheidswinst halen, in de praktijk is het veel gedoe en doet vrijwel niemand het.
• Als je veel partities hebt, en één van die partities raakt beschadigd, dan zijn de andere partities nog heel. Het is alleen de vraag wat je hebt aan /tmp als je / kapot is
• /home en / op aparte partities kan handig zijn. Als je bijvoorbeeld je systeem om zeep helpt (doordat je als beginner wat te enthousiast experimenteerde bijvoorbeeld), dan kun je makkelijk herinstalleren met behoud van je /home (en dus van je persoonlijke files). Ook overstappen op een ander OS/distro met behoud van je /home is zo makkelijker.
• Swap kan zowel op een aparte partitie als in een file op een bestaande partitie. Maar swap in een aparte partitie is sneller. De reden hiervoor is dat swap in een file via de filesystem drivers en dergelijke heen moet, wat extra werk is. De kernel kan een losse swappartitie gewoon behandelen alsof het een lineair stuk geheugen is, wat makkelijker en sneller is.

Naar mijn mening zijn alleen de laatste twee van deze punten de moeite waard, maar smaken verschillen natuurlijk.

De grote nadelen van meerdere partities zijn:
• Meer gedoe/rompslomp om op te zetten en evt beheren.
• Partities blijken altijd te groot of te klein.

Vooral de laatste is iets waar veel mensen (inclusief ikzelf) over vallen. Je / is veel te groot, terwijl je al maanden met ruimte-problemen in /usr kampt. En je wil een programma gebruiken dat veel tijdelijke ruimte nodig heeft, maar je /tmp is te klein gekozen, dus dat wil niet zo. Je moet dan dus herpartitioneren (wat herinstalleren betekent), of je partities resizen, wat minstens een reboot kost.

Mijn raad? Ga, zeker als je beginner bent, niet klooien met teveel partities. Swap op een aparte partitie. Als je van plan bent te herinstalleren of andere OSsen/distro's uit te proberen kan een aparte /home partitie handig zijn. Neem dus of / en swap, of /, /home en swap. Niet meer partities dan dat.

Uiteindelijk is alles ge-installeerd maar het draait nu vreselijk langzaam. Opstarten kost ong. 8 minuten op een 400 Mhz AMD K6 machine met 256MB RAM.

Ik zou zeggen, controleer of DMA aanstaat op je HDs, en vertel eens wat er precies zo lang duurt. Wellicht is het een DNS timeout ergens (zoals al genoemd ergens hierboven).

Dus begin ik te twijfelen of het wel zo verstandig is geweest om alles op 1 partitie van 12GB te stoppen.

Dat zal het hem niet zijn hoor

DrFrankenstoner schreef op 06 August 2003 @ 12:39:
RedHat gebruikt volgens mij automagisch ext3, dus bijna geen fragmentatie

En wat heeft ext3 met fragmentatie te maken?

Verwijderd schreef op 06 August 2003 @ 13:29:
Inderdaad, tot aan SendMail loopt alles vlot. Maar SendMail zelft duurt bijna 3 minuten. Zal dus eens kijken of dat uit kan, is toch een SMTP server?

Sendmail is een SMTP server ja, maar sendmail zelf zal waarschijnlijk niet de oorzaak zijn, falende DNS resolving is dat waarschijnlijk.

Ik heb RedHat ge-installeerd met de standaard instellingen van DeskTop. Ik snapte ook al niet waarom SendMail gestart werd.

Het is bij Unices gangbaar dat een machine een lokale mailserver draait

Ik heb ook een CPU meter gevonden die aangaf dat de computer op idle al zo'n 20% CPU verbruikte.

Wat gebruikt er dan precies CPU?

Toen ik TuxRacer erbij opstarte was dit niet vooruit te branden. Alleen al het introscherm met muziek gaf al 90% CPU (User + System).

Dat is waarschijnlijk afwezige hardware 3D acceleratie. Tuxracer is een OpenGL spel, en als die OpenGL in software gerenderd moet worden is het erg traag.

[ Voor 15% gewijzigd door deadinspace op 06-08-2003 13:59 ]

[blender]

Wil nog even aan de post van deadin~1 toevoegen dat het eerste puntje te maken heeft met security. Als je /tmp bijvoorbeeld niet als aparte partitie hebt en hij begint vol te lopen is dit direct van invloed op de rest van de partitie waar /tmp op staat. Bij aparte partities dus niet.

Verder wil het nog wel eens helpen om je swap partitie op een aparte schijf te zetten als je die hebt. Die aparte schijf moet je dan aan een andere controller hangen.

Dat het systeem van de TS er zo lang overdoet om op te starten komt volgens mij ook doordat hij teveel laat opstarten... (of liever, de standaard Desktop install van RH73 doet dat)

[Verwijderd]

Parities zijn ook een simpele vorm van quota's
Je wilt b.v. niet dat er voor /var niet meer genoeg ruimte is zodat je logfiles niet meer worden gemaakt...
Dan krijg je dingen zoals dit "warning: /var almost out of spa"

[deadinspace]

blender schreef op 06 August 2003 @ 13:59:
Wil nog even aan de post van deadin~1 toevoegen dat het eerste puntje te maken heeft met security. Als je /tmp bijvoorbeeld niet als aparte partitie hebt en hij begint vol te lopen is dit direct van invloed op de rest van de partitie waar /tmp op staat. Bij aparte partities dus niet.

En zoals ik ook opmerkte is dit ook op te lossen met quota's. Met quota's is het zelfs netter en vooral veel flexibeler.

Dat het systeem van de TS er zo lang overdoet om op te starten komt volgens mij ook doordat hij teveel laat opstarten... (of liever, de standaard Desktop install van RH73 doet dat)

Red hat mag dan default niet zuinig zijn met geinstalleerd spul, maar ik geloof er niks van dat het daardoor komt dat het opstarten 8 minuten duurt

[Verwijderd]

Het heeft dus (voor een deel) te maken met het bekende DNS name resolving van sendmail. Heb je je DNS servers goed ingesteld staan in je /etc/resolve.conf?

[ritsjoena]

Op oudere machines moeten de boot elementen onder de 1024 sector (?) staan. Als je meer ruimte ruimte voor je root wil hebben is een aparte partitie van zeg 20MB geen gek idee. RH 7.3 disk druid gaat hiervan uit.

Swap is een eigen filesysteem (ik dacht zelfs een rauwe memory dump) en heeft een daarvoor passende partitie nodig.

Het is vaak handig om systeem software en persoonlijke data van elkaar gescheiden te houden (/home)

Ik denk dat het er in praktijk vanaf hangt wat je ermee doet. Zelf gebruik ik de volgende partities
2x windows (boven en onder de 1024)
/boot
SWAP
/ (root) voor de rest

Ik meen me te herinneren dat het meest optimale voor swap even groot als het geheugen was, maar dat kan inmiddels achterhaald zijn.

Vraagje waarom RH 7.3 en niet gelijk 9 (of eventueel 8 )?

edit: smileys zijn leuk maar soms veranderen ze je tekst onbedoeld.

[ Voor 6% gewijzigd door ritsjoena op 06-08-2003 14:22 ]

[Verwijderd]

Nog een klein snelheidsgerelateerd tipje:
het werd al gezegd, hd's zijn sneller naarmate je dichter bij het begin van de drive bent.

Dus heb je linux op een pc met 128MB geheugen (waar het zeer waarschijnlijk is dat je met een webbrowser, wat gimpen en xmms enzo onder een zware de/wm zoals kde de swap gaat gebruiken) zet dan als eerste de swap partitie; heb je 1GB doe dan de systeem / partitie het meeste vooraan (geen windows installeren! gewoon / vooraan, daarna evt ~512MB swap en daarna je /home enzo).

Of het uitmaakt?

Geen flauw idee. Theoretisch kan je het niet beter doen, dus waarom niet..

[Verwijderd]

deadin~1, bedankt voor je uitleg.

Ik heb nog niet gekeken wat de instellingen zijn van de DNS. Maar het systeem krijgt z'n info via DHCP van m'n router zodat ik er voor het gemak even vanuit ga dat alles goed staat.

Ik zal eens een aantal dingen uit gaan zetten, SendMail als eerste.

ritsjoena schreef op 06 August 2003 @ 14:20:
Vraagje waarom RH 7.3 en niet gelijk 9 (of eventueel 8 )?

Eigenlijk geen idee. Ik volg Linux al een hele tijd en had destijds een kopietje van 7.2 gemaakt. Maar toen ik die eindelijk wilde installeren bleek die niet bootable. Toen bleek 7.2 niet meer downloadable te zijn en 7.3 wel.
Ik wil graag RedHat omdat de meeste cursussen ermee gegeven worden. Weet eigenlijk niet eens het grote verschil tussen 7.3, 8 en 9 (Kernel?).

[Acropia]

Nieuwere kernel, veel bugs uitgeroeid, weet niet of 7.3 al standaard ext3 had, maar daarna is ext3 iig de standaard geworden...

[JaQ]

deadin~1 schreef op 06 augustus 2003 @ 13:49:
[...]
En wat heeft ext3 met fragmentatie te maken?
[...]

offtopic:
ext3 gaat op een vergelijkbare wijze als ntfs met je filesystem om. Een bak data wordt in het eerste de beste passende block gedrukt. Door het journal wat ext3 gebruikt, is dit 95% van de tijd het eerste aansluitende blok. (dus zelfs nog wat slimmer dan ntfs) Dit is nou precies het grote voordeel van het gebruik maken van een journaling filesystem.

Maar goed, allemaal offtopic

edit:
maar dan wel met correct qoute tags

[ Voor 7% gewijzigd door JaQ op 06-08-2003 14:52 ]

[deadinspace]

ritsjoena schreef op 06 August 2003 @ 14:20:
Op oudere machines moeten de boot elementen onder de 1024 sector (?) staan. Als je meer ruimte ruimte voor je root wil hebben is een aparte partitie van zeg 20MB geen gek idee.

Ohja, dat was ik vergeten, al heb ikzelf dat probleem werkelijk nog nooit gehad
Ook als je je / op softare raid wil moet je een aparte /boot hebben btw.

Verwijderd schreef op 06 August 2003 @ 14:41:
Ik heb nog niet gekeken wat de instellingen zijn van de DNS. Maar het systeem krijgt z'n info via DHCP van m'n router zodat ik er voor het gemak even vanuit ga dat alles goed staat.

Mja, toch maar even controleren, je weet nooit. Het zou ook kunnen dat hij de hostname van je computer zelf niet kan resolven, omdat er wat ontbreekt in /etc/hosts.

DrFrankenstoner schreef op 06 August 2003 @ 14:52:
ext3 gaat op een vergelijkbare wijze als ntfs met je filesystem om. Een bak data wordt in het eerste de beste passende block gedrukt. Door het journal wat ext3 gebruikt, is dit 95% van de tijd het eerste aansluitende blok. (dus zelfs nog wat slimmer dan ntfs) Dit is nou precies het grote voordeel van het gebruik maken van een journaling filesystem.

Journaling heeft alleen dus geen ruk met fragmentatie te maken. De ext2 en ext3 drivers zijn gelijk, op de toegevoegde journaling na. De fragmentatie zal dus bij ext2 en ext3 onder gelijke omstandigheden hetzelfde zijn.

Bovendien gaat het hier om een pas geinstalleerd systeem, dus fragmentatie doet helemaal niet ter zake.

[JaQ]

deadin~1 schreef op 06 augustus 2003 @ 16:06:
[...]

Journaling heeft alleen dus geen ruk met fragmentatie te maken. De ext2 en ext3 drivers zijn gelijk, op de toegevoegde journaling na. De fragmentatie zal dus bij ext2 en ext3 onder gelijke omstandigheden hetzelfde zijn.

Bovendien gaat het hier om een pas geinstalleerd systeem, dus fragmentatie doet helemaal niet ter zake.

Ik ben het ook meer dan eens met de punten die je noemt (verder naar boven). Volgens mij is disc-access niet het probleem waar de TS mee zit, maar eerder de processen die draaien op z'n machine (wachten op meer info dus).

Ik ben het niet met je eens dat journaling niet ter zake doet bij fragmentatie. De journaling techniek die ext3 gebruikt zorgt juist voor verminderde fragmentatie t.o.v. bijvoorbeeld ext2, fat of fat32. Juist hoe bestanden fysiek op je schijf worden gezet is van belang bij fragmentatie en laat nou net het journal dat gebruikt wordt bij ext3 hier wat leuke grappen mee uithalen.

Maar goed, misschien ben ik maar een n00b en snap ik e.e.a. niet zo goed als dat jij dat doet (ik ben ook geen ex-modje NOS natuurlijk, niet dat modjes altijd alles beter weten, maar toch). Ik zal voor de zekerheid nog eens wat docjes na gaan lezen om te kijken of ik e.e.a. niet verkeerd heb begrepen

[deadinspace]

DrFrankenstoner schreef op 06 August 2003 @ 16:17:
Ik ben het niet met je eens dat journaling niet ter zake doet bij fragmentatie. De journaling techniek die ext3 gebruikt zorgt juist voor verminderde fragmentatie t.o.v. bijvoorbeeld ext2, fat of fat32. Juist hoe bestanden fysiek op je schijf worden gezet is van belang bij fragmentatie en laat nou net het journal dat gebruikt wordt bij ext3 hier wat leuke grappen mee uithalen.

Uit Documentation/filesystems/ext3.txt uit de Linux source tree:

code:

ext3 shares all disk implementation with ext2 filesystem, and add
transactions capabilities to ext2.  Journaling is done by the
Journaling block device layer.

Daar maak ik toch echt uit op dat ext3 alleen de journaling mogelijkheden toevoegt, en dat alle overige dingen, waaronder de allocation algorithms - die grotendeels verantwoordelijk zijn voor (het voorkomen van) fragmentatie - hetzelfde zijn als bij ext2.

Overigens is dat iets dat helemaal niks met ext2 en ext3 te maken heeft eigenlijk, maar meer met de implementatie ervan in de Linux kernel. Het zou best kunnen dat de huidige ext2/3 driver in recente kernels verbeteringen heeft tov de driver in bijvoorbeeld Linux 1.0.0, maar dat is dan niet ext3-specifiek; ext2 filesystems profiteren daar ook van.

Dat moet ook wel, aangezien de disk-layout van beide filesystems nog altijd hetzelfde is (afgezien van de toegevoegde journal inode bij ext3), en de mogelijke (fragmentatie-) optimalisaties voor beiden FSen dus hetzelfde zijn

[JaQ]

deadin~1 schreef op 06 augustus 2003 @ 17:28:
[...]

Uit Documentation/filesystems/ext3.txt uit de Linux source tree:

code:

ext3 shares all disk implementation with ext2 filesystem, and add
transactions capabilities to ext2.  Journaling is done by the
Journaling block device layer.

Daar maak ik toch echt uit op dat ext3 alleen de journaling mogelijkheden toevoegt, en dat alle overige dingen, waaronder de allocation algorithms - die grotendeels verantwoordelijk zijn voor (het voorkomen van) fragmentatie - hetzelfde zijn als bij ext2.

Overigens is dat iets dat helemaal niks met ext2 en ext3 te maken heeft eigenlijk, maar meer met de implementatie ervan in de Linux kernel. Het zou best kunnen dat de huidige ext2/3 driver in recente kernels verbeteringen heeft tov de driver in bijvoorbeeld Linux 1.0.0, maar dat is dan niet ext3-specifiek; ext2 filesystems profiteren daar ook van.

Dat moet ook wel, aangezien de disk-layout van beide filesystems nog altijd hetzelfde is (afgezien van de toegevoegde journal inode bij ext3), en de mogelijke (fragmentatie-) optimalisaties voor beiden FSen dus hetzelfde zijn

Helaas moet ik je gelijk geven. Journaling filesystems in z'n algemeenheid hebben minder fragmentatie, ik dacht dat dit ook gelde voor ext3, helaas niet dus. Volgende keer iets beter lezen dus.

docs:
http://freshmeat.net/articles/view/212/
http://www.csce.uark.edu/...ures/Filesystems-attr.pdf en
http://www.eandm.co.il/presentations/TandT_Linux/hagit.pdf

[CyBeR]

Het niet hebben van meerdere partities is GEEN invloed op de snelheid van je systeem. Ook het niet hebben van een aparte swappartitie is (als je er snel genoeg achter bent gekomen, zie onder) geen merkbare vertragende factor.

* CyBeR werkt al jaren met 1 root partitie (er bestaan wel andere maar die zijn speciaal, zoals drivers voor macos, een macos partitie om te booten, enz.)

Tegenwoordig heb ik ook weer netjes een swappartitie, omdat ik er voor de gein aan dacht bij het installeren Dat had ik dus eerst niet, en toen heb ik zelfs voor het installen van packages al 3 swap files van 128MB gemaakt en die in /boot gepleurd. Je hebt op deze manier mischien een heel klein beetje filesystem overhead, maar nauwelijks fragmentatieproblemen. Dit laatste is de grootste vertragende factor. Als je dus pas na een paar dagen merkt dat je geen swap had gemaakt, zal dat wel het geval zijn.

Het handige overigens aan files is dat je ze weg kunt pleuren als je net nog een klein beetje extra ruimte nodig hebt


Over sendmail/apache die nodig namen moeten resolven: zorg dat die pas starten nadat je een internetverbinding hebt gemaakt. Zo simpel

[deadinspace]

CyBeR schreef op 06 August 2003 @ 18:59:
Ook het niet hebben van een aparte swappartitie is (als je er snel genoeg achter bent gekomen, zie onder) geen merkbare vertragende factor.

In http://www.codemonkey.org.uk/post-halloween-2.5.txt lees ik:

Due to various changes, swap files should be just as fast as swap partitions.

Waaruit ik concludeer dat in 2.4 en eerdere kernels swapfiles trager zijn dan swappartities. Of dat puur en alleen door fragmentatie komt weet ik niet.

Het handige overigens aan files is dat je ze weg kunt pleuren als je net nog een klein beetje extra ruimte nodig hebt

True

Over sendmail/apache die nodig namen moeten resolven: zorg dat die pas starten nadat je een internetverbinding hebt gemaakt. Zo simpel

localhost resolven moet toch echt daarvoor al lukken hoor

[Verwijderd]

Gisteravond weer druk bezig geweest. De opstart tijd is iets verbeterd, van 8 minuten naar 6:20 Met name door het uitzetten van een aatal services. Maar SendMail blijft 2:40 'hangen' en het opstarten van KDE blijft 2:10.

Ik ben er inmiddels van overtuigd dat het niet de partities zijn. Het lijkt gewoon of ik een 40Mhz processor heb ipv een 400Mhz.

Als ik onder RedHat/KDE de systemguard aanzet om de CPU te volgen verbruikt SysGuard zelf al minimaal 25% CPU! Start ik Knoppix3.2 met KDE (ook 3.2?) dan geeft de SysGuard 10% CPU op idle aan.

Opvallen is dat de services lijst op RedHat twee pagina's is. Op Knoppix is dat maar driekwart. Je zou kunnen zeggen dat dit de oorzaak is. Maar als je kijkt wat al die processen aan CPU vreten is dat niks, ze staan bijna allemaal op 0.00. Alleen X11 schommelt tussen de 2 en 5%

Ik begrijp dat eyecandy CPU kost, maar zo is Linux absoluut onwerkbaar. Bijv het starten van Konqueror kost alleen al een minuut.

CyBeR schreef op 06 augustus 2003 @ 18:59:
Over sendmail/apache die nodig namen moeten resolven: zorg dat die pas starten nadat je een internetverbinding hebt gemaakt. Zo simpel

eth0 is al op wanneer SendMail gestart wordt.

Maar hoe voorkom ik dat SendMail gestart wordt? Ik kan 'm wel in de services lijst uitvinken, maar bij het opstarten komt 'ie wel terug.

IK heb het systeem nu opnieuw ge-installeerd maar nu met 4 partities en Gnome. Maar toen was het tijd voor de BBQ

[ACM]

Je kan sendmail gewoon uitzetten, voor het verzenden van mail vanaf je lokale doos is het in principe niet nodig dat sendmail continue draait.

KDE is gewoon zwaar of dat sneller kan zou ik niet weten, services in linux gebruiken normaliter overigens weinig cpu. Maar wat je wellicht eens kan doen is de default-runtime van 5 naar 3 veranderen (/etc/inittab ) zodat je iig kan zien hoelang het opstarten van alles _zonder_ X duurt.

Daarna kan je inloggen en 'startx' uitvoeren om te kijken hoelang het starten van X + kde duurt.
Uiteraard eerst even kijken wat je cpu-gebruik daarvoor is (met top bijvoorbeeld).

sendmail uitzetten:
startup en dan in het menutje es zoeken naar een services-configuratie applicatie. Of op de commandline naar de /etc/rc.d dir gaan en daar in de rcX.d dir's de linkjes ala SXXsendmail en KXXsendmail te verwijderen.

Niet het 'sendmail' script uit de init.d dir verwijderen.

[ Voor 20% gewijzigd door ACM op 07-08-2003 10:59 ]

[Verwijderd]

Nog een tip als je vaak last hebt van partities die te groot of te klein zijn: EVMS
Daarmee kan je verschillende partities samenvoegen/resizen, software raid gebruiken etc.

Ik gebruik nu EVMS in combinatie met Reiserfs. Reiserfs kan resizen zonder dat je het filesystem hoeft te unmounten. Dat is erg handig. Als ik te weinig op mijn /home heb kan ik dus /usr kleiner maken en /home wat groter zonder naar een ander runlevel te gaan of opnieuw op te starten.

Het enige nadeel is dat je je kernel moet patchen.

[Verwijderd]

swap? bij 512MB RAM of hoger gebruik ik helemaal geen geen swap partitie meer. is niet nodig. zelfs niet als ik met gimp oid bezig ben.
En performanceverschillen, tussen aparte partitie en swapfile is enkele procenten in performance, dan zou ik eerder in de configuratie van je systeem aanpassingen brengen, dat levert vaak veel meer performancewinst op.

[Verwijderd]

Het vierde blokje in de SysGuard geeft iets van 'Swap Usage' , daar heb ik nog geen meting in gezien. Het geheugen gebruik stijgt flink maar is nog niet tot aan het maximum geweest.

Klopt het dan dat het swap file nog niet gebruikt is?

Maar ja, wat wil je ook met zo'n traag systeem.

[Verwijderd]

Geef het commando
free
om te zien of je swap gebruikt wordt.

Maar 1 minuut om konqueror te openen als kde al draait lijkt me wel heel erg langzaam; op mijn 2GHz bak duurt het 1 sec en die is (helaas) echt niet 60x zo snel als een 400MHz machine.

Het lijkt me dat er meer verrot is aan je systeem/installatie, en dit ligt ook niet aan je hd/partities lijkt me...

[LightYears]

KDE kan je flink versnellen door portmap en fam aan te zetten (zijn 2 deamons). fam houdt bij wat er op je schijf veranderd en verteld dit aan de verschillende kio subsystemen, die "horen" dat en springen direct door naar de goeie plek

althans zoiets was het, het werkt iig wel goed

[Verwijderd]

Het heeft even geduurd maar ik ben er uiteindelijk achter gekomen.

Onder zowel RedHat 7.3 als 9.0 werkte de hostname niet goed.

In Networks stond wel hostname=localhost.localdomain maar als je op vroeg wat de hostname was kwam 'ie met "."

Nu de regel in 2-en gesplitst
hostname=localhost
domainname-localdomain
en dit werkt prima, de machine is weer 'flitsend' (voor een 400Mhz dan)

[XTerm]

* XTerm gokt dat deze brave jongen geen UDMA heeft aanstaan

code:

hdparm -tT
hdparm -c1d1X69 /dev/hda
hdparm -tT

Kijk es hoeveel dat scheelt ?