Inbetriebnahme eines PCs. Partitionsgrößen für Debian

[qlfreak]

Hallo,

ich kenne Debian (allerdings von SARGE-Zeiten), daher wollte ich fragen, welche Partitionsgrößen man für Debian verwenden sollte.

In den PC sind (zunächst) 1 SSD mit 256 GByte (232 GByte nutzbar) und 1 Harddisk ebenfalls mit 256 GByte eingebaut.

Installiert werden soll zunächst Windows (vermutlich 10 evtl. 8.1). Einen Bootmanager habe ich bereits gefunden (http://www.boot-us.de), da man diesen in eine eigene primäre Partition installieren kann und somit weder im MBR, noch auf einer Partition auf der ein anderes BS installiert ist, etwas verändert werden muss. Der GRUB kommt dann in die Partition (das logische Laufwerk in der erweiterten Partition auf der SSD) in das auch Debian selbst installiert wird. GRUB wird dann von boot-us gestartet. So habe ich das früher mit dem OS/2-Bootmanager auch gehandhabt und es war perfekt, leider lässt sich OS/2 auf moderner Hardware nicht mehr installieren und somit auch der OS/2-Bootmanager nicht in Betrieb nehmen.

Windows ist das Hauptsystem. Debian soll vor allem verwendet werden, um in C++, C#, Java, Python, ... zu programmieren, und einige andere Sachen, für die UNIX einfach besser geeignet ist, als Windows.

Debian soll auf jedem Fall von der SSD gestartet werden und wichtige Programme (wie GCC und CLANG, Java-SDK, ...) sollen ebenfalls auf die SSD. Meine Daten (z. B. Projekte) sollen dagegen auf der Harddisk gespeichert werden.

Ich hatte so an 30 bis 50 GByte auf der SSD angedacht (dann bleiben mindestens 180 GByte für Windows plus den Anwendungen, was ausreichend sein sollte. Auf der Harddisk dachte ich an um die 60 GByte.

Sind diese Werte realistisch (insbesondere auf der SSD) oder eher knapp?

EDIT: Wie groß sollte die SWAP-Partition für DEBIAN (natürlich auf der SSD) sein?

[cronoik]

Willkommen im Forum,

wir hatten hier [1] schon eine ähnliche Diskussion. Wenn du geizen musst, nimm die 50 auf der SSD. Ob die 60GB ausreichen hängt von deinen Projekten ab. Diesen Projektbereich würde ich dann im /home deines Benutzer mounten. Dann sind dort nur deine Projekte vorhanden und nichts Debianspezifisches.

EDIT: Wie groß sollte die SWAP-Partition für DEBIAN (natürlich auf der SSD) sein?

Wie groß ist denn dein Arbeitsspeicher? Früher war die Regel "so groß wie der RAM" und die gilt auch heute noch wenn du Suspend2Disk nutzen möchtest. Dem "normalen" Nutzer sollten 2 GB reichen. Es hängt halt bei dir von deinem Nutzerverhalten ab.

[1] http://debianforum.de/forum/viewtopic.php?f=27&t=156679

[Lord_Carlos]

2gb swap ist sicherlich ok. Wie die anderen sagen, es kommt immer etwas drauf an wie viel Ram man hat und wie man den Rechner benutzt. Ich kann mich nicht erinnern in den letzten Jahren jemals den Swap gross ausgelastet zu haben. Manchmal ist da ~100mb drinne, weis aber nicht womit, da noch ram frei ist.

Ja, 30 bis 50gb sollten reichen, wuerde eher zu 50 tendieren. Gerade wenn man dicke IDEs wie IDEA, eclipse etc. benutzt und dazu noch mehrere JDKs hat, z.B. 7 und 8.
Solange deine Projekte nicht gerade sehr viel Platz wegnehmen (z.B. wegen Binareen daten ala Bilder/Videos) wuerde ich die auch auf die SSD packen. Da macht das compilieren mehr spass Viele kleine Daten ist das wo die SSD ihren vorteil auspackt.

Das mit den bootloader verstehe ich nicht (Ich habe seit Jahren nur grub im Einsatz) aber solange du den durchblick hast ist das ja egal.

[hikaru]

So lange du kein Suspend2Disk verwenden willst oder exorbitante Speicheranforderungen hast kannst du auch ganz ohne Swap leben.
Bei deinem Szenario frage ich mich allerdings ob es nicht sinnvoller wäre Debian zu virtualisieren. Die Hauptfrage dürfte hier sein welche Rolle für dich der Datendurchsatz auf die HDD/SSD spielt. So lange die beim Compilieren anfallenden Daten im Vergleich zum RAM überschaubar bleiben könnten man hierfür auch eine RAMdisk verwenden.

[eggy]

Hikaru, beim Compilieren würde ich lieber auf Virtualisierung verzichten wollen. Die Performance -grade bei Optimierungen- dürfte merklich in den Keller gehen.

Das jeweils aktuelle Projekt in die Ramdisk zu stecken hingegen ist nen sehr guter Vorschlag.
Dann achte aber drauf, z.B. ne Versionsverwaltung einzusetzen und regelmässig nen commit/push auf die HD abzusetzen. Nichts ist nerviger als nach nem langen Arbeitstag die Kiste runterzufahren und vorher vergessen zu haben die Ramdisk zu "backuppen" ... ich sprech aus (mehrfacher) Erfahrung
Und auch Murphy liebt dieses Szenario: Stromausfall, hängender Rechner, etc kommt alles immer in den ungünstigsten Momenten vor.

[hikaru]

Hikaru, beim Compilieren würde ich lieber auf Virtualisierung verzichten wollen. Die Performance -grade bei Optimierungen- dürfte merklich in den Keller gehen.

Die CPU wird bei Virtualbox, VMWare und Qemu (x86-Gast auf x86-Host) einfach nur durchgereicht. Da entstehen keine Verluste wie z.B. bei einer Emulation.

[qlfreak]

Vielen Dank für die Antworten (insbesondere an cronoik für den Link). Ich denke ich werde dann 50 evtl. 60 GByte auf der SSD frei halten.

@Lord_Carlos: Warum ich nicht Grub nehme liegt daran, dass man diesen im MBR installieren muss, damit er als erstes aufgerufen wird. Am MBR möchte ich aber nichts ändern. Die andere Möglichkeit wäre (falls das geht), ihn in das Startmenü von Windows einzubinden. Aber auf Windows möchte ich mich nicht verlassen. Die Möglichkeit GRUB in eine eigene primäre, versteckte Partition zu installieren, die vom MBR gestartet wird, und die dann wie der MBR einfach den Startcode in anderen Partitionen aufruft, bestand zumindest zu Sarge-Zeiten nicht. Dort wurde extra davor gewarnt, den GRUB in eine Partition (logisches Laufwerk in erweiterter Partition) zu speichern, da man dann immer einen zweiten Boot-Manager benötigt, der GRUB aufruft. Genau das mache ich jetzt (und habe das früher mit dem OS/2-Bootmanager gemacht). Vorteil: Sollte irgend ein BS (Windows macht das) den Bootmanager bei der Installation lahmlegen, kann man ihn mit dem Partitionierungsprogramm eines beliebigen Betriebssystems einfach wieder herstellen, indem man dessen Partition als die Aktive setzt. Da der MBR nicht verändert werden muss, kann der im Fehlerfall mit z. B. FDISK /fmbr von DOS auch wieder einfach restauriert werden. Bei GRUB im MBR hätte ich da ein größeres Problem.