[gelöst, wir nehmen tar.gz] pxz Multicore xz Binary bitte ins OE 2.2 einbinden

  • Nachdem ich das Sichern des Images in ein tar.xz getestet habe und es mit den standard xz utils > 15 min dauert ein tar.xz zu generieren weil nur ein core für die Komprimierung benutzt wird würde ich bitten das pxz ins OE 2.2 einzubinden.


    Ist zwar immer noch nur ein Alpha kit, nutzt aber alle 4 cores aus und ermöglich damit ein Sichern in 6 Minten was vergleichbar zum Sichern von aktuellen OE 2.2 Images auff der Dreambox selbst ist.


    https://jnovy.fedorapeople.org/pxz/


    Wen es wer vorher testen will bei OoZooN habe ich ein Q&D Debian Paket dafür mit einen selbstcompilierten gepostet.


    Hier im Board kann man *.deb Files leider noch niicht anhängen.


    LG
    gutemine

    2 Mal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Der Box ist es grundsätzlich egal, ob und wie der Tarball komprimiert ist. Mein Vorschlag wäre deshalb, den Tarball auf der Box entweder unkomprimiert oder mit gzip komprimiert zu erzeugen. Zurückflashen kann man alles (auch bzip2, aber das ist auch langsam). 6 Minuten sind immernoch ziemlich viel. Könntest Du mal ausprobieren, wie lange die beiden Varianten brauchen? Für gzip gibt es übrigens auch eine parallelisierte Implementierung. Bei Kompressoren erzielen die parallelisierten Varianten allerdings nicht immer dasselbe Ergebnis, insofern muss man ggf. schauen, dass es nicht inkompatibel mit Busybox wird.

  • Das xz schafft unter Verwendung potenter Desktop / Server-Prozessoren kaum eine erfreuliche Geschwindigkeit des Komprimierens.
    Die Parallelisierung verbessert das zwar, aber Begeisterung kommt nicht auf.
    Das xz macht Sinn für einmal Kompromieren, mehrfach Entpacken Szenarien, oder aber Reduktion der Größe um jeden Preis.
    Die paar MByte gesparter Platz machen zwar einen Techniker gücklicher, aber den Anwender intressieren eher die Zeiten.


    Die parallel-Variante von xz würde ich auf einer Settop Box vermeiden.
    Eine 100% Auslastung aller CPU cores kann Seiteneffekte mit sich bringen.


    Ich möchte hier eher den klassischen gzip empfehlen.

  • Ich habe auch Aufnahmen während der Sicherung ausprobiert, das war auch kein Problem da fast alles im memory gemacht wird.


    Das reine tar file ist in wenigen Sekunden fertig, und ja das gzip ist auch noch recht flott. Mir ist schon klar dass xz seine Zeit braucht, aber nachdem Ihr auch die Daten in den deb files teilweise als tar.xz habt macht auch dafür das pxz durchaus Sinn.


    In der finalen Version vom dBackup wird man sich eh aussuchen können wie man sichert, aber erstens war es ein netter Test wie flott die box wirklich ist und zweitens gilt hier auch das selbe Argument wie beim nfi - wenn es das default image format ist dan wollen es die Leute auch haben :grinning_squinting_face:


    Vor allem sind die 6min auch für ein > 100MB großes file, weil auch sachen wie die EPG Datenbank mitgesichert werden und damit das image sich aufbläht. Für ein 55MB großes Image wie das aus dem OE2.2 würde das pxz < 3 min brauchen.


    Nicht umsonst habe ich mir das pxz selber compiliert und damit erstmal ein standard image auf die Hardddisk aus und wieder eingepackt, das ist bereits viel schneller als das was dBackup derzeit mit den 6 Minuten macht.


    Und letztendlich kann man dem xz auch sagen ob was und wie stark es komprimieren kann. Daher wäre es trotzdem nett wenn es im OE 2.2 verfügbar wäre - Bitte Bitte


    Das Makefile ist auch so simpel das es kaum Arbeit machen sollte draus ein bb zu machen. Im Debian auf der box selber hat ein simple make ohne Anpsassungen gereicht um das binary zu compilieren, da es nicht mal ein configure hat.

    Einmal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Mir ist schon klar dass xz seine Zeit braucht, aber nachdem Ihr auch die Daten in den deb files teilweise als tar.xz habt macht auch dafür das pxz durchaus Sinn.

    Hier liegt der Denkfehler: Die deb-Pakete werden auf der Box nur dekomprimiert. Dekomprimieren ist bei xz (relativ) schnell, während die Komprimierung richtig lahm ist.

    zweitens gilt hier auch das selbe Argument wie beim nfi - wenn es das default image format ist dan wollen es die Leute auch haben

    Hiermit erkläre ich .tar.gz höchst offiziell zum Default-Backup-Image-Format, das vom Rescue-Image in einer zukünftigen Version erzeugt werden wird.


    Ich sehe derzeit keinen Sinn darin, pxz in opendreambox einzubauen. Wenn Du es trotzdem unbedingt dort haben möchtest, kannst Du einen Patch mit einem sauberen Recipe an die OpenEmbedded-Mailingliste schicken. Sobald Dein Patch dort übernommen wurde, werde ich ihn ebenfalls in unsere Version übernehmen. Vorher nicht.

  • Wenn es jetzt das default backup format ist dann ist mir das natürlich Befehl !!!


    Und ja ich weis das xz beim dekomprimieren relativ schnell ist (sofern man genug memory hat - da habe ich auf den alten Boxen oft gelitten bei den höheren Compression Leveln)


    Es soll aber auch Leute geben die *.deb Pakete auf der Box bauen ...aber da tut ein tar.gz auch genauso.


    Gut das wir das geklärt haben - ich mache als tar.gz als Default und nur wenn wer ein xz oder pxz installiert hat das er sich einbildet. dann wird das optional verwendet :grinning_squinting_face:


    EDIT: Ich habe das dBackup auf tar.gz angepasst und getestet, das image ist dann etwa 20% großer und ein tar -czf braucht dann aber auch rund 6 Minuten weil nur ein core zum komprimieren verwendet wird, womit wir auch hier wohl um das pigz das mehrere Cores benutzen kann nicht herum kommen werden, dann sollten aber <2min möglich sein zum sichern.


    EDIT: habe schnell das aktuelle pigz compiliert und bei OoZooN als *.deb gepostet und eine dBackup version geamcht die es verwendet - damit dauert das Backup genau 1 min - Perfekt :winking_face:

    4 Mal editiert, zuletzt von Lost in Translation ()