FreeBSD ... Praxisoptimierungen...

Georg47

New Member
hallo @all...

Nach diversen FreeBSD - Installationen (und sachkundigem Support des Forenchats - ja, ich hab euch mal gelobt *tapfer guck) möchte ich FreeBSD als Desktopsystem einrichten und nutzen. Die FreeBSD 5.3 (im Moment beta5) gefällt mir so gut, dass ich mein System daraufhin "optimieren" möchte...

Zugegeben, es ist ein exotisches System, aber ich spiele halt gern herum und versuch es zu nutzen... Anwendungen sind bevorzugt Grafik a la GIMP, KDE oder Xfce, vielleicht später mal die Pflege einer kleinen privaten Homepage... im Vordergund steht jedoch das "Arbeiten" rund um das System... schnelles Upgrade bei neuen Versionen, rumspielen mit current (vielleicht im jail), schnelles compilieren von world/kernel/ports....

Es soll keine Rücksicht auf Ausfallsicherheiten genommen werden (die Daten werden auf einen anderen Rechner gesichert oder auf DVD), das OS kann relativ problemlos nach Plattentausch wieder aufgesetzt werden... einzelnes dump von verzeichnissen nicht ausgeschlossen...

Als Festplatten stehen sowohl IDE als auch SCSI-2 Platten zur Verfügung, laut diskinfo alle ungefähr gleich schnell im seek und transfer-modus...

Mich würde interessieren, ob z.B eine kleine SCSI-Platte (4,3 GB) besser als swap oder / eingesetzt wird (man könnte ja die notwendigen verzeichnisse mounten), ob eine raid0 installation grundsätzlich schneller im Plattenverhalten ist, als eine Aufteilung auf verschiedene Platten usw...

z.Z. wird das System wie folgt genutzt

ad0 (10 GB) = / (war zu faul, mit scsi, bootmanager usw rumzupielen)
ad2 (10 GB) = /backup (für dump usw)
ad4+ad6 an ide-raid-controller = ar0 /daten
da0 (4,3 GB) /swap
da1 (9 GB) /tmp
da2 (9 GB) /usr
da3 (9 GB) /usr/ports

Idee war, dass die Arbeiten in /var damit automatisch auf der relativ ungenutzen ad0 ebenfalls ungestört laufen, falls portinstall/world usw. gemacht wird (aber das kann ja schon eine falsche Überlegung sein)...

Verbesserungsvorschläge werden gern entgegen genommen...

Zusätzlich interessiert mich, ob z.B. FreeBSD mit einem 64-Bit Prozessor schon für Desktop eingesetzt werden kann und/oder Dual-Proz-Betrieb für signifikante Leistungssteigerungen im Normalbetrieb sorgt oder nur für Entwickler interessant ist...

Und nun "schlagt" mich nicht tot... habt Rücksicht auf mein Alter *lach
 
Ich will dir ja nicht auf die Fuesse pinkeln, aber 10GB Platten sind alt und langsam. Kauf dir eine 120GB ATA-Platte (kost ja nix) und verwende die. Damit hast du mehr Speedup als du durch sonstige Frickeleien hinbekommen wuerdest (mal ganz zu schweigen von der gesparten Zeit und Nerven).

Achja, wenn du schnelle buildworlds haben willst, dann mounte doch mal eine Memorydisk nach /usr/obj <veg>

PS: Wenn du bei heutigen RAM-Preisen wirklich den _Swap_ optimieren willst, dann kann dir echt keiner mehr helfen :)
 
Nicht jeder kauft gleich einen neuen Rechner.. es ist halt das System, welches mir zur Verfügung steht... RAM hat das Teil soviel, wie das Board maximal verträgt (also 1.5 GB), swappen tut es so gut wie nie (bisher wenigstens)... also kann die Idee mit der RAM-disk ja durchaus mal in Angriff genommen werden... obwohl ich ehrlich gesagt noch nicht weiss, was das bringen könnte.

Aber genau darum geht es mir ja, zu lernen, wie man ein vorhandenes System besser nutzen kann.. die anderen Festplatten sind mir zu klein für meine Daten (benutze ca. 80 GB für meine Arbeit), deswegen habe ich nicht das OS auf das IDE-Raid installiert...

