Ist Btrfs ausgereift?
Hallo! Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen. Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design": https://de.wikipedia.org/wiki/Btrfs Der letzte Punkt ist von 2018. Seitdem ist also schon viel Zeit vergangen. Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge? Ich frage mich auch, wie es mit Verschlüsselung steht, und ob ich meine zwei internen Massenspeicher (eine SSD und eine Festplatte) mit Btrfs besser zusammenbinden kann, so daß ein einheitlicher Verzeichnisbaum entsteht. Bis jetzt habe ich symbolische Verknüpfungen auf Unterverzeichnisse der Platte... Tschüß und Danke im Voraus, Volker
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design":
https://de.wikipedia.org/wiki/Btrfs
Der letzte Punkt ist von 2018. Seitdem ist also schon viel Zeit vergangen.
Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge?
Ich frage mich auch, wie es mit Verschlüsselung steht, und ob ich meine zwei internen Massenspeicher (eine SSD und eine Festplatte) mit Btrfs besser zusammenbinden kann, so daß ein einheitlicher Verzeichnisbaum entsteht. Bis jetzt habe ich symbolische Verknüpfungen auf Unterverzeichnisse der Platte...
RAID und/oder LVM. Kannst du mit btrfs haben. Solltest Du dir aber überlegen. Eine SSD für das Betriebssystem allein kosten nicht mehr die Welt und wenn Daten und Betriebssystem getrennt sind, hast du bei nur einem fehlerhaften Massenspeicher, egal welchem, weniger Aufwand für die Wiederherstellung. SSDs sind auch schneller als HDDs, m.E. baust du dir eine Schreibbremse ein, wenn Daten per LVM zwischen SSD und HDD gesplittet werden und spart Kopfschmerzen wenn einer ausfällt. Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert. Für meinen Zweck brauche ich allerdings auf der Daten-HDD kein btrfs, mir reicht da ext4, was sich auch leichter vergrößern bzw verkleinern lässt. Das Folgende kennst du vielleicht: https://de.linux-console.net/?p=16494 Gruß Peter
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design":
https://de.wikipedia.org/wiki/Btrfs
Der letzte Punkt ist von 2018. Seitdem ist also schon viel Zeit vergangen.
Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge?
Ich frage mich auch, wie es mit Verschlüsselung steht, und ob ich meine zwei internen Massenspeicher (eine SSD und eine Festplatte) mit Btrfs besser zusammenbinden kann, so daß ein einheitlicher Verzeichnisbaum entsteht. Bis jetzt habe ich symbolische Verknüpfungen auf Unterverzeichnisse der Platte...
RAID und/oder LVM.
Ich will nicht beide zu einem Dateisystem zusammenfassen, weil ein Laufwerk eine SSD und das andere eine Festplatte ist. Dann wüßte ich ja nie, ob meine neuen Daten im schnellen SSD- oder dem langsamen Festplattenteil gespeichert werden. Meine Idee waren sowas wie bind mounts, die es (nur?) unter ext4 gibt.
Kannst du mit btrfs haben. Solltest Du dir aber überlegen. Eine SSD für das Betriebssystem allein kosten nicht mehr die Welt und wenn Daten und Betriebssystem getrennt sind, hast du bei nur einem fehlerhaften Massenspeicher, egal welchem, weniger Aufwand für die Wiederherstellung.
Du meinst eine weitere (kleine) SSD, zu der, die ich schon habe? Das muß ich mir überlegen...
SSDs sind auch schneller als HDDs, m.E. baust du dir eine Schreibbremse ein, wenn Daten per LVM zwischen SSD und HDD gesplittet werden und spart Kopfschmerzen wenn einer ausfällt.
Ja, s.o.
Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert.
Ja, das kenne ich. Ich will aber für bestimmte Daten die Geschwindigkeit einer SSD. Sonst hätte ich das auch so gemacht.
Für meinen Zweck brauche ich allerdings auf der Daten-HDD kein btrfs, mir reicht da ext4, was sich auch leichter vergrößern bzw verkleinern lässt.
Das Folgende kennst du vielleicht:
Kannte ich noch nicht. Ist sehr informativ. Btrfs schneidet besser ab als XFS. Für mich ist die Schnappschuß-Funktion von Btrfs ein entscheidendes Merkmal. Leider gibt es keine Anmerkungen zur Stabilität der beiden Dateisysteme. Was wohl eher dafür spricht, daß es kein Thema mehr ist (weil die Probleme behoben wurden). Danke für die Infos. Die haben mich bestärkt, auf Btrfs zu setzen. Volker
Am 01.10.24 um 13:10 schrieb Volker Wysk:
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk: ... Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert.
Ja, das kenne ich. Ich will aber für bestimmte Daten die Geschwindigkeit einer SSD. Sonst hätte ich das auch so gemacht. ...
Schön und gut, aber wie ich die Infos verstehe ist Geschwindigkeit nicht die Stärke vom btrfs. Suse sieht per default für das Betriebssystem btrfs und für Datenpartitionen xfs vor. Ich habe auf meinem Desktop mit Leap 15.6 eine schnelle SSD für das System und /home und für Daten, auch mit btrfs, eine passable 2TB SSD, wo ich alles hinverlinke, was ich nicht in /home brauche. Alles schön schnell aber eigentlich brauche ich die Funktionalität von btrfs nicht für meine Daten, da würde ext4 genügen und die Partition ließe sich bei Bedarf mit Yast einfacher verändern. Ich meine das Rollback von btrfs ist für das System nützlich, für Daten scheint mir eine Backuplösung wie backintime sinnvoller. Was manchmal nervt, btrfs räumt gelegentlich in unpassenden Momenten die Platte auf und verursache eine Pause. Ich habe noch nicht herausgefunden, wo ich die Zeit einstellen kann, zu der so etwas bevorzugt stattfinden soll. Die vorherige Daten-HDD habe übrigens ich als Backupspeicher in ein USB-Gehäuse verfrachtet. Gruß Peter
Am Dienstag, dem 01.10.2024 um 14:41 +0200 schrieb Peter McD:
Am 01.10.24 um 13:10 schrieb Volker Wysk:
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk: ... Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert.
Ja, das kenne ich. Ich will aber für bestimmte Daten die Geschwindigkeit einer SSD. Sonst hätte ich das auch so gemacht. ...
Schön und gut, aber wie ich die Infos verstehe ist Geschwindigkeit nicht die Stärke vom btrfs.
Ich dachte an den Geschwindigkeitsunterschied zwischen einer SSD und einer Festplatte.
Suse sieht per default für das Betriebssystem btrfs und für Datenpartitionen xfs vor.
Ich muß mal nach den Gründen dafür recherchieren...
Ich habe auf meinem Desktop mit Leap 15.6 eine schnelle SSD für das System und /home und für Daten, auch mit btrfs, eine passable 2TB SSD, wo ich alles hinverlinke, was ich nicht in /home brauche.
So ähnlich mache ich es mit meiner internen SSD (PCIe) und der internen Platte. Mir war gar nicht bewußt, daß es bei der Geschwindigkeit da so große Unterschiede zwischen den SSDs gibt... Ist die eine eine PCI-Expreß und die andere nach dem älteren PCI-Standard?
Alles schön schnell aber eigentlich brauche ich die Funktionalität von btrfs nicht für meine Daten, da würde ext4 genügen und die Partition ließe sich bei Bedarf mit Yast einfacher verändern.
Ich meine das Rollback von btrfs ist für das System nützlich, für Daten scheint mir eine Backuplösung wie backintime sinnvoller.
Mit Rollback meinst Du die Rückkehr zu einem vorherigen Schnappschuß, nachdem eine ("rolling") Aktualisierung das System kaputt gemacht hat? Das wird als wesentlicher Vorteil von Tumbleweed gegenüber anderen Rolling- Release-Distributionen genannt. Da muß ich noch mehr recherchieren, wie das geht...
Was manchmal nervt, btrfs räumt gelegentlich in unpassenden Momenten die Platte auf und verursache eine Pause. Ich habe noch nicht herausgefunden, wo ich die Zeit einstellen kann, zu der so etwas bevorzugt stattfinden soll.
Hmmm... Das ist nicht schön.
Die vorherige Daten-HDD habe übrigens ich als Backupspeicher in ein USB-Gehäuse verfrachtet.
Ich verwende auch zwei externe USB-Festplatten für die Datensicherung. Tschüß! Volker
Am 02.10.24 um 18:10 schrieb Volker Wysk:
Am Dienstag, dem 01.10.2024 um 14:41 +0200 schrieb Peter McD:
Am 01.10.24 um 13:10 schrieb Volker Wysk:
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk: ... Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert.
Ja, das kenne ich. Ich will aber für bestimmte Daten die Geschwindigkeit einer SSD. Sonst hätte ich das auch so gemacht. ...
Schön und gut, aber wie ich die Infos verstehe ist Geschwindigkeit nicht die Stärke vom btrfs.
Ich dachte an den Geschwindigkeitsunterschied zwischen einer SSD und einer Festplatte.
Suse sieht per default für das Betriebssystem btrfs und für Datenpartitionen xfs vor.
Ich muß mal nach den Gründen dafür recherchieren...
Ich habe auf meinem Desktop mit Leap 15.6 eine schnelle SSD für das System und /home und für Daten, auch mit btrfs, eine passable 2TB SSD, wo ich alles hinverlinke, was ich nicht in /home brauche.
So ähnlich mache ich es mit meiner internen SSD (PCIe) und der internen Platte.
Mir war gar nicht bewußt, daß es bei der Geschwindigkeit da so große Unterschiede zwischen den SSDs gibt... Ist die eine eine PCI-Expreß und die andere nach dem älteren PCI-Standard?
Bei Lesen dürfte die Unterschiede nicht so groß seine, beim Schreiben hingegen dürften je nach SSD-Aufbau und Firmware die Schreibrate je nach Datenmenge absinken.
Alles schön schnell aber eigentlich brauche ich die Funktionalität von btrfs nicht für meine Daten, da würde ext4 genügen und die Partition ließe sich bei Bedarf mit Yast einfacher verändern.
Ich meine das Rollback von btrfs ist für das System nützlich, für Daten scheint mir eine Backuplösung wie backintime sinnvoller.
Mit Rollback meinst Du die Rückkehr zu einem vorherigen Schnappschuß, nachdem eine ("rolling") Aktualisierung das System kaputt gemacht hat? Das wird als wesentlicher Vorteil von Tumbleweed gegenüber anderen Rolling- Release-Distributionen genannt. Da muß ich noch mehr recherchieren, wie das geht...
Gibt bei Suse bei allen Varianten als Standard und ist für das System toll, aber bei Daten sehe ich bei meiner Verwendung keine Notwendigkeit. Gruß Peter
Am Mittwoch, dem 02.10.2024 um 21:19 +0200 schrieb Peter McD:
Am 02.10.24 um 18:10 schrieb Volker Wysk:
Am Dienstag, dem 01.10.2024 um 14:41 +0200 schrieb Peter McD:
Am 01.10.24 um 13:10 schrieb Volker Wysk:
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk: ... Hier läuft ein Laptop, macht nur voll verschlüsselt Sinn, Suse Slowroll und ein kleines /HOME auf der SSD, die Daten auf der größeren HDD, funktioniert.
Ja, das kenne ich. Ich will aber für bestimmte Daten die Geschwindigkeit einer SSD. Sonst hätte ich das auch so gemacht. ...
Schön und gut, aber wie ich die Infos verstehe ist Geschwindigkeit nicht die Stärke vom btrfs.
Ich dachte an den Geschwindigkeitsunterschied zwischen einer SSD und einer Festplatte.
Suse sieht per default für das Betriebssystem btrfs und für Datenpartitionen xfs vor.
Ich muß mal nach den Gründen dafür recherchieren...
Ich habe auf meinem Desktop mit Leap 15.6 eine schnelle SSD für das System und /home und für Daten, auch mit btrfs, eine passable 2TB SSD, wo ich alles hinverlinke, was ich nicht in /home brauche.
So ähnlich mache ich es mit meiner internen SSD (PCIe) und der internen Platte.
Mir war gar nicht bewußt, daß es bei der Geschwindigkeit da so große Unterschiede zwischen den SSDs gibt... Ist die eine eine PCI-Expreß und die andere nach dem älteren PCI-Standard?
Bei Lesen dürfte die Unterschiede nicht so groß seine, beim Schreiben hingegen dürften je nach SSD-Aufbau und Firmware die Schreibrate je nach Datenmenge absinken.
Alles schön schnell aber eigentlich brauche ich die Funktionalität von btrfs nicht für meine Daten, da würde ext4 genügen und die Partition ließe sich bei Bedarf mit Yast einfacher verändern.
Ich meine das Rollback von btrfs ist für das System nützlich, für Daten scheint mir eine Backuplösung wie backintime sinnvoller.
Mit Rollback meinst Du die Rückkehr zu einem vorherigen Schnappschuß, nachdem eine ("rolling") Aktualisierung das System kaputt gemacht hat? Das wird als wesentlicher Vorteil von Tumbleweed gegenüber anderen Rolling- Release-Distributionen genannt. Da muß ich noch mehr recherchieren, wie das geht...
Gibt bei Suse bei allen Varianten als Standard und ist für das System toll, aber bei Daten sehe ich bei meiner Verwendung keine Notwendigkeit.
Naja, wenn man Btrfs für die Daten verwendet und die Möglichkeit für Schnappschüsse hat, dann finden sich vielleicht auch Anwendungen. "Wer einen Hammer hat, sieht überall Nägel." :-) Tschüß, Volker
Am 04.10.24 um 10:15 schrieb Volker Wysk:
Am Mittwoch, dem 02.10.2024 um 21:19 +0200 schrieb Peter McD:
Am 02.10.24 um 18:10 schrieb Volker Wysk:
Am Dienstag, dem 01.10.2024 um 14:41 +0200 schrieb Peter McD:
Am 01.10.24 um 13:10 schrieb Volker Wysk:
Am Montag, dem 30.09.2024 um 20:13 +0200 schrieb Peter McD: ... Ich meine das Rollback von btrfs ist für das System nützlich, für Daten scheint mir eine Backuplösung wie backintime sinnvoller.
Mit Rollback meinst Du die Rückkehr zu einem vorherigen Schnappschuß, nachdem eine ("rolling") Aktualisierung das System kaputt gemacht hat? Das wird als wesentlicher Vorteil von Tumbleweed gegenüber anderen Rolling- Release-Distributionen genannt. Da muß ich noch mehr recherchieren, wie das geht...
Gibt bei Suse bei allen Varianten als Standard und ist für das System toll, aber bei Daten sehe ich bei meiner Verwendung keine Notwendigkeit.
Naja, wenn man Btrfs für die Daten verwendet und die Möglichkeit für Schnappschüsse hat, dann finden sich vielleicht auch Anwendungen. "Wer einen Hammer hat, sieht überall Nägel." :-)
Wie geschrieben, kann man machen, eher weniger wegen der Schnappschüsse sondern wegen CopyOnWrite. Gruß Peter
On Wed, 2 Oct 2024 21:19:11 +0200 Peter McD <peter.posts@gmx.net> wrote:
Mir war gar nicht bewußt, daß es bei der Geschwindigkeit da so große Unterschiede zwischen den SSDs gibt... Ist die eine eine PCI-Expreß und die andere nach dem älteren PCI-Standard?
Bei Lesen dürfte die Unterschiede nicht so groß seine, beim Schreiben hingegen dürften je nach SSD-Aufbau und Firmware die Schreibrate je nach Datenmenge absinken.
Hinsichtlich der Schnittstelle liegen m.W. die Hauptunterschiede zwischen Zugriff via HBA (PCI oder PCIe) und NVMe. PCI ist hauptsächlich deswegen langsamer, weil es schon lange nicht mehr weiterentwickelt wird, aber Systeme, bei denen man die Wahl hat, gab es auch nur etliche Jahre lang. Bei den SSDs wird zumindest im Enterprise-Umfeld hinsichtlich der hauptsächlichen Zugriffscharakteristik differenziert nach "hauptsächlich Lesen", "hauptsächlich Schreiben" und "ausgewogener R/W-Zugriff". Da geht's sowohl um Performance als auch um Lebensdauer. Hinsichtlich Lese-Performance hast Du recht, wenn ich die Zahlen noch richtig im Kopf habe. Allerdings leben diese SSDs bei hauptsächlichen Lesebetrieb recht lange und da ihre GB-Preise niedriger sind, kann man sich auch sehr große SSDs leisten. Wir setzen in unserm zentralen, HDD-basierten SAN ein Write-Log aus einem RAID-1 aus ziemlich teuren Schreib-SSDs von nur 375 GB ein, die selten zu mehr als 10% belegt sind. Als Lese-Cache kommt hingegen eine 6-TB-SSD zum Einsatz. War damals das Größte, was am Markt war, sonst hätten wir was noch größeres gekauft. Gruß, Tobias.
On Mon, 30 Sep 2024 18:56:10 +0200 Volker Wysk <post@volker-wysk.de> wrote:
Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design":
Ich habe nur bedingt eigene Erfahrungen damit. Im Kern sind es 2 SLES-15-Server, die noch damit installiert sind. Sie funktionieren problemlos, nutzen aber auch keine der zusätzlichen Möglichkeiten - insbesondere, weil sie als VM auf einem zentralen Storage laufen. Da ich mich nicht ständig mit neuen FS beschäftigen möchte, sind die anderen SLES-15-Server alle mit LVM2 und ext4fs eingerichtet, weil ich mich damit halt besser auskenne. Könnte mir vorstellen, dass die Snapshots interessant sein könnten, wenn das System auf Hardware läuft, aber keine eigenen Erfahrungen, da wir hier bei HW-Servern OEL einsetzen. Ansonsten kann man eigentlich das meiste mit LVM2 und ext4 erschlagen. Nur bei großen FS kommt das Konzept an seine Grenzen, aber da ist mittlerweile ZFS auch unter Linux so ausgereift, dass es problemlos eingesetzt werden kann. Wobei ZFS schon auch Einarbeitung benötigt. Wird halt mittlerweile auch unter Linux viel eingesetzt. QNAP bieten die neuen Systeme alternativ mit ext4fs oder ZFS an und die gelten ja nicht als besonders experimentierfreudig. Einige Distributionen wie Ubuntu bieten es mittlerweile beim initialen Setup an. Bisher musste man es immer im Nachgang installieren, also Basis-OS auf ext4 / LVM2 und zusätzlicher Storage nach Installation diverser Tools und Treiber per ZFS. Ich will Dir nicht von btrfs abraten, ist bestimmt interessant - insbesondere auf Hardware. Nur wenn Stabilität an erster Stelle steht, würde ich eher zu ext4 und LVM2 raten, wenn die Platten < 1 TB sind. Bei größeren Platten eher XFS und LVM2 oder ZFS. Gruß, Tobias Crefeld.
Synolgy erwingt das bei bestimmten Funktionen und Tools. Also wohl ja. Gruss Von meinem iPhone gesendet
Am 01.10.2024 um 02:03 schrieb Tobias Crefeld <tclx@klekih-petra.de>:
On Mon, 30 Sep 2024 18:56:10 +0200 Volker Wysk <post@volker-wysk.de> wrote:
Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design":
Ich habe nur bedingt eigene Erfahrungen damit. Im Kern sind es 2 SLES-15-Server, die noch damit installiert sind. Sie funktionieren problemlos, nutzen aber auch keine der zusätzlichen Möglichkeiten - insbesondere, weil sie als VM auf einem zentralen Storage laufen.
Da ich mich nicht ständig mit neuen FS beschäftigen möchte, sind die anderen SLES-15-Server alle mit LVM2 und ext4fs eingerichtet, weil ich mich damit halt besser auskenne. Könnte mir vorstellen, dass die Snapshots interessant sein könnten, wenn das System auf Hardware läuft, aber keine eigenen Erfahrungen, da wir hier bei HW-Servern OEL einsetzen.
Ansonsten kann man eigentlich das meiste mit LVM2 und ext4 erschlagen. Nur bei großen FS kommt das Konzept an seine Grenzen, aber da ist mittlerweile ZFS auch unter Linux so ausgereift, dass es problemlos eingesetzt werden kann. Wobei ZFS schon auch Einarbeitung benötigt. Wird halt mittlerweile auch unter Linux viel eingesetzt. QNAP bieten die neuen Systeme alternativ mit ext4fs oder ZFS an und die gelten ja nicht als besonders experimentierfreudig. Einige Distributionen wie Ubuntu bieten es mittlerweile beim initialen Setup an. Bisher musste man es immer im Nachgang installieren, also Basis-OS auf ext4 / LVM2 und zusätzlicher Storage nach Installation diverser Tools und Treiber per ZFS.
Ich will Dir nicht von btrfs abraten, ist bestimmt interessant - insbesondere auf Hardware. Nur wenn Stabilität an erster Stelle steht, würde ich eher zu ext4 und LVM2 raten, wenn die Platten < 1 TB sind. Bei größeren Platten eher XFS und LVM2 oder ZFS.
Gruß, Tobias Crefeld.
Am Dienstag, dem 01.10.2024 um 02:02 +0200 schrieb Tobias Crefeld:
On Mon, 30 Sep 2024 18:56:10 +0200 Volker Wysk <post@volker-wysk.de>
Könnte mir vorstellen, dass die Snapshots interessant sein könnten, wenn das System auf Hardware läuft, aber keine eigenen Erfahrungen,
Da haben wir etwas gemeinsam. ;-)
Ansonsten kann man eigentlich das meiste mit LVM2 und ext4 erschlagen. Nur bei großen FS kommt das Konzept an seine Grenzen,
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit.
Ich will Dir nicht von btrfs abraten, ist bestimmt interessant - insbesondere auf Hardware. Nur wenn Stabilität an erster Stelle steht, würde ich eher zu ext4 und LVM2 raten, wenn die Platten < 1 TB sind. Bei größeren Platten eher XFS und LVM2 oder ZFS.
Ich habe hier keine professionellen Anforderungen. Es ist nur für meinen persönlichen Desktop-PC und Laptop. Ich denke, ich versuche es mit Btrfs. Danke für die Infos. Volker
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit.
Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden. Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben. Gruss, Tobias.
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias, bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt... Grüße Norbert
Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher. ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern. Manfred
Am 03.10.24 17:56 schrieb Manfred Kreisl:
Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher.
ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern.
Manfred
Aha! Wieder was g'lernt ...
Am 03.10.24 um 17:56 schrieb Manfred Kreisl:
Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher.
ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern.
Manfred
Ich bin da nicht so sicher. Meines Erachtens liegt der Unterschied darin, ob man ein "Quick Format" macht oder ein "Full Format". Quick Format dauert für 5 oder 8 TB disks ein paar Sekunden, sicher nicht länger als 1 Minute. Alle meine x-TB-HD's habe ich mit Ext4 quick formatiert. Full Format dauert bei dieser Diskgrösse tagelang (~5 Std/TB). Wieder "meines Erachtens": der Unterschiede zwischen quick und full besteht nur darin, dass bei full die ganze Partition mit Nullen beschrieben (und, soviel ich weiss, auch noch geprüft) wird, was eben dauert. Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig). Ansonsten kenne ich keine Nachteile eines Ext-4 Quick-Formats. (Man korrigiere mich bitte, falls ich falsch liege. Ich arbeite aber seit Jahren - seit dem Verschwinden von Reiser-FS - intensiv mit viel neuen Dateien, Überschreiben, Verschieben, Löschen... aller denkbaren Grössen... auf verschlüsselten quick-formatierten Ext-4-Partitions) Gruss, Daniel -- Daniel Bauer photographer Basel Málaga Twitter: @Marsfotografo (often explicit nudes) https://www.patreon.com/danielbauer https://www.daniel-bauer.com (nudes)
Am 03.10.2024 um 20:24 schrieb Daniel Bauer:
Am 03.10.24 um 17:56 schrieb Manfred Kreisl:
Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher.
ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern.
Manfred
Ich bin da nicht so sicher.
Meines Erachtens liegt der Unterschied darin, ob man ein "Quick Format" macht oder ein "Full Format".
Quick Format dauert für 5 oder 8 TB disks ein paar Sekunden, sicher nicht länger als 1 Minute. Alle meine x-TB-HD's habe ich mit Ext4 quick formatiert.
Full Format dauert bei dieser Diskgrösse tagelang (~5 Std/TB).
Wieder "meines Erachtens": der Unterschiede zwischen quick und full besteht nur darin, dass bei full die ganze Partition mit Nullen beschrieben (und, soviel ich weiss, auch noch geprüft) wird, was eben dauert.
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Ansonsten kenne ich keine Nachteile eines Ext-4 Quick-Formats.
(Man korrigiere mich bitte, falls ich falsch liege. Ich arbeite aber seit Jahren - seit dem Verschwinden von Reiser-FS - intensiv mit viel neuen Dateien, Überschreiben, Verschieben, Löschen... aller denkbaren Grössen... auf verschlüsselten quick-formatierten Ext-4-Partitions)
Gruss,
Daniel
lesen bildet: lazy_itable_init[= <0 to disable, 1 to enable>] If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up filesystem initial‐ ization noticeably, but it requires the kernel to finish initializing the filesystem in the background when the filesystem is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing. lazy_journal_init[= <0 to disable, 1 to enable>] If enabled, the journal inode will not be fully zeroed out by mke2fs. This speeds up filesystem initialization noticeably, but carries some small risk if the system crashes before the journal has been overwritten entirely one time. If the option value is omitted, it defaults to 1 to enable lazy journal inode zeroing.
Moin, mal ein richtig guter Thread aber bei der ganzen Fragestellung 2 Anmerkungen: 1) Das Thema Dauer Ersteinrichtung kann man unter Windows auch beobachten, ne nachdem ob mal quick auswählt oder nicht. 2) Die Frage ausgereift oder nicht muss ergänzt werden um „habe ich Tools die eine Datenwiederherstellung bzw. Reparatur des Filesystems ermöglichen und. beherrsche ich diese. Gruß Von meinem iPad gesendet
Am 03.10.2024 um 23:30 schrieb Manfred Kreisl <ml4km@arcor.de>:
Am 03.10.2024 um 20:24 schrieb Daniel Bauer:
Am 03.10.24 um 17:56 schrieb Manfred Kreisl: Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher.
ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern.
Manfred
Ich bin da nicht so sicher.
Meines Erachtens liegt der Unterschied darin, ob man ein "Quick Format" macht oder ein "Full Format".
Quick Format dauert für 5 oder 8 TB disks ein paar Sekunden, sicher nicht länger als 1 Minute. Alle meine x-TB-HD's habe ich mit Ext4 quick formatiert.
Full Format dauert bei dieser Diskgrösse tagelang (~5 Std/TB).
Wieder "meines Erachtens": der Unterschiede zwischen quick und full besteht nur darin, dass bei full die ganze Partition mit Nullen beschrieben (und, soviel ich weiss, auch noch geprüft) wird, was eben dauert.
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Ansonsten kenne ich keine Nachteile eines Ext-4 Quick-Formats.
(Man korrigiere mich bitte, falls ich falsch liege. Ich arbeite aber seit Jahren - seit dem Verschwinden von Reiser-FS - intensiv mit viel neuen Dateien, Überschreiben, Verschieben, Löschen... aller denkbaren Grössen... auf verschlüsselten quick-formatierten Ext-4-Partitions)
Gruss,
Daniel
lesen bildet:
lazy_itable_init[= <0 to disable, 1 to enable>] If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up filesystem initial‐ ization noticeably, but it requires the kernel to finish initializing the filesystem in the background when the filesystem is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.
lazy_journal_init[= <0 to disable, 1 to enable>] If enabled, the journal inode will not be fully zeroed out by mke2fs. This speeds up filesystem initialization noticeably, but carries some small risk if the system crashes before the journal has been overwritten entirely one time. If the option value is omitted, it defaults to 1 to enable lazy journal inode zeroing.
Am Donnerstag, dem 03.10.2024 um 20:24 +0200 schrieb Daniel Bauer:
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Das gilt für Festplatten. Wie es bei SSDs ist, weiß ich nicht. Du meinst dieses Verfahren, bei dem Teile der Platte vielfach überschrieben werden. Ich habe auch vergessen, wie es heißt. Für große Festplatten ist es nicht praktikabel, alles zu überschreiben. Es würde viel zu lange dauern. Wenn man die Daten später wieder los werden will, dann ist von Anfang an eine Verschlüsselung nötig. Dann kann später der LUKS-Vorspann mit dem genannten Verfahren unlesbar gemacht werden. In ihm ist der (oder die) Schlüssel für die Platte abgelegt. Dieser Schlüssel ist wiederum mit dem Paßwort verschlüsselt. Tschüß, Volker
Am 04.10.24 um 10:29 AM schrieb Volker Wysk:
Am Donnerstag, dem 03.10.2024 um 20:24 +0200 schrieb Daniel Bauer:
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Das gilt für Festplatten. Wie es bei SSDs ist, weiß ich nicht. Du meinst dieses Verfahren, bei dem Teile der Platte vielfach überschrieben werden. Ich habe auch vergessen, wie es heißt. Für große Festplatten ist es nicht praktikabel, alles zu überschreiben. Es würde viel zu lange dauern.
Es funktioniert halt auch nur in Grenzen. Zum einen werden Datenblöcke bei Fehlverhalten durch Reserveblöcke ersetzt, die dort verbleibenden Daten erreicht man dann mit Tools wie shred nicht mehr. Zum anderen ist bei SSD heutzutage keine fixe Zuordnung von Blocknummern zu phys. Blöcken mehr gegeben, von OS Seite besteht also schlicht nicht mehr die Möglichkeit, wirklich alle Blöcke zu überschreiben. Man kann hier zum einen die in der Platte integrierte Funktion als Alternative nehmen (Secure- Erase) oder halt - wie Du ja schon geschrieben hast - von Anfang an auf Verschüsselung setzen. Viele Grüße Ulf
Am 04.10.24 um 10:29 schrieb Volker Wysk:
Am Donnerstag, dem 03.10.2024 um 20:24 +0200 schrieb Daniel Bauer:
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Das gilt für Festplatten. Wie es bei SSDs ist, weiß ich nicht. Du meinst dieses Verfahren, bei dem Teile der Platte vielfach überschrieben werden. Ich habe auch vergessen, wie es heißt. Für große Festplatten ist es nicht praktikabel, alles zu überschreiben. Es würde viel zu lange dauern.
Bei SSDs wird m.W. ein Teil der Speicherzellen per Firmware als Reparaturreserve zum Austausch freigehalten, bei solchen ausgetauschten Zellen könnte man später mit geeigneten Werkzeugen Daten evtl. auslesen, peinlich die Daten vertrauliche bleiben sollen.
Wenn man die Daten später wieder los werden will, dann ist von Anfang an eine Verschlüsselung nötig. Dann kann später der LUKS-Vorspann mit dem genannten Verfahren unlesbar gemacht werden. In ihm ist der (oder die) Schlüssel für die Platte abgelegt. Dieser Schlüssel ist wiederum mit dem Paßwort verschlüsselt.
So ist es. Gruß Peter
Am 03.10.24 20:24 schrieb Daniel Bauer:
Am 03.10.24 um 17:56 schrieb Manfred Kreisl:
Am 03.10.2024 um 12:31 schrieb Norbert Zawodsky:
Am 03.10.24 12:20 schrieb Tobias Crefeld:
On Tue, 01 Oct 2024 13:36:39 +0200 Volker Wysk <post@volker-wysk.de> wrote:
"Groß" sind in meinem Fall 5 TB. Aber scheints bin ich da nicht auf dem Stand der Zeit. Also ein Filesystem mit 5 TB ist auf alle Fälle gross. Das Anlegen des Filesystems würde mit ext4fs ewig dauern. Mit btrfs, XFS oder ZFS geht das mehr oder minder in wenigen Sekunden.
Außerdem haben zumindest btrfs und ZFS "scrubbing"-Mechanismen. Damit lassen sich Festplattenfehler beheben.
Gruss, Tobias.
Hallo Tobias,
bist Du sicher? Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Grüße Norbert
Er IST sich definitiv sicher.
ext4 mogelt per default beim Anlegen des Filesystems. Es wird so getan als wenn's komplett ist macht aber heimlich still und leise im Hintergrund weiter. Und das kann bei fetten Platten in der Tat Ewigkeiten dauern.
Manfred
Ich bin da nicht so sicher.
Meines Erachtens liegt der Unterschied darin, ob man ein "Quick Format" macht oder ein "Full Format".
Quick Format dauert für 5 oder 8 TB disks ein paar Sekunden, sicher nicht länger als 1 Minute. Alle meine x-TB-HD's habe ich mit Ext4 quick formatiert.
Full Format dauert bei dieser Diskgrösse tagelang (~5 Std/TB).
Wieder "meines Erachtens": der Unterschiede zwischen quick und full besteht nur darin, dass bei full die ganze Partition mit Nullen beschrieben (und, soviel ich weiss, auch noch geprüft) wird, was eben dauert.
Quick hingegen schreibt nur die Dateisystem-Information an den Anfang. Eventuell vor der Formatierung enthaltene Daten werden daher nicht überschrieben, was aber an sich egal ist, ausser man muss sie wirklich auch kriminologisch unlesbar loswerden. Aber dann müsste man sie sowieso mehrfach mit Zufallsinhalten überschreiben und die anderen Datei-System-Formatierungen tun das auch nicht (oder sie dauerten eben auch ewig).
Ansonsten kenne ich keine Nachteile eines Ext-4 Quick-Formats.
(Man korrigiere mich bitte, falls ich falsch liege. Ich arbeite aber seit Jahren - seit dem Verschwinden von Reiser-FS - intensiv mit viel neuen Dateien, Überschreiben, Verschieben, Löschen... aller denkbaren Grössen... auf verschlüsselten quick-formatierten Ext-4-Partitions)
Gruss,
Daniel
Bei mir sind alle HDs mit ext4 formatiert. Auch die großen LVs mit 40 TB. Nie ein Problem gehabt.. Und snapshots hab ich bis jetzt noch nie gebraucht
On Thu, 3 Oct 2024 12:31:14 +0200 Norbert Zawodsky <norbert@zawodsky.at> wrote:
Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Also ich gehe davon aus, dass das zu formatierende Volume (Blockdevice / LV / Partition) auch um die 8 TB groß war. War auch mehr aus dem Kopf und ich müsste es mal wieder ausprobieren, um die tatsächliche Zeit zu ermitteln, aber mehrere Minuten waren es mindestens. Vielleicht gibt es auch Unterschiede zwischen HDD und SSD - mit großen Volumes auf SSD und ext4fs habe ich keine Erfahrung. Du hattest schon mit journalling formatiert und das Journal auf demselben Volume abgelegt und im Modus data=ordered betrieben? Gruß, Tobias.
Am 04.10.24 um 9:17 PM schrieb Tobias Crefeld:
On Thu, 3 Oct 2024 12:31:14 +0200 Norbert Zawodsky <norbert@zawodsky.at> wrote:
Ich kann mich zwar nicht genau erinnern, ist schon länger her, aber als ich das letzte mal eine 8 TB HD in ein bestehendes system dazu gehängt habe, hat das anlegen des ext4 filesystems sicher nicht "ewig" gedauert. Vielleicht 30 Sekunden? Wenn überhaupt...
Also ich gehe davon aus, dass das zu formatierende Volume (Blockdevice / LV / Partition) auch um die 8 TB groß war.
War auch mehr aus dem Kopf und ich müsste es mal wieder ausprobieren, um die tatsächliche Zeit zu ermitteln, aber mehrere Minuten waren es mindestens. Vielleicht gibt es auch Unterschiede zwischen HDD und SSD - mit großen Volumes auf SSD und ext4fs habe ich keine Erfahrung.
Du hattest schon mit journalling formatiert und das Journal auf demselben Volume abgelegt und im Modus data=ordered betrieben?
Wie im Thread schon angesprochen wird das erreicht, indem das mkfs bei ext4 im Hintergrund weiterläuft. Was dann je nach Größe und Geschwindigkeit durchaus mehrere Tage dauern kann. Das Sitchwort zum Nachlesen ist hier lazyinit. Viele GRüße Ulf Volmer
Am Mo., 30. Sept. 2024 um 18:56 Uhr schrieb Volker Wysk <post@volker-wysk.de>:
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Löblich.
Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge?
Das ist bei openSUSE seit 42.1 der Default, also seit 2015. Dürfte also inzwischen gut abgehangen sein. Und hier gab's in den letzten Jahren auch keine Berichte von Katastrophen. Gruß Martin
Am 1. Oktober 2024 14:50:35 MESZ schrieb "Martin Schröder" <martin@oneiros.de>:
Am Mo., 30. Sept. 2024 um 18:56 Uhr schrieb Volker Wysk <post@volker-wysk.de>:
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Löblich.
Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge?
Das ist bei openSUSE seit 42.1 der Default, also seit 2015. Dürfte also inzwischen gut abgehangen sein. Und hier gab's in den letzten Jahren auch keine Berichte von Katastrophen.
Eigentlich läuft es. Aber wie schon ein anderer schrieb, nerven die Aufräumarbeiten. Da stockt es dann etwas. Geht bis zu kurzeitigen Maus- und Tastaturaussetzer. Gruß Eric
Am Dienstag, dem 01.10.2024 um 14:50 +0200 schrieb Martin Schröder:
Am Mo., 30. Sept. 2024 um 18:56 Uhr schrieb Volker Wysk <post@volker-wysk.de>:
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Löblich.
Wie sieht es heute aus? Kennt jemand eine gute Seite mit dem aktuellen Stand der Dinge?
Das ist bei openSUSE seit 42.1 der Default, also seit 2015. Dürfte also inzwischen gut abgehangen sein.
Ja, das denke ich mir auch. Ich war nur verunsichert wegen den Problemen, die in diesem Wikipediaartikel genannt werden. Der ist wohl veraltet. Tschüß Volker
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen. ...
Noch etwas. Tumbleweed als Rolling Release zieht ziemlich oft zum Teil erhebliche Updates, gelegentlich sind das GB. Eine Alternative ist Slowroll, ein gemächliches Rolling Release, so einmal im Monat kommt die Masse, Sicherheitsrelevantes sobald notwendig. https://de.opensuse.org/openSUSE:Slowroll Ich ziehe jedoch für meinen Desktoprechner Leap vor, gekrönt mit den zwei, drei Programmen von denen ich gerne die neuste Version hätte. Bekommt man aus Zusatzrepositories oder auch über Flatpak. Gruß Peter
Am Dienstag, dem 01.10.2024 um 20:30 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen. ...
Noch etwas. Tumbleweed als Rolling Release zieht ziemlich oft zum Teil erhebliche Updates, gelegentlich sind das GB.
Eine Alternative ist Slowroll, ein gemächliches Rolling Release, so einmal im Monat kommt die Masse, Sicherheitsrelevantes sobald notwendig.
Danke für die Information! Das sieht gut aus. Und man kann ja einfach von Tumbleweed zu Slowroll wechseln, indem man die Paketquellen austauscht.
Ich ziehe jedoch für meinen Desktoprechner Leap vor, gekrönt mit den zwei, drei Programmen von denen ich gerne die neuste Version hätte. Bekommt man aus Zusatzrepositories oder auch über Flatpak.
Sind diese Zusatzrepositories sowas wie die PPAs (Personal Package Archvies) unter Ubuntu..? Vielleicht sollte ich auch das meiste belassen und nur bestimmte Programmpakete regelmäßig erneuern, wenn das geht. Z.B. Gnome und PHP. Ich muß noch mehr überlegen und recherchieren. Tschüß dann, Volker
Am 02.10.24 um 18:22 schrieb Volker Wysk:
Am Dienstag, dem 01.10.2024 um 20:30 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen. ...
Noch etwas. Tumbleweed als Rolling Release zieht ziemlich oft zum Teil erhebliche Updates, gelegentlich sind das GB.
Eine Alternative ist Slowroll, ein gemächliches Rolling Release, so einmal im Monat kommt die Masse, Sicherheitsrelevantes sobald notwendig.
Danke für die Information! Das sieht gut aus. Und man kann ja einfach von Tumbleweed zu Slowroll wechseln, indem man die Paketquellen austauscht.
Ich ziehe jedoch für meinen Desktoprechner Leap vor, gekrönt mit den zwei, drei Programmen von denen ich gerne die neuste Version hätte. Bekommt man aus Zusatzrepositories oder auch über Flatpak.
Sind diese Zusatzrepositories sowas wie die PPAs (Personal Package Archvies) unter Ubuntu..?
Ja, siehe z.B.: https://software.opensuse.org/ Beispiel Suche: Thunderbird Da gibt es für die verschieden Suse Varianten die default Version und unter "Community Pakete anzeigen" aktuellere oder auch älterer Versionen. Allerdings empfiehlt sich m.E.nur dann eine neue Variante, wenn man einen Grund dafür hat. Die Leute die die Distribution zusammen stellen, testen ihre Kombinationen, änderst du etwas am der Programmzusammenstellung wirst du der Tester. Man kann sich sein System ziemlich verhunzen, wenn man der Versionitis verfällt. Allerdings kann "Rollback" vieles retten.
Vielleicht sollte ich auch das meiste belassen und nur bestimmte Programmpakete regelmäßig erneuern, wenn das geht. Z.B. Gnome und PHP.
Gnome(!) Wer basteln will nimmt KDE;-) Viel Spaß. Gruß Peter
Am Mittwoch, dem 02.10.2024 um 21:46 +0200 schrieb Peter McD:
Am 02.10.24 um 18:22 schrieb Volker Wysk:
Am Dienstag, dem 01.10.2024 um 20:30 +0200 schrieb Peter McD:
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen. ...
Noch etwas. Tumbleweed als Rolling Release zieht ziemlich oft zum Teil erhebliche Updates, gelegentlich sind das GB.
Eine Alternative ist Slowroll, ein gemächliches Rolling Release, so einmal im Monat kommt die Masse, Sicherheitsrelevantes sobald notwendig.
Danke für die Information! Das sieht gut aus. Und man kann ja einfach von Tumbleweed zu Slowroll wechseln, indem man die Paketquellen austauscht.
Ich ziehe jedoch für meinen Desktoprechner Leap vor, gekrönt mit den zwei, drei Programmen von denen ich gerne die neuste Version hätte. Bekommt man aus Zusatzrepositories oder auch über Flatpak.
Sind diese Zusatzrepositories sowas wie die PPAs (Personal Package Archvies) unter Ubuntu..?
Ja, siehe z.B.: https://software.opensuse.org/
Beispiel Suche: Thunderbird Da gibt es für die verschieden Suse Varianten die default Version und unter "Community Pakete anzeigen" aktuellere oder auch älterer Versionen.
Da gibt es kein "Community Pakete anzeigen"... Bei dem Zahnrad bekomme ich nur Entwicklungspakete anzeigen / Sprachpakete anzeigen / Debug-Pakete anzeigen.
Allerdings empfiehlt sich m.E.nur dann eine neue Variante, wenn man einen Grund dafür hat.
Ja, volle Zustimmung.
Die Leute die die Distribution zusammen stellen, testen ihre Kombinationen, änderst du etwas am der Programmzusammenstellung wirst du der Tester.
Man kann sich sein System ziemlich verhunzen, wenn man der Versionitis verfällt.
Allerdings kann "Rollback" vieles retten.
Vielleicht sollte ich auch das meiste belassen und nur bestimmte Programmpakete regelmäßig erneuern, wenn das geht. Z.B. Gnome und PHP.
Gnome(!) Wer basteln will nimmt KDE;-)
Ich habe KDE verwendet, bis vor ungefähr 6 Jahren. Es gab die ganze Zeit Probleme mit Akonadi und deswegen mit KMail. Ich weiß die Einzelheiten nicht mehr, aber als es mir dann *wieder* die Installation zerschossen hat, sagte ich mir "Jetzt reicht's". Ich bin dann zu Gnome gewechselt. Tschüß Volker
On Wed, 2 Oct 2024 21:46:11 +0200 Peter McD <peter.posts@gmx.net> wrote:
Gnome(!) Wer basteln will nimmt KDE;-)
Auf "richtigen" Desktop-Systemen, also welche, auf denen nicht nur ein GUI nötig ist, weil die Serveranwendung das braucht, die aber nicht als Arbeitsplatzrechner dienen, verwende ich nur KDE. Ist vielleicht auch Gewohnheit, aber irgendwie habe ich GNOME nie wirklich kapiert und unter KDE gibt es etliche Tools, die ich teilweise seit Langem gewohnt bin. Stabil läuft KDE hier sowohl auf Desktop-PCs als auch auf Laptops. Andererseits sind ein paar gtk+-Applikationen, die ich gerne verwendet habe, nicht an GNOME gebunden, laufen also auch unter KDE. Allerdings nicht mit SUSE drunter, wobei ich nicht behaupten will, dass da ein Zusammenhang besteht. Gruß, Tobias.
Am 06.10.24 um 18:38 schrieb Tobias Crefeld:
On Wed, 2 Oct 2024 21:46:11 +0200 Peter McD <peter.posts@gmx.net> wrote:
Gnome(!) Wer basteln will nimmt KDE;-)
Auf "richtigen" Desktop-Systemen, also welche, auf denen nicht nur ein GUI nötig ist, weil die Serveranwendung das braucht, die aber nicht als Arbeitsplatzrechner dienen, verwende ich nur KDE.
Ist vielleicht auch Gewohnheit, aber irgendwie habe ich GNOME nie wirklich kapiert und unter KDE gibt es etliche Tools, die ich teilweise seit Langem gewohnt bin. Stabil läuft KDE hier sowohl auf Desktop-PCs als auch auf Laptops. Andererseits sind ein paar gtk+-Applikationen, die ich gerne verwendet habe, nicht an GNOME gebunden, laufen also auch unter KDE.
Vermutlich gibt es die üblichen Tools sowohl unter KDE als auch unter Gnome und verwenden könnte ich beide GUIs. XFCE habe ich auch schon probiert. Allerdings ist meine KDE-Killerkpplikation der komplett unwichtige Plasma Medienrahmen, davon habe ich drei auf dem Desktop, darin laufen im Hintergrund drei Diashows mit meinen zahlreichen Fotos, besser als jedes Fotoalbum. Zudem kann man sich mit dem Einstellmöglichkeiten von KDE tagelang von der Arbeit ablenken lassen, dagegen kann Gnome nicht anstinken;-) Gruß Peter
Am 30.09.24 um 18:56 schrieb Volker Wysk:
Hallo!
Ich bin (bis jetzt) ein Ubuntu-Benutzer und überlege, auf OpenSUSE Tumbleweed umzusteigen.
Ich habe Teile der deutschen und englischen Wikipedia über Btrfs gelesen. Es klingt phantastisch. Doch - besonders in der deutschen Wikipedia - wird der Eindruck erweckt, daß Btrfs noch nicht stabil und ausgereift ist. Siehe hier, unter "Kritik am Design":
Ich verwende btrfs seitdem es in Opensuse als default für die root-Partition eingesetzt wird. Allerdings läuft bei mir Opensuse nur auf Desktop-Systemen. in den ersten Jahren gab es durchaus einige Hakelein aber seit vielen Jahren habe ich damit keinerlei Probleme. Genial für mich ist Snapper - ich kann mir mein System bis zur absoluten Unbenutzbarkei verbasteln. Ein einfaches snapper rollback rettet mich. Um es mal so zu sagen: Ein Leben ohne Snapper ist möglich aber sehr mühsam. Wolfgang
participants (11)
-
Daniel Bauer -
Eric Schirra -
Manfred Kreisl -
Martin Schröder -
Norbert Zawodsky -
Peter McD -
Ralf Prengel -
Tobias Crefeld -
Ulf Volmer -
Volker Wysk -
Wolfgang Geisendörfer