Wie viel Festplattenspeicher kann Linux Ubuntu 14.04 verwalten?
4 Antworten
Das kommt auf das verwendete Dateisystem an. Die 32TB-Antwort ist sicherlich nicht richtig. Bei ext4 ist derzeit z.B. bei 1 EiB Schluß.
Die Frage ist falsch gestellt, bzw. der falsche Kontext !
Wieviel das ist, hängt weniger vom Betriebssystem und vom Kernel ab, sondern vielmehr vom verwendeten Dateisystem ! Die gemachten Limits anderer Art, wie z.B. MBR vs. GPT haben damit nicht direkt zu tun und können softwaretechnisch gelöst werden...
Siehe dazu hier :
https://de.wikipedia.org/wiki/Liste_von_Dateisystemen
Abteilung LINUX
EXT4 unterstützt auf jeden Fall schon mal mindestens 16 TiB ( Terabytes ) , technisch jedoch bis 1 EiB ( ExaByte ) ! Wenn das immer noch nicht reichen sollte:
Das zukünftige Standarddateisystem zukünftiger Linuxsysteme, bzw. Linuxkernel soll irgendwann bald mal BTRFS werden:
Damit gehen dann maximal 16 Exabytes.... Es wird noch viel Zeit vergehen, bis reale physische Datenträger in den Bereich aktueller Limits kommen werden. Das werden dann sicher keine Festplatten oder SSDs nach dem heutigen Funktionsprinzip sein.... Vieleicht wird es dann ein holografischer Speicher sein !???
Wie ihr seht, wenn ihr nicht gerade FAT FAT32 verwendet, sind die Limits mit aktuellen Festplatten noch lange nicht erreichbar....
Du meinst Tibibytes und Eibibytes :D Das ist ein Unterschied! (sorry xD)
Beliebig viel. Du müsstest rein theoretisch sehr große Datenträger (die noch nicht erfunden wurden) in mehrere Partitionen unterteilen, falls Filesystem-spezifische Limits gerissen werden.
Die nächste Hürde ist dann die Zahl der Datenträger, die an bestimmte Bussysteme real existierender Computer angeschlossen werden kann.
Wenn man netzwerkweite Storage (remote mounts) mit einbezieht, gibt's eigentlich gar keine Limits.
Linux wird allerdings bei extrem großen Plattenkapazitäten irgendwann ineffizient, wenn dem nicht genug Hauptspeicher gegenübersteht. Denn dann funktionieren die Caching-Strategien nicht mehr vernünftig, so dass alle Zugriffe schnarchlangsam werden.
Kleiner Tipp gegen dieses Horrorszenario: Automounter verwenden. Ist zwar keine vollständige Problemlösung, sorgt aber zumindest mal dafür, dass inaktive Datenträger/Partitionen keinen Hauptspeicherbedarf produzieren. Sie werden ja nach kurzer Zeit automatisch ausgehängt.
Ansonsten: die Inodes müssen meines Wissens nicht vollständig im Hauptspeicher liegen, bzw. es ist nur eine virtuelle Allokation (Prinzip "mmap"). D. h. das Limit ist dann nicht der real existierende Arbeitsspeicher, sondern der (heute meist 64 bit breite) Adressraum.
Nee neee, so ist das nicht gemeint... ...und gegen das Szenario hilft auch kein Automounter nich ! Ausserdem haben fast ausschliesslich nur GUI-Systeme einen Automaounter und genau so was passiert aber besonders bei Servern ohne GUI und ohne Automounter !
Angenommen ich habe eine 2 PB ( 1 Pentabyte = 1000 TB ) Festplatte und richte darauf eine EXT4-Partition ein. Der Server hat satte 128 GB RAM, was zum Mounten der 2 PB-Partition ausreichen würde, solange sie noch leer ist. Solche Riesendatenträger gibts zwar noch lang nicht, aber das trifft auch für kleinere Verhältnisse und RAID-Verbände zu...
Die User schaufeln nun fleissig Daten auf den Server und legen tonnenweise Verzeichnisse und Milliarden von Dateinen an..... Zunächst geht das noch alles gut, aber der Speicherbedarf des Dateisystemmoduls steigt immer mehr an, bis das physische Limit überschritten wird.... Bei einem Server kann kein "Automounter" einfach mal schnell eine Partition aushängen... Jetzt gehts aber los mit Fehlern..... Sollte nun der Admin auf die dumme Idee kommen, das System neu zu rebooten, haben wir genau dieses Horrorszenario ! Dann hätte allerdings der Systemintegratior, der das gebaut hat wirklich geschlafen oder ist einfach unkompetent..... Mit der goldenen Regel ein Volumen nur " so klein wie möglich, aber so groß wie nötig" zu machen, natürlich mit großzügigem Weitblick auf den zukünftigen Platzbedarf, fährt man immer gut, besonders bei Systemvolumen. Je kleiner ein Dateisystem, desto geringer die Fehlerwahrscheinlichkeit, desto schneller der Zugriff, desto schneller gehen Checks und Reparaturen mit hoher Erfolgsquote, desto einfacher und schneller sind Backups möglich, desto stabiler und unkritischer wird das Ganze....
Das kommt ganz auf das benutzte Dateisystem an. Hier eine Übersicht:
http://wiki.ubuntuusers.de/dateisystem#Weitere-Merkmale
Und dann kann man ja noch mehrere Festplatten haben, oder wenn es ganz "eng" wird, auf einer Festplatte mehrere Partitionen. Also im Grunde ist da mit dem richtgen Dateisystem keine wirkliche Begrenzung seitens der Software bei Linux und folglich bei Ubuntu.
PS: 1 EiB (Exbibyte) = 1024 PiB (Pebibyte) = 1024*1024 TiB (Tebibyte).
Ja richtig und im gegenteil ! Alle INODE-Tables und Hauptverzeichnisse 1.Ebene werden beim Mounten eines Datenträgers in den RAM geladen. Bei einem solchen Riesendatenträger würde der RAM keines Systems ausreichen, jedem System würde dabei der Speicher ausgehen ! Und das Schlimmste dabei kommt noch. Anfangs ist das Haupverzeichnis noch leer und es könnte vieleicht doch gemountet werden. Je mehr Dateisystemstrukturen auf dem Volumen erstellt werden, desto höher wird aber der Speicherbedarf ! So kann es passieren ( ist aich schon passiert ), dass ein anfangs einwandfrei mountbarer Datenträger mit zunehmender Belegung plötzlich Fehler verursacht ! Die Fehler lassen sich dann allerdings nicht mehr reparieren ( out of Memory ) und der Datenträger kann ab dann nicht mehr gemountet werden. Der einzige Ausweg... Speicher erweitern ! Viele solche Systeme sind jedoch schon maximal ausgebaut und dann siehts wirklich schlecht aus....