Wie viel Speicher beansprucht eure Root-Partition unter Linux?

Bei mir beansprucht / etwa...

  • <15GB

    Stimmen: 6 12,0%
  • 15 bis 30GB

    Stimmen: 12 24,0%
  • 30 bis 50GB

    Stimmen: 15 30,0%
  • 50 bis 75GB

    Stimmen: 4 8,0%
  • 75 bis 100GB

    Stimmen: 2 4,0%
  • 100 bis 150GB

    Stimmen: 3 6,0%
  • >150GB

    Stimmen: 8 16,0%

  • Umfrageteilnehmer
    50
Krakadil schrieb:
Das hört sich jetzt so an als wäre das aus Not eine Lösung gewesen, welche aber nicht zu empfehlen ist :D
Ja, es war 2014, ich hatte noch nicht viel Geld übrig und da reichte es nur für eine 128er-SSD, und davon auch noch eine sehr günstige Serie: eine Sandisk (keine "Extreme" oder "Pro", sondern es steht einfach nur groß "Solid State Drive" drauf). Aber dank MLC ist sie auch heute noch schnell. Eine Festplatte hatte ich schon aus einem externen Gehäuse herausgeschneidert.
 
  • Gefällt mir
Reaktionen: Krakadil
Keylan schrieb:
Was aber ganz unproblematisch ist, ist einfach weitere Partitionen unter /home einzubinden um dort mehr Platz zu haben.
Ja, diese Methode bewährt sich bestens. Daher verwende ich sie für sonstige, einzubindende Partitionen fast ausschließlich.
 
In der Umfrage fehlt der Punkt: "Dynamisches Subvolume"
Man sieht ja, dass einige Nutzer hier die Möglichkeiten von BTRFS nutzen, mich eingeschlossen.

Krakadil schrieb:
Nie benutzt und würde ich auch nicht.

Ein Fehler, definitiv.
 
  • Gefällt mir
Reaktionen: s1ave77
Moderne FS wie btrfs, bcachefs [noch zu unstable IMHO, aber ein starker Konkurrent zu btrfs] oder vielleicht auch OpenZFS (ZFS ist ja bei manchen schon lange beliebt für seine Features, aber ich halte davon Abstand wegen dem Lizenzierungsgedöns und Kompatibilitätsunsicherheiten. btrfs und bcachefs sind legal komplett frei benutzbar und immer im Kernel mit dabei) sind doch der absolute Hammer.

Snapshots (wisst ihr wie praktisch das ist, z.B. nach einem fehlgeschlagenen Update einfach ein Rollback machen zu können? Oder bevor man eine potenziell riskante Aktion versucht), Deduplizierung (warum mehr Daten speichern als nötig), Transparente Kompression mit zstd (rasend schnell, trotzdem stärkere Kompression als ZIP bspw. -- again: warum mehr Daten speichern als nötig... eure effektive Parititonsgröße steigt dadurch), Copy on Write (nötig für Snapshots und um Bit Rot zu vermeiden, mglw. reduzieren sich dadurch auch Schreibvorgänge, was der Lebensdauer der Disks zu gute kommt), RAID-Funktionalitäten (weil das Dateisystem nicht nur mehrere Partitionen sondern auch Disks verwalten kann), dazu auch vom Design her sehr ausfallsicher.

Der Hauptnachteil gegenüber ext4, xfs, f2fs und Co. ist, dass sie langsamer sind. Deutlich langsamer sogar, aber ich würde sagen man merkt das nicht wirklich als User, außer man kopiert ständig große Datenmengen und timed die Vorgänge auch noch, dann fällt es sicherlich auf. Aber man kann ja seine Videos/Musik ja auch auf ner XFS-Partition speichern, wenn man unbedingt den Speed braucht, und nutzt btrfs nur fürs System und den ganzen Rest.
Aber der Nachteil von ext4, xfs, f2fs und Co. ist halt ... die können (im Vergleich) nix, außer dass sie schnell und simpel sind. OK, im Vergleich zu bcachefs auch noch ausgereift. btrfs ist ja inzwischen schon ausgereift genug, hat glaube ich nur noch Probleme mit RAID 6, aber das nutzen eh nur wenige.
 
Krakadil schrieb:
Ich habe da 32GB für Hibernate. Praktisch wenn er nicht fertig ist mit rechnen und der Akku schwächelt.
 
  • Gefällt mir
Reaktionen: Espero
Fedora legt soweit ich weiß selbst eine an.
 
Zu SWAP:

Schön ist, wenn der Installer einem die Wahl lässt, ob SWAP angelegt wird.
Letztens war ich angenehm überrascht, als ein Installer anbot, SWAP ja oder nein, und falls ja, dann ob mit oder ohne Hibernate. Sowas finde ich vorbildlich.
 
  • Gefällt mir