Wenn allerdings es insgesamt besser ist, die drei SCSI-Platten als Raid zu nutzen, um insgesamt mehr Performance zu haben, als mit der Aufteilung in verschiedene Partitionen, kann ich das ja mal ausprobieren... dann wäre ja nur noch zu klären, wie das mit dem Bootmanager am besten klappt (mir ist nicht bekannt, ob ein eigenes /boot - slice auf ad0, ähnlich wie bei gentoo - dann den restlichen Teil auf / - angenommen auf dem scsci-raid - ansprechen könnte... Tips werden gern entgegen genommen...

Im übrigen bemühe ich mich, jeden Vorschlag ernst zu nehmen... auch, wenn es manchmal eher rauh als herzlich klingt *lach...

Der "Aufwand" ist eher im Verstehen, wie das System ineinander greift... bessere, schnellere Hardware kann Verstehen nicht immer ersetzen... höchstens die Lücken schneller vergrössern (mal philosophischen "Touch" reinbring *schmunzel)

In diesem Sinne.. immer mal her mit weiteren Vorschlägen...
 
Ich hab ein Dual-System mit 2 Pentium III Coppermine, beim Kernel- und Weltbau merkt man das schon deutlich (war mal einer kaputt, durfte nur auf einem Topf laufen, da merkt man das schon), dann arbeite ich recht intensiv mit Grafik und LaTeX, das rennt auch brav und schnell. Seit SCHED_4BSD wieder im Kernel ist, habe ich auch nicht mehr das Einfrieren der Oberfläche, das wirklich seit etwa 5.2.1 häufig auftrat, keine Ahnung, ob das mit Dualsystemen und dem Scheduler zu tun hat.
 
MrFixit schrieb:
Ich will dir ja nicht auf die Fuesse pinkeln, aber 10GB Platten sind alt und langsam. Kauf dir eine 120GB ATA-Platte (kost ja nix) und verwende die. Damit hast du mehr Speedup als du durch sonstige Frickeleien hinbekommen wuerdest (mal ganz zu schweigen von der gesparten Zeit und Nerven).

Achja, wenn du schnelle buildworlds haben willst, dann mounte doch mal eine Memorydisk nach /usr/obj <veg>

PS: Wenn du bei heutigen RAM-Preisen wirklich den _Swap_ optimieren willst, dann kann dir echt keiner mehr helfen :)

Da habe ich gleichmal eine Frage dazu. Ich habe ein buildworld auch einmal mit Memorydisk gemacht, das ging wirklich affenschnell. Aber wenn der Kernel gebaut ist, soll ja das Teil neu gebootet werden. Spätestens dann ist die Memorydisk aber im A...

Vielleicht bin ich ein bisschen blöd, aber mir hat sich der Sinn einer Memorydisk beim 'make buildworld' nicht ganz erschlossen. Kann mich da jemand aufklären?

Danke c.
 
Zuletzt bearbeitet:
MrFixit schrieb:
Wenn der Kernel gebaut ist, dann soll er zumindest installiert werden, bevor du rebootest. Wo ist das Problem?

Normal läuft ja das update des Systems so ab:

1. make buildworld
2. make buildkernel
3. make installkernel
4. shutdown -r now
5. mergemaster -p
6. make installworld
7. mergemaster
8. shutdown -r now

Wenn ich jetzt die memory disk unter /usr/obj mounte, dann gehen die Schritte 1-3 auch schön schnell, nur nach dem Booten mit dem neuen Kernel ist die memory disk eben nicht mehr da.

Nach dem Handbuch benötigt man aber /usr/src und /usr/obj für make installworld.

Gruß c.
 
crotchmaster schrieb:
Normal läuft ja das update des Systems so ab:
1. make buildworld
2. make buildkernel
3. make installkernel
4. shutdown -r now
5. mergemaster -p
6. make installworld
7. mergemaster
8. shutdown -r now

Warum machst Du einen reboot bei (4)? Lass das einfach weg, ausser es ist anders unter /usr/src/UPDATING beschrieben. Ich habe bisher nie diesen reboot gemacht, ausser als ich eine Kiste von 4.x auf 5.x hochgezogen hatte, oder es stand explizit unter UPDATING.
 
Der Reboot ist dann wichtig, wenn sich Kernelschnittstellen geändert haben. Ein Beispiel dafür ist die Änderung von November 2003:
Code:
20031112:
        The statfs structure has been updated with 64-bit fields to
        allow accurate reporting of multi-terabyte filesystem
        sizes. You should build world, then build and boot the new kernel
        ...
        ****************************DANGER*******************************

        DO NOT make installworld after the buildworld w/o building and
        installing a new kernel FIRST.  You will be unable to build a
        new kernel otherwise on a system with new binaries and an old
        kernel.
Für mich ist es beim Upgraden wichtiger, dass System nicht zu zerschiessen, als ein paar Sekunden für einen Reboot zu sparen. Ich rate also davon ab, auf den Reboot zu verzichten!
 
Zurück
Oben