HI! Mir ist klar, dass es dazu verschiedene Meinungen gibt, dennoch wären mir Vorschläge recht. Wie partitioniere ich sinnvoll eine 100 GB Platte für den privaten Gebrauch (2 User)? /home auf eine eigene Partition zu legen macht wohl Sinn. Aber was noch? Unter Windows hatte ich immer 3 Partitionen: System, Anwendungsprogramme, Sonstiges (Videodateien, Archive, etc.). Kann man bei Linux überhaupt trennen zwischen System und Anwendungsprogrammen? Danke! Thomas
* Thomas Börkel:
Wie partitioniere ich sinnvoll eine 100 GB Platte für den privaten Gebrauch (2 User)?
/home auf eine eigene Partition zu legen macht wohl Sinn. Aber was noch?
/var (damit / nicht überläuft, wenn Logdateien explodieren) /usr (kann man z.B. ro mounten) ...
Kann man bei Linux überhaupt trennen zwischen System und Anwendungsprogrammen?
Aber klar. /bin + /sbin vs. /usr/bin + /usr/sbin (+ /opt + ...). Alles was für das Booten und den Grundgebrauch des Systems essenziell notwendig ist, ist in /bin und /sbin. Genau aus dem Grund, dass die normalerweise auf der /-Partition liegen. Thorsten -- You talkin' to me? Get my public GPG key: 0xF99C905C
Thorsten Jens wrote:
/var (damit / nicht überläuft, wenn Logdateien explodieren)
Das nutzt Dir genau gar nix. Wenn /var vollläuft, steht das System trotzdem, und Du kannst Dich unter Umständen nicht mehr einloggen. Da ist es egal, ob das eine Extra-Partition ist.
/usr (kann man z.B. ro mounten)
Und dann jede Menge Probleme z.B. mit dem YOU bekommen. Meiner Meinung nach ist es wichtiger, schnell und automatisch aktuelle Sicherheitspatches zu bekommen als ein ro-/usr zu haben.
Aber klar. /bin + /sbin vs. /usr/bin + /usr/sbin (+ /opt + ...). Alles was für das Booten und den Grundgebrauch des Systems essenziell notwendig ist, ist in /bin und /sbin. Genau aus dem Grund, dass die normalerweise auf der /-Partition liegen.
/bin vs. /usr/bin und /lib vs. /usr/lib ist ein PDP-11-ismus und seit mehr als 20 Jahren obsolet. Eine PDP hatte nur begrenzt viel Speicher, und wenn beim Booten ein fsck auf / gemacht werden mußte, dann mußte / in den Speicher passen, weil zu diesem Zeitpunkt noch kein swap vorhanden war. Erst nach dem Checken von / konnten der Swap enabled, dann /usr gecheckt und dann /usr gemountet werden. Daher die artifizielle Trennung von / und /usr. Einen praktischen Grund gibt es dafür nicht mehr (und in Solaris sind /bin und /lib deswegen konsequent Symlinks auf /usr/bin und /usr/lib). Kristian
Hallo, Am Fr, 2003-11-28 um 09.21 schrieb Thorsten Jens:
* Thomas Börkel:
Wie partitioniere ich sinnvoll eine 100 GB Platte für den privaten Gebrauch (2 User)?
Nur ein Beispiel: Ich habe eine 120er Platte in 5,5 GB Partitionen aufgeteilt, damit ich verschiedene Distris mal probieren kann (übrigens neben Win98SE und W2k). So kann ich installieren, ohne mich um die konkrete Partitionierung dieser Distri zu kümmern - alles unter /. Die Partitionierung für eine Distri könnte so aussehen: 0,05 % für /boot, 0,97 % (entsprechend RAM) für swap, 5,5 % für /, 32 % für /usr, 11 % für /var, 27 % für /opt und der Rest für /home. Wie gesagt, ist nur ein Beispiel, mit dem ich aber gut gefahren bin. Grüße H.-Peter
Hallo, Am Samstag, 29. November 2003 00:14 schrieb H.-Peter Baldamus: /.
Die Partitionierung für eine Distri könnte so aussehen: 0,05 % für /boot, 0,97 % (entsprechend RAM) für swap, 5,5 % für /, 32 % für /usr, 11 % für /var, 27 % für /opt und der Rest für /home.
Wenigstens die swap-Partition könnten alle Distris gemeinsam nutzen. Grüsse, Rüdiger
Hi, im Falle eines nicht ganz vorsintflutlichen PCs (ab PII) würde ich heute kaum Zeit mehr darauf verwenden, wie ich meine Festplatte partitioniere. Einfach: swap 512 MB / 5 GB /home Rest _Ich_ würde es so machen: /boot 16 MB swap 1 GB / 5 GB /home ca. 5 GB /local 30 /multimedia 60 GB Warum? swap kann man vielleicht mal als STD oder hibernation-Partition gebrauchen, /home kann man in der Größe auch mal wegbrennen, um /local kümmert man sich extra, unter /multimedia liegen Filme, MP3s etc. Vielleicht gefällt Dir ja eine Mischform: wie oben plus Multimedia-Partition oder so. Mein Tipp: Vergiss komplexe Partitionierung, kostet nur Zeit, die Dir am Ende nix bringt. Oder mach es richtig und lager alles in extra Mount-Points aus, was ro gemountet werden kann usw. Und dann erzähl von Deinen Bastel-Erkenntnissen. Gruß, René
On Fri, 2003-11-28 at 11:13, René Matthäi wrote:
Hi,
Mein Tipp: Vergiss komplexe Partitionierung, kostet nur Zeit, die Dir am Ende nix bringt.
Wozu Sicherheitsgurt, dein Auto hat doch Airbags? Wozu Winterreifen, deine Sommerreifen sind doch noch OK und überhaupt bei uns schneit es doch sowieso nicht. Mit 5 Bier kann man doch noch autofahren, ist doch klar? ... Oder? Klar, auf einem Home-Desktop kann man vieles lässiger handhaben als es anderwo notwendig wäre, trotzdem iste es kein Fehler, sich auch zuhause über Dinge Gedanken zu machen, die anderswo als sinnvoll angesehen werden haben. Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen. Ralf
Hallo, Am Freitag, 28. November 2003 12:38 schrieb Kristian Koehntopp:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
Ich war mal sehr froh, als die ersten badblocks auf meiner 40er Platte nur ein kleine Partition betrafen. Die anderen Partitionen konnte ich noch problemlos sichern. Grüsse, Rüdiger,
Rüdiger Meier wrote:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
Ich war mal sehr froh, als die ersten badblocks auf meiner 40er Platte nur ein kleine Partition betrafen. Die anderen Partitionen konnte ich noch problemlos sichern.
Das wäre bei einer großen Partition nicht anders gewesen. Du hättest alle Verzeichnisse und die darin enthaltenen Dateien sichern können außer denen, die die defekten Blöcke enthalten würden. Ein e2fsck baut das gesamte Dateisystem neu, indem es die Inode-Tabellen durchliest, die Verzeichnisse identifiziert, die Verzeichnisse durchliest und das alles wieder zusammensteckt. Es braucht im Prinzip nicht mal einen Superblock dafür. Ein reiserfsck macht sogar noch mehr: Es liest die ganze Platte durch, identifiziert anhand von Magic-Bytes potentielle reiser-Datenstrukturen und baut Dir so einen kompletten reiser-Tree neu. In beiden Fällen würden durch defekte Blöcke in Dateien unleserliche Dateien entfallen und durch defekte Blöcke in Verzeichnissen abgetrennte Unterverzeichnisse in /lost+found auftauchen. Der Schaden und Datenverlust ist in dem von Dir genannten Szenario unabhängig von der Partitioniert vergleichsweise klein. Die verlorenen Verzeichnisse und Dateien kann man dann vom Backup nachziehen. Du hast doch eines, oder? Kristian
* Kristian Koehntopp:
Rüdiger Meier wrote:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
Ich war mal sehr froh, als die ersten badblocks auf meiner 40er Platte nur ein kleine Partition betrafen. Die anderen Partitionen konnte ich noch problemlos sichern. [...]
In beiden Fällen würden durch defekte Blöcke in Dateien unleserliche Dateien entfallen und durch defekte Blöcke in Verzeichnissen abgetrennte Unterverzeichnisse in /lost+found auftauchen. Der Schaden und Datenverlust ist in dem von Dir genannten Szenario unabhängig von der Partitioniert vergleichsweise klein.
Ich denke es geht auch um den Zeitaufwand. Thorsten -- You talkin' to me? Get my public GPG key: 0xF99C905C
Hallo, Am Freitag, 28. November 2003 13:34 schrieb Kristian Koehntopp:
Ich war mal sehr froh, als die ersten badblocks auf meiner 40er Platte nur ein kleine Partition betrafen. Die anderen Partitionen konnte ich noch problemlos sichern.
Das wäre bei einer großen Partition nicht anders gewesen. Du hättest alle Verzeichnisse und die darin enthaltenen Dateien sichern können außer denen, die die defekten Blöcke enthalten würden.
Das ist nur solange uneingeschränkt richtig, wie die defekten Blöcke nicht das Filsystem selbst schon in Mitleidenschaft gezogen haben. Bei reiserFS soll ja angeblich schon ein "richtiger" Block dafür ausreichen, damit reiserfsck nicht mehr wie gewünscht funktioniert. Hatte selbst alledings noch nie Probleme damit und verwende es ausschliesslich.
Ein e2fsck baut das gesamte Dateisystem neu, indem es die Inode-Tabellen durchliest, die Verzeichnisse identifiziert, die
Habe keine grosse Ahnung von FS-Interna, aber eine Inode-Tabelle ist sicher auch nicht unkaputtbar, Ich weiss nicht wie viele es davon gibt und wie die über die Partition verteilt sind. Bestimmt gibt es aber auch hier einen worst-case mit wenig kaputten Blöcken und vielen kaputten Dateien.
Ein reiserfsck macht sogar noch mehr: Es liest die ganze Platte
Gerade die vergangenen Versionen von reiserFS sollen aber bei Hardware-Defekten in grössere Schwierigkeiten geraten seien, als ext3. Man sollte übrigens ein xyzfsck nicht auf der kaputten Partition/Platte machen sondern auf einem Image. Das ist bedeutend einfacher, wenn das klein ist. Ich könnte mir jedenfalls nicht so schnell eine leere 100 GB Platte für Restaurierungsarbeiten ordern. Bei kleinen Paritionen gehts auch bedeutend schneller.
In beiden Fällen würden durch defekte Blöcke in Dateien unleserliche Dateien entfallen und durch defekte Blöcke in Verzeichnissen abgetrennte Unterverzeichnisse in /lost+found auftauchen. Der Schaden und Datenverlust ist in dem von Dir genannten Szenario unabhängig von der Partitioniert vergleichsweise klein.
Auch hier ist es einfacher, wenn man ein paar Daten weniger aus /lost+found wieder richtig einzusortieren hat.
Die verlorenen Verzeichnisse und Dateien kann man dann vom Backup nachziehen. Du hast doch eines, oder?
Der Hinweis aufs Backup durfte natürlich nicht fehlen ;) Ich mache das hier zu Hause nur mit Daten, die mir sehr wichtig erscheinen und die nicht sowieso schon auf irgendwelchen ftp-Servern oder Original-CDs liegen. Freue mich im Fall der Fälle allerdings trotzdem, wenn ich um eine komplette Neu-Installation herumkomme. Und auch hier ist wohl von Vorteil, wenn man nicht ein einziges riesiges Backup-Archiv mit einem eventuell kaputten Block vorliegen hat, oder kann man kaputte tar-Bälle auch so problemlos reparieren? (Das Backup-Konzept muss natürlich nicht unbedingt etwas mit den Partitionsgrössen zu tun haben.) Grüsse, Rüdiger
On Fri, 2003-11-28 at 12:38, Kristian Koehntopp wrote:
Ralf Corsepius wrote:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
* Nehmen wir an, die Wahrscheinlichkeit, dass ein Plattendefekt ein Platte trifft, sei über die ganze Platte gleichverteilt. Somit ist die Wahrscheinlichkeit, dass das FS von einem Fehler getroffen wird, ebenfalls N und die Wahrscheinlichkeit, das Daten verloren gehen proportional zu N. (Der Fehler wirkt sich auf das gesamte FS aus) Wird eine Platte in n Partitionen aufgeteilt, wirkt sich ein Fehler nur noch die betroffene, kleinere Partition aus. Somit ist die Wahrscheinlichkeit, dass Daten verloren gehen erheblich kleiner als N. * FS-Recovery ist bei kleinen FS wesentlich schneller als bei grossen FSen. * Während des Betriebs findet schreibender Zugriff typischerweise nur in wenigen Verzeichnissen statt (Normalerweise nur /tmp, /var und /home). Somit ist die Wahrscheinlichkeit, dass dort ein Fehler auftritt deutlich höher als in anderen Verzeichnissen. Legt man diese auf eigene Partitionen, reduziert sich die Wahrscheinlichkeit, dass ein FS-Fehler dort andere Verzeichnisse in Mitleidenschaft zieht, nicht unerheblich. Ralf
Hi, Am Freitag, 28. November 2003 13:51 schrieb Ralf Corsepius:
On Fri, 2003-11-28 at 12:38, Kristian Koehntopp wrote:
Ralf Corsepius wrote:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
* Nehmen wir an, die Wahrscheinlichkeit, dass ein Plattendefekt ein Platte trifft, sei über die ganze Platte gleichverteilt.
Somit ist die Wahrscheinlichkeit, dass das FS von einem Fehler getroffen wird, ebenfalls N und die Wahrscheinlichkeit, das Daten verloren gehen proportional zu N. (Der Fehler wirkt sich auf das gesamte FS aus)
Wird eine Platte in n Partitionen aufgeteilt, wirkt sich ein Fehler nur noch die betroffene, kleinere Partition aus. Somit ist die Wahrscheinlichkeit, dass Daten verloren gehen erheblich kleiner als N.
wenn, wie Du selbst schreibst Plattendefekte über die Platte gleichmäßig verteilt auftreten, ist die Wahrscheinlichkeit das damit Datenverluste verbunden sind, nur davon abhängig wieviele Daten auf der Platte vorhanden sind. Und daran lässt sich nicht vorbei-partitionieren.
[...]
* Während des Betriebs findet schreibender Zugriff typischerweise nur in wenigen Verzeichnissen statt (Normalerweise nur /tmp, /var und /home). Somit ist die Wahrscheinlichkeit, dass dort ein Fehler auftritt deutlich höher als in anderen Verzeichnissen.
Würde bedeuten das Hardwaredefekte sich nur bei schreibendem Zugriff auswirken,- halte ich ebenfalls für ein Gerücht.... Gruß Harald
On Fri, 2003-11-28 at 14:26, Harald Huthmann wrote:
Hi, Am Freitag, 28. November 2003 13:51 schrieb Ralf Corsepius:
On Fri, 2003-11-28 at 12:38, Kristian Koehntopp wrote:
Ralf Corsepius wrote:
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Nämlich warum?
* Nehmen wir an, die Wahrscheinlichkeit, dass ein Plattendefekt ein Platte trifft, sei über die ganze Platte gleichverteilt.
Somit ist die Wahrscheinlichkeit, dass das FS von einem Fehler getroffen wird, ebenfalls N und die Wahrscheinlichkeit, das Daten verloren gehen proportional zu N. (Der Fehler wirkt sich auf das gesamte FS aus)
Wird eine Platte in n Partitionen aufgeteilt, wirkt sich ein Fehler nur noch die betroffene, kleinere Partition aus. Somit ist die Wahrscheinlichkeit, dass Daten verloren gehen erheblich kleiner als N.
wenn, wie Du selbst schreibst Plattendefekte über die Platte gleichmäßig verteilt auftreten, ist die Wahrscheinlichkeit das damit Datenverluste verbunden sind, nur davon abhängig wieviele Daten auf der Platte vorhanden sind. Richtig.
Und daran lässt sich nicht vorbei-partitionieren. Aber die Auswirkungen lassen sich einschränken.
Angenommen, es würde über die gesamte Platte gesehen alle 1000h eine FS-Fehler auftreten, würdest Du bei jedem Fehler den gesamten Datenbestand auf der ganzen Platte gefährden. Verwendet man mehrere Partitionen, würde bei jedem Fehler nur der Datenbestand auf der jeweils getroffenen Partition gefährdet werden. Die Summe der Fehler wäre die gleiche, nur die Wahrscheinlichkeit der Gefahr von Datenverlusten wäre geringer.
[...]
* Während des Betriebs findet schreibender Zugriff typischerweise nur in wenigen Verzeichnissen statt (Normalerweise nur /tmp, /var und /home). Somit ist die Wahrscheinlichkeit, dass dort ein Fehler auftritt deutlich höher als in anderen Verzeichnissen.
Würde bedeuten das Hardwaredefekte sich nur bei schreibendem Zugriff auswirken,- halte ich ebenfalls für ein Gerücht.... ACK.
Ich sprach ja auch von Wahrscheinlichkeiten und nicht von Ausschliesslichkeit und nicht nur von HW-Defekten. Und da ist es nun mal so, dass die Wahrscheinlichkeit, dass ein Schreibzugriff das FS zerstört oder Daten verloren gehen, erheblich höher ist, als die Wahrscheinlichkeit, dass ein FS bei einem lesenden Zugriff zerstört wird, da schreibende Zugriffe in der Regel das FS modifizieren, lesende Zugriffe hingegen nicht. Gerade beim Klassiker Stromausfall kann man hinterher sehr schön beobachten, welche FS restauriert werden müssen, welche nicht und wo Fehler auftreten. Im Normalfall sind es genau /tmp, /var und /home. Ralf
Am Freitag, 28. November 2003 15:16 schrieb Ralf Corsepius:
Gerade beim Klassiker Stromausfall kann man hinterher sehr schön beobachten, welche FS restauriert werden müssen, welche nicht und wo Fehler auftreten.
Im Normalfall sind es genau /tmp, /var und /home.
Genau dieser Fall ist mir vor ein paar Tagen passiert. Die Auslagerung von /var hat mir reichlich Zeit bei der Wiederherstellung gespart. Einfach /var neu partitionieren und das letzte Backup-Image wieder drauf. Das geht schneller als reparieren und Daten wiederherstellen. Und es ist bedeutend schneller gefixt, als wenn man eine große Partition hat. Nach einem Viertelstündchen lief es wieder. Bei einer großen Partition kann es auch mal ein paar Stunden dauern bis alles gefixt ist. Ein weiterer Grund fürs Partitionieren: Wenn man mehrere OS-Versionen auf einem Rechner haben möchte, spart man Platz, da einige Partitionen, z.B. /boot und /home von mehreren OS-Versionen benutzt werden können. (Und jetzt kommt mir blos keiner mit der Bemerkung, einfach noch eine weitere oder größere Platte einzubauen.) Grüße René
Hi, hältst Du Dich für so klug und/oder mich für doof, dass Du gleich in vor Zynismus triefende Ironie ausbrechen brauchst... Ralf Corsepius schrieb:
On Fri, 2003-11-28 at 11:13, René Matthäi wrote:
Mein Tipp: Vergiss komplexe Partitionierung, kostet nur Zeit, die Dir am Ende nix bringt.
[...]
Klar, auf einem Home-Desktop kann man vieles lässiger handhaben als es anderwo notwendig wäre, trotzdem iste es kein Fehler, sich auch zuhause über Dinge Gedanken zu machen, die anderswo als sinnvoll angesehen werden haben.
Spätestens wenn das FS einer 60GB-Platte einen Crash erfährt oder ... oder ... oder ..., wirst auch Du erleben, warum Partitionierungen auch heute noch Sinn machen.
Das habe ich nicht gemeint. Selbst für ein Produktiv-System unterschriebe ich die gleiche Aussage. Ich würde in diesem Fall allerdings RAID und Backups verwenden. Mach ich zu Hause übrigens auch (in begrenztem Umfang). René
Thomas Börkel wrote:
Wie partitioniere ich sinnvoll eine 100 GB Platte für den privaten Gebrauch (2 User)?
swap wie gewünscht, / (6-10 GB), falls notwendig /boot (~50 MB), den Rest nach /home. Oder Du verwendest lvm, und machst Deine Partitionen im Laufe der Zeit größer wie benötigt. Dies ist eine fortgeschrittene Konfiguration und nichts für Anfänger. Kristian
HI! Ich hatte vor einiger Zeit hier gefragt und viele interessante Antworten bekommen. Hier nun das Ergebnis meiner Installation: Ich wollte eigentlich / und /boot auf getrennten reiserfs Partitionen haben und alle "großen" Mountpoints unter LVM. Dabei hat Suse 9.0 aber einen Fehler bei der Konfiguration von Grub gemacht, wodurch am Ende die Installation bei der Aktivierung des Bootmanagers stehen blieb mit "File not found". Da ich mich mit Grub nicht auskenne, habe ich ins Blaue hinein die Config geändert (anscheinend hat er die Menu.lst nicht gefunden). Daraufhin wurde die Installation fortgesetzt und der Rechner wollte neu booten. Dabei blieb er aber in einem Grub-Prompt stehen. offensichtlich hatte ich also nicht korrekt geändert. ;-) Ich habe dann aufgegeben und neu installiert mit / und /boot auf der selben Partition. So sieht es nun aus auf meiner 120 GB Platte: / = 1 GB (reiserfs) swap = 1 GB LVM = 110 GB /usr = 3 GB (LVM) /opt = 3 GB (LVM) /var = 500 MB (LVM) /srv = 50 MB (LVM) /home = 1 GB (LVM) /local = 500 MB (LVM) /buffer = 4.3 GB (LVM) /work = 70 GB (LVM) 27 GB in LVM frei für Snapshots oder als Reserve. Für was man /local braucht war mir nicht ganz klar. Achja: Und die LVM-Gruppe darf nicht "lvm" heißen. ;-) Thomas
participants (9)
-
H.-Peter Baldamus -
Harald_mail＠t-online.de -
Kristian Koehntopp -
Ralf Corsepius -
René Falk -
René Matthäi -
Rüdiger Meier -
Thomas Börkel -
Thorsten Jens