Reaktionen: konkretor
Hab mal ne Frage, hier wird immer wieder vom BTRFS gesprochen und das es kein Limit habe.
Kann mir das jemand erklären, welche Vorzüge das FS mit sich bringt? Ich hatte es noch nie im Einsatz.
 
Von der Raid funktion würde ich aber abstand nehmen, bis irgendwer feststellt/Testet, das das mittlerweile Fertig entwickelt/sicher ist.

Ein Vorteil kann sein, wenn es für dich von interesse ist eben für die Gesamte Festplatte eine BTRFS Partition anzulegen und dann darin Subvolumes zu erzeugen, die wenn nicht anders vorgegeben jedes für sich "zugriff" auf die gesamtgröße hat. man kann es sich quasi wie ordner auf einer Festplatte vorstellen, jedoch wird es als eigenständige Partitionen "anerkannt" wenn man so will. man kann eben diese subvolumes mounten. Wenn gewünscht aber ebean auch größenbegrenzungen angeben.

Die Schnappschüsse sind sehr interessant um in "Fingerschnippgeschwindigkeit"/"over 9000 !11!" einen Zustand sicherzustellen, sagen wir mal zum Beispiel bei bzw. vor einem Systemupdate, den gerade noch funktionierenden Zustand als Snapshot festlegen und sogar automatisch im Grub Bootmenü eintragen zu lassen als Bootoption.

Ein Snapshot zu erstellen ist (finde ich) aber nicht zu verwechseln mit einer Sicherung.

https://de.wikipedia.org/wiki/Btrfs

Btrfs soll vor allem auch Funktionen bieten, die es vom derzeitigen Linux-Standard ext3/ext4, aber auch von anderen Dateisystemen wie XFS oder JFS abheben, hierunter fallen:



Ich frage mich, ob damit dein
zelect0r schrieb:
das es kein Limit habe.
schon abgedeckt ist. Es ging um den verwendbaren Speicherplatz einer Festplatte dabei?
 
zelect0r schrieb:
Kann mir das jemand erklären, welche Vorzüge das FS mit sich bringt?

Datensicherheit. Es ist ein Copy-on-Write-Dateisystem. Sprich, es erstellt vor jedweder Änderung an Dateien erstmal eine Kopie, auch beim Löschen. Dazu arbeitet es mit Subvolumes. Das sind quasi dynamische Partitionen, die nach belieben in das Dateisystem eingehängt werden können. Von diesen kann das Dateisystem Abbilder erstellen (Snapshots), die man binnen Sekunden wiederherstellen oder mounten kann. Ich teile so mein System auf in:

ID 256 gen 187034 top level 5 path @
ID 257 gen 187035 top level 5 path @Home
ID 258 gen 186949 top level 5 path @flatpak
ID 259 gen 186707 top level 5 path @spiele
ID 260 gen 114189 top level 5 path @srv
ID 261 gen 114189 top level 5 path @abs
ID 262 gen 187035 top level 5 path @log
ID 263 gen 186952 top level 5 path @tmp
ID 264 gen 185742 top level 5 path @pkg
ID 265 gen 114189 top level 5 path @containers
ID 266 gen 114189 top level 5 path @images
ID 267 gen 114189 top level 5 path @swap
ID 268 gen 185742 top level 5 path @snapshots

Von @, also dem Hauptsystem, werden bei jeder Aktualsierung durch pacman zwei Snapshots angelegt (vorher & nachher), die bootfähig sind. Also kann ich jeden Zustand des Systems bequem wiederherstellen, ohne die anderen Dateien dabei tangieren zu müssen. Ich kann mit dem Hauptsystem quasi Monate in die Vergangenheit reisen und nehme die aktuellen persönlichen Daten aus meinem Home-Verzeichnis einfach mit. Oder ich mounte @Home in ein völlig anderes Betriebssystem.
@Home wird jede Stunde gesichert und die Snapshots für eine Weile aufgehoben, bis sie autmatisch gelöscht werden. Dassselbe mache ich noch bei einer angeschlossenen HDD. Die restlichen Subvolumes existieren nur, damit deren Daten nicht automatisch mit gesichert werden.

Daneben beherrscht Btrfs die transparante Kompression, komprimiert also im laufenden Betrieb deine Daten. Die Kompressionsstärke ist in Stufen zwischen 0-15 einstellbar, Standard ist 3. Bei HDDs nutze ich gerne 8-10, alles darüber würde dann nichtmehr die SATA-Schnittstelle ausreizen können.

Alexander2 schrieb:
Von der Raid funktion würde ich aber abstand nehmen, bis irgendwer feststellt/Testet, das das mittlerweile Fertig entwickelt/sicher ist.

Betraf das nicht ohnehin nur die Kombi mit einem Hardware-Raid? Wie ZFS auch bringt es ja seine eigenen Raid-Funktionen mit, die zu bevorzugen sind. Und ich meine, die haben nie Probleme gemacht (kann mich da aber auch irren).

€: @swap habe ich nur angelegt, sollte ich mal einen Swap haben wollen. Aktuell nutze ich keinen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 7vor10, Alexander2, Kuristina und eine weitere Person
Es gab da irgendwo ne Seite über den aktuellen Status welcher Funktion. kann man sicher per Internetsuche finden.
 
Beelzebot schrieb:
Betraf das nicht ohnehin nur die Kombi mit einem Hardware-Raid?
Nee. BTRFS hat bei RAID 5 und 6 keinen Mechanismus, der vor sogenannten Write Holes schützt.
Das Problem ist, dass ein Schreibvorgang technisch gesehen nicht atomar ist. Sollte so einer (warum auch immer) unterbrochen werden, stimmt die RAID-Parität nicht mehr und die Daten sind futsch.

Eigentlich will man für diesen Zweck einen Journal implementieren, wie man es bspw. auch von Ext4 kennt. Das würde die Schwachstelle abdichten. Meines Wissens nach hat aber noch keiner was gemacht.
 
  • Gefällt mir
Reaktionen: Beelzebot
Linux, eine schnelle SSD und der Standard ... mein Server, der läuft 24/7 mit Mint in einer VMware. Platten sind durchgereicht zu Docker.

Läuft jetzt ein Jahr Nonstopp ;).
 
Ganz ohne Updates? Das ist doch Fahrlässig? Mint hat doch bestimmt nicht die funktionalität für den Kernel von Live Updates, das man das ohne neustart hinbekäme.
 
Was ich immer mache ist /var eine eigene Partition zu geben . Wenn das voll läuft, rennt der Rest weiter.
 
Krik schrieb:
Nee. BTRFS hat bei RAID 5 und 6 keinen Mechanismus, der vor sogenannten Write Holes schützt.

Stimmt, das wars!

konkretor schrieb:
Was ich immer mache ist /var eine eigene Partition zu geben . Wenn das voll läuft, rennt der Rest weiter.

Das ist durchaus sinnig! Ich hatte mal einen Bug mit einer Log-File, die über die Zeit mehrere hundert Gibibytes groß wurde und letztlich den gesamten freien Platz belegt hat. Hat dem System garnicht gefallen...
 
Die Sample-Size ist wahrscheinlich nichtig und es mag durchaus mein Confirmation Bias sein weil ich Btrfs aufgrund meiner eigenen Erfahrungen (diplomatisch formuliert) skeptisch gegenüber stehe, aber: Die Anzahl an Horrorgeschichten die ich von Btrfs-Nutzer:innen gehört habe ist deutlich höher als die Zahl der Erfolgsgeschichten die mir zu Ohren gekommen sind. Letztere kann ich leicht an einer Hand abzählen.
 
Das liegt auch irgendwo in der Natur der Sache :-) wenns Knallt wird geschrien, wenns läuft ist einfach alles gut und es gibt nichts zu erwähnen.

Ich kann von beidem berichten :-) (eigene Erfahrung) wobei der komplette partitionsverlust Jahre her ist und sich von damals aus bis jetzt weiterentwickelt hat..
 
sedot schrieb:
Inklusive /home 129,99GiB
Gab's das irgendwo im Sommerschlußverkauf? :D

Espero schrieb:
Auf manche Verzeichnisse wurde der Zugriff verweigert.
Konnte man das nicht mit Ändern der Zugriffsrechte beheben?
gio127 schrieb:
Wichtige Konfigs hab ich eh gespeichert.
Was denn z.B.?
ghecko schrieb:
Ja, aber was ist der Unterschied zwischen einem Volume und einem Verzeichnis, wenn ein Volume wie /home am Ende wieder als Verzeichnis in / geführt wird?
Also ich kann ja nicht soviel zu dem Thema sagen, aber wenn man mal Probleme mit dem Dateisystem hat und Daten retten muss, ist das mit einer extra Partition schon praktisch. Ob es das, aufgrund anderer möglicher Probleme, wert ist, ist natürlich eine andere Frage.
Krakadil schrieb:
Ich installiere z.B. Fedora und schei. rein, dann kann ich Fedora einfach neu installieren.
Und was passiert dann mit Konfigurationsdaten usw. von Programmen, die mit dem BS mitkommen, z.B. Firefox? Gibts da nicht Konflikte mit Programm-Ordnern, die da schon drin sind?
 
  • Gefällt mir
Reaktionen: Espero und sedot
Zurück
Oben