Y-Chromosome
Commander
- Registriert
- Aug. 2008
- Beiträge
- 2.923
man sagt 1gb ram pro 1tb plattenplatz
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
Wie jedes FS: mit den gewünschten Parametern erstellt man das FS, dann mountet man es (oder permanent in die fstab), befüllt mit den gewünschten Daten usw.Mr.Seymour Buds schrieb:Wie "bedient" man den ext4? Bin kein Spezialist für Dateisysteme. Da würde ich mir wirklich mal einen tiefergehenden Artikel wünschen....Gerade bei Linux hat man ja mehr Auswahl, als zB Windows mit "nur" NTFS...
Und was wäre mit einer klassischen Boot-Partition?blackiwid schrieb:Hatte glaub bei nem umzug mein fedora auf ne btrfs platte kopiert und zum laufen gebracht. es macht fuer mich keinen sinn eine btrfs partition an zu legen oder lvm zu benutzen um zu partitionen wenn btrfs das alles im grunde selber kann. daher hab ich direkt /dev/sda mit btrfs formatiert.
wenn ich manuell grub-install drauf laufen lasse laeuft alles wunderbar. Aber irgend ein Muellscript von Redhat crashed oder bricht ab wenn ein neuer kernel als update kommt. und ich muss jedesmal hinterher manuell grub2-mkconfig laufen lassen.
Aber das macht der Kernel doch bei jedem FS, permanent.Ilsan schrieb:Das stimmt doch gar nicht. ZFS nutzt den Ram halt als Cache, daher profitiert es eben von viel Ram. Wenn wenig Ram vorhanden ist so fällt der Speed eben auf das Tempo der Platten zurück.
[...]
4GB reichen vollkommen für ZFS, es kommt drauf an was man genau vorhat.Wenn 32GB drin sind werden halt auch 32GB fürs Caching benutzt.
Gar nichts. Du kannst dir den Code auch ziehen und das Kernel Modul in den eigenen Kernel backen, sollte dieses aus Lizenzgründen irgend wann mal wieder raus genommen werden.Bruddelsupp schrieb:Was bedeutet es für die Anwender, wenn Canonnical eine Rechtstreit dazu verliert? Ist es ein Risiko, das FS einzusetzen?
Es gibt aber keinen Lesecache in der Form. Kopier doch mehrmals hintereinander eine 1GB große Datei irgendwo anders hin. Die wird jedesmal wieder von der Platte neu gelesen.Aber das macht der Kernel doch bei jedem FS, permanent.
Sobald man Daten bewegt, wird der freie RAM als Cache verwendet.
Erst mal müßte es einen Kläger geben...Bruddelsupp schrieb:Was bedeutet es für die Anwender, wenn Canonnical eine Rechtstreit dazu verliert? Ist es ein Risiko, das FS einzusetzen?
ja dann brauch ich aber wieder partitionen und wollte mir den overhead ersparen, grub selbt kommt ja auch super damit klar aber dieses von geisteskranken Redhat Angestellten tool grubby faengt hier grub ab und wirft einen Fehler obwohl alles perfekt ist. Halt weil Redhat das nicht offiziel supportet. Das grubteam tuts aber. muss nun jeder opensource software entwickler erst redhat fragen ob sie bestimmte features anbieten darf, und wenn nicht dann werden die features von Redhat unterbunden?cirrussc schrieb:Und was wäre mit einer klassischen Boot-Partition?
Ilsan schrieb:Es gibt aber keinen Lesecache in der Form. Kopier doch mehrmals hintereinander eine 1GB große Datei irgendwo anders hin. Die wird jedesmal wieder von der Platte neu gelesen.
Ilsan schrieb:Das stimmt doch gar nicht. ZFS nutzt den Ram halt als Cache, daher profitiert es eben von viel Ram. Wenn wenig Ram vorhanden ist so fällt der Speed eben auf das Tempo der Platten zurück.
Und btrfs isst nicht gerade wegen des speeds beruehmt (sondern eher wegen den features) und trotzdem zersaegt es zfs. Mag an der fuse implementierung liegen aber es gibt sehr gute fuse implementierungen mit hohem speed.
Sprich durch mehr Ram kann man ZFS "tunen", aber wirklich brauchen tut man den Ram nicht, es ist dann eben nur nicht ganz so schnell. Sollte aber dann auf dem Niveau von btrfs liegen eigentlich.
4GB reichen vollkommen für ZFS, es kommt drauf an was man genau vorhat.Wenn 32GB drin sind werden halt auch 32GB fürs Caching benutzt.
Aber auch btrfs kann kein Ram nutzen, der nicht da ist. Zaubern kann ZFS halt auch nicht Dass der Speed leidet ist daher in meinen Augen ne ungünstige Formulierung.
Sorry aber kannst du mir mal verraten wie du Daten wiederherstellen willst ohne Kopie? Siehst du das als Nachteil jetzt an weil ZFS sich die verlorenen Daten nicht aus den Fingern saugen kann?
Ich schätze du würdest den Nobel Preis dafür bekommen wenn du einen Algo erfindest der sowas kann
Obendrein hast du nicht ganz recht. Bei einer HDD kann ZFS dir zumindest sehr wohl anzeigen dass die Daten beschädigt sind. Noch dazu existieren auch bei einer Platte zumindest Kopien der Metadaten welche wieder hergestellt werden können. Wenn du noch mehr willst setze halt copies auf 2. Dann werden auch deine Dokumente 2mal auf der selben Platte abgelegt und können somit auch wiederhergestellt werden. Im Rahmen dessen was physikalisch möglich ist! Informationen aus dem Nichts heraus kannst du nicht wiederherstellen.
Was obendrein ein tolles Feature wäre wenn ich eine große Festplatte verbaut habe aber nur wenig Daten habe zum drauf speichern. So kann ich den Platz dennoch für mich sinnvoll nutzen, weil meine Daten doppelt vorhanden sind und kann die eine Kopie nicht gelesen werden, wird eben die andere Kopie gelesen.
Mr.Seymour Buds schrieb:Es ging doch im Wesentlichen um Ubuntu Desktop. Was hat das mit NAS und Server zu tun?
Sollte man, gegeben Ubuntu wählt nun ZFS, auf EEC Ram setzen und wenn ja, warum? Fragen über Fragen....
Nur beziehen sich solche Aussagen von "solchen" Seiten auch oft auf irgendwelche Dinge, da wo irgendjemand mal gehört hat dass ZFS viel Ram benötigt. Komisch ist auch dass oft ne generelle Empfehlung ausgesprochen werden kann. Scheint wohl tatsächlich komplett egal sein um was für einen Anwendungsfall es dann letztendlich geht, waIch kenne keine seite die empfiehlt ne bestimmte menge von ram zu benutzen fuer btrfs, ich kenne seiten die das aber fuer ZFS tun.
Nur weil es oft wo steht, muss es deswegen nicht korrekt sein. Ich habe selber viel über ZFS gelesen und bin zu dem Entschluss gekommen dass viele Seiten auch wenn sie über ZFS berichten sich nicht wirklich damit beschäftigt haben.Ich kann dir nicht im detail die gruende nennen, es gibt aber 0 artikel darueber das btrfs massiv ram braucht und 1mio das zfs viel ram braucht oder "will". Das ist fakt und hab versucht benchmarks zu finden, mit wenig ram, sah aber nur ein benchmark von 2013 auf phoronix wo mit 8gb ram (was ja viel ist) btrfs zfs zersaeegt hat. Ich wuerde wetten das bei 1-4gb ram die Benchmarks deutlich staerker noch zu gunsten btrfs gehen wuerden.
Wenn eine Seite das für ZFS empfiehlt dann sollte es auch begründet werden können, notfalls steckt man 2GB, 4GB und 8GB in den Rechner und vergleicht. Aber einfach nur das kopieren was andere kopieren ist bisschen dünn findest nicht?Ich kenne keine seite die empfiehlt ne bestimmte menge von ram zu benutzen fuer btrfs, ich kenne seiten die das aber fuer ZFS tun.
Haha. Genau und bei Linux ist ja von der Benutzerfreundlichkeit genauso wie OSX, wa?Schoen und gut aber soll leute geben die nicht vollzeit systemadmins sind, die wollen mit ihrem pc arbeiten und nicht staendig das fs managen und beobachten.
Genau 50 verschiedene Tools sonst geht gar nix. lol. Wo ist das Problem mit den Angaben? Wenn das OS irgendwelche Temp Dateien speichert wird auch auf einem "normalen" Filesystem der Platz weniger obwohl ich aktiv nix abspeichere.es kann sein du hast 30gb dateien auf deinem os aber es sind 80gb belegt, teilweise widersprechen sich die angaben auch. Mag ja auch sinnvoll sein, aber das ist ne umgewoehnug bei ext4 oder xfs schau bei df krieg eine anzeige die stimmt und gut, ich muss mich nicht mit 50 verschieden tools und anzeigen und der komplexen struktur des fs auseinandersetzen und alles ist recht simpel.
Ilsan schrieb:Nen simples 2Bay NAS von Synology wird auch nicht da eingesetzt wo zig Zugriffe gleichzeitig stattfinden. Erwartet auch niemand, wieso dann bei ZFS auf einmal? Es skaliert eben, das ist alles. Willst du mehr Leistung benötigst du halt mehr Ressourcen. Hat aber nicht speziell was mit ZFS zu tun. Ich hab hier nen NAS das 4GB Ram besitzt, und nen anderes mit 9GB. Unterschied ist quasi keiner vorhanden, es ist sogar eher so dass das mit 4GB schneller ist, mag damit zusammen hängen weil die CPU stärker ist und weil 6 HDDs drin sind statt nur 2 bei dem anderen.
Und mal ehrlich, klar würde das Teil zusammen brechen wenn jetzt auf einmal 20 Leute auf einmal drauf zugreifen. Da würde es aber auch keien Abhilfe schaffen wenn ich Linux mit btrfs einsetze.
chithanh schrieb:Verletzt wird die GPL, genauer gesagt der Passus, der besagt dass GPL-Code keinen weiteren Einschränkungen unterworfen werden darf, ferner muss Code der von der GPL abgeleitet ist, ebenfalls unter der GPL lizenziert sein.
Die CDDL von Solaris macht solche Einschränkungen und daher ist sie nicht zur GPL kompatibel.
Lösungen:
Canonical scheint momentan auf letzteres zu setzen.
- Kernel-Lizenz wird geändert zu einer die CDDL-kompatibel ist, oder
- ZFS-Lizenz wird geändert zu einer die GPL-Kompatibel ist, oder
- beide ändern ihre Lizenzen (z.B. Kernel nach GPL v3, ZFS nach Apache 2.0), oder
- man sitzt das Problem aus nach dem Motto: wo kein Kläger, da kein Richter
Es ist übrigens keinesfalls ausgeschlossen, dass der Kernel seine Lizenz ändert. Zwar müssten alle Copyrightinhaber (bzw. deren Erben) zustimmen, und die Teile für die man keine Zustimmung bekommt neu geschrieben werden. Aber da mit jedem Kernel-Release sowieso erhebliche Teile neu geschrieben werden ist das im Bereich des Möglichen.
Mr.Seymour Buds schrieb:Gerade bei Linux hat man ja mehr Auswahl, als zB Windows mit "nur" NTFS...
tek9 schrieb:Damit wiederholtst du nur mit anderen Worten das was in dem Artikel steht. Warum das ein Problem sein soll wenn beide Produkte auf unterschiedliche Lizenzen aufsetzen wissen wir immer noch nicht