Beiträge von MustermannE

Zitat von Berichtigung

Und nochmal: Deine Software ist zu alt.
Daraus zu folgern, dass openSUSE einen Bug habe,
ist ähnlich sinnvoll, wie Mercedes anzuklagen, weil es beim Automatik Getriebe keinen Ganghebel gibt,
wo doch der eigene Ford Model T einen hat.

Nett, dass ihr mich auf meinen eigenen Bugreport aufmerksam macht ...
Und zu alt ist eine eigenwillige Interpretation, ich sehe das anders.

Einen Bug hatte ich doch nicht unterstellt, aber meine Vermutung, dass sich ab Leap 15 etwas änderte, hat sich doch vollumfänglich bestätigt:

Ab Leap 15 wird ein ext4-fs vom Yast-Partinioner stets als 64-Bit-System angelegt.
Bis Leap 42.3 geschah das nur, wenn es auch erforderlich war:

/etc/mke2fs.conf in der ext4 subsection steht bei Leap 42.3 noch
auto_64-bit_support = 1

In Leap 15 steht da etwas mit ...,64bBit,...
Das kann man mit ...,^64Bit,... abschalten. Das habe ich mal gemacht und den Yast-Partinioner erneut bemüht.
Und es funktioniert, prompt hat Paragon-FM15 das Problem nicht mehr. Prompt ist meine Software nicht mehr zu alt.

Und - btw - laut manpages zu mke2fs.conf kann man auch da mit # etwas auskommentieren ...

Hier einfach "mit deine Software ist zu alt" alles abzubügeln, finde ich weder hilfreich, noch angemessen.
So wie Felix Miata geholfen hat, so ist es hilfreich gewesen.
Und - btw - ich fahre einen Mercedes mit Automatik-Getriebe und da hat es sogar mehrere Ganghebel drei um genau zu sein und die sind alle am Lenkrad.

Die Vorgehensweise bis Leap 42.3 erscheint mir sinnvoller, wann sollte denn ein /-System in 64-Bit-Ausprägung je nötig sein oder Vorteile bringen?
Wo sollen da je soviele Blöcke erforderlich werden?
Zu unseren Lebzeiten wohl kaum. Für spezielle Datensysteme kann das zutreffen.
Felix Miata sieht das ebenso: "For compatibility reasons, I have no / partitions using the 64bit option, and few others."

Ich werde aber Paragon sicherheitshalber auf den Umstand 32-Bit/64-Bit bei ext4 hinweisen. Vielleicht bewirkt das ja etwas.
Den Thread setze ich auf erledigt.

Zitat von Sauerland

Dann mach bei Paragon nen Bugreport auf.

Ich denke aber, das Problem liegt bei openSUSE, nicht bei Paragon. Soeben habe ich GParted (0.31.0-lp150.1.2) aus dem Leap-Repository installiert und damit ein ext4-fs erzeugt. Und siehe da, das wird vom Paragon-Tool auch richtig erkannt. Zustand, Füllungsgrad, Partitionsgrenzen, alles i. O.

Das Problem taucht ausschließlich im Umgang mit dem Leap15-Partitionierer auf. Da ist m. E. openSUSE als erster Ansprechpartner zuständig.

Zitat von Berichtigung

Ich hatte schon mehrfach geschrieben: Ist deine Wahl.
Dass ich den gnadenlosen Geschwindigkeitsvorteil weder glaube, noch für nötig halte, sei mir aber bitte doch auch unbenommen.

Außerdem würde ich einer Backup/ISO - Restore Lösung, die keine normale Linux- Formatierung erkennt, niemals trauen.
Für den Ernstfall schon gar nicht.

Etwas nicht für nötig halten, ist eine Sache. Einem nicht zu glauben eine andere. Ich bin gerne bereit, es live zu demonstrieren ... eine Flasche Wein ist immer im Keller ... Den Ernstfall habe ich mehrfach erprobt und überwunden.

Und bis vor 2 Wochen unter Leap 42.3 gab es dieses Problem nicht. Und bei allen anderen Vorgänger-Versionen bis zur 13.2 garantiert auch nicht. Es ist erst mit Leap 15 aufgetaucht. Mit dem 4.12er Kernel und bevor das jüngst in den Medien beschrieben ext4-Problem diskutiert wurde (ich habe eine Weile Leap 15 und Leap 42.3 parallel vorgrhalten). Mit den Patches dazu kann es also auch nicht zu tun haben.

Ich gehe inzwischen davon aus, dass irgendein Verwaltungsbit/Statusbyte/bisher unbenutztes Bit/Byte einen Zustand bekommen hat, den es so bislang nicht gab oder so nicht benutzt wurde und deshalb zu einer falschen Interpretation führt. Sogar diesen Zustand kann ich sichern, ich muss in den Einstellungen dann vorgeben, jeden Sektor ins Image aufzunehmen. Ja, habe ich ausprobiert, klappt. Auch der Restore klappt. Dauert dann halt 5-6 Minuten.

Am 3.7-Kernel des Bootsticks liegt es auch nicht, das habe ich inzwischen herausgefunden, in dem ich dafür den aktuellen 4.19er der openSUSE unterjubelte, was zu meiner Verblüffung sogar ganz gut klappte. Auch dann wird ein ext4-FS des Leap-15-Partionierer als unformatiert angesehen.

Zitat von Berichtigung

Ich weiß nicht, was du da machst, aber 1,5 Minuten um eine ganze Partition zu klonen?
Mag möglich sein, wenn die nicht größer als ein paar MB ist.

Das ist kein klonen. es werden nur die belegten Sektoren im Imagefile hinterlegt. TrueImage, Paragon und alle anderen Anbieter von Idiesen Backup&Restore-Tools machen dasselbe.

def -h
liefert u. a. das hier:
/dev/sda2 59G 11G 46G 19% /

Das ist schon etwas mehr als ein paar MB. Quell- und Zielmedium sind zwei SSD.
Und was die Ausführungs-Zeiten in beiden Richtungen angeht: btdtgt
Ich kann nicht nachvollziehen, wieso meine Angaben hier derart angezweifelt werden, ich habe mir die nicht ausgedacht!

Und da ich - wie beschrieben - damit offline sichere, ist da kein Hintergrund, in dem etwas läuft. Insofern ist Schnelligkeit durchaus ein Thema. Dafür kann ich einen Systemstand aber auch blitzschnell restaurieren. Ganz ohne überhaupt ein System zu haben, dass ich booten muss. Wie restaurierst du ein System, das irgendwie online gesichert wurde, das sich aber nicht mehr booten lässt? Dann musst du ein anderes System (ein Live-System?) booten und das Dateisystem wieder neu aufbauen. Sicher, kann man machen.

Aber ein Image zu laden geht deutlich fixer, besonders, wenn an mal etwas ausprobieren will und das evtl. mehrmal tun muss. Und ich kann so ein Image-Archiv einfach zusätzlich auf externe Datenträger vervielfältigen (wo ich eine Kopie von /home habe), die ich bequem auswärts aufbewahren kann, z. N. im Bankschließfach oder der Zweitwohnung. Damit bin ich auch für den worst case ziemlich gut vorbereitet.

In alten Windows-Tagen habe ich auch die Datenlaufwerke stets so in Images gesichert, da geht das ohnehin schon immer online und im Hintergrund. Seitdem ich so verfahre (15 Jahre?), hatte ich nie einen Datenverlust zu beklagen. Bei rdiff-backup hingegen kommt es gelegentlich schon zu Unpässlichkeiten, vielleicht weil der Rechner ausfiel während eines Sicherungslaufes. Darum mache ich das alle 20 Minuten auf je einer anderen Platte nebenbei. Hin und wieder zur Sicherheit als Image wieder offline mit dem FM15. Das läuft dann für

/dev/sdc1 443G 229G 214G 52% /home

in ca. 20 Minuten durch, da ist das Ziel dann keine SSD. Das Ergebnis davon könnte auch inkrementell ergänzt werden, aber das praktiziere ich derzeit nicht.

Nun, ganz so ist es nicht.

Ich halte schon Ausschau nach einer vergleichbaren Linux-Lösung, habe aber bislang nichts wirklich Gleichwertiges/Funktionierendes gefunden. Auch unterscheide ich zwischen Systemsicherung/-wiederherstellung und der Datensicherung. /home sichere ich zyklisch online mittels rdiff-backup auf unterschiedlichen Medien. Den Rest halt mit diesem Tool und der Sicherungsvorgang braucht knapp 1,5 Minuten. Diese Zeit brauche ich bei Clonezilla allein für die Vorgabe, was zu tun ist ... Ein Restore ist ebenso schnell.

Ich sichere das System oft, immer wenn sich etwas ändert. Mit dieser Strategie habe ich bisher jede Situation bewältigen können, die mich das System nicht mehr booten oder sinnvoll bedienen ließ. Sowas war zwar selten in den letzten Jahren, hat mir dann aber komfortabel den Hintern gerettet.

Evtl. kämen noch snapshots in Frage, aber dafür müsste ich zu btrfs wechseln und das möchte ich eigentlich nicht tun. Die jetzige Lösung ist schnell und ressourcenschonend und ich weiß bei jedem gesicherten Stand genau, was ich da habe.

fsck.ext4 ist ohne Fehler durchgelaufen. Bei Interesse poste ich das Ergebnis morgen.

Ich habe mal in das Binary des USB-Sticks reingeschaut, da finde ich einen Stempel 3.7.1-1.1-default. Das ist schon ein gewisser Abstand zum 4.19.12 ...

Ich hab mal
sudo fsck.ext4 -v -f -c /dev/sdX1
auf eine Partition losgelassen, das wird wohl etwas dauern, ist nun bei 8%, bisher ohne Meldung.

Nach meiner laienhaften Vorstellung müssten die Neuerungen des ext4 im lfdn. Betrieb Wirkung haben, aber nicht bei der Formatierung. Sehe ich das richtig? Oder haben die Weiterentwicklungen des ext4 nur dann Wirkung, wenn eine Partition auch mit dem neuesten Kernel formatiert wurde?

1. FM15 = Paragon Festplatten Manager 15
2. Fomatiert wurde stets mit dem Partitionierer im Yast, sowohl unter 42.3 als unter 15. Formatiere ich mit FM15, läuft auch unter Leap 15 augenscheinlich alles normal.

1. Das ist ein USB-Stick oder auch CD, davon wird dann ein Linux-System gebootet.

2. Wenn damit der jüngste ext4-Fall "Datenkorruption" gemeint ist, dieser Effekt trat schon davor auf.

3. Neuere Versionen von Paragon will ich nicht nutzen, die sind zu sehr auf Windows-Einsatz zugeschnitten. Ich habe da auch keine kostenpflichtige Version im Einsatz, sondern eine Gratisausgabe. Die Linux-Tools, die ich bisher ausprobierte (z. B. Clonezilla) sind eine ganze Größenordnung langsamer und nicht annähernd so komfortabel bedienbar. Ein Tool von Veeam habe ich vergeblich ausprobiert, das habe ich nicht zur Arbeit bewegen können.