• bennypr0fane@discuss.tchncs.de
    4·
    16 days ago

    Und in welcher Form ist das Komprimieren hilfreich dabei, die Funktionstüchtigkeit des “Magnetspeichers” (SSD?) zu überprüfen?

    • istdaslol@feddit.org
      9·
      16 days ago

      Magnetspeicher sind die alten Festplatten die sich schnell drehen mit arm undso. SSDs wären Blitzspeicher

    • bleistift2@sopuli.xyzOPDeutsch
      7·
      16 days ago

      Gar nicht. Siehe Überschrift (entzangendeutscht) „any% Speedrun”. Es ging ihm nur darum, die 100GB zu nehmen und eine Datei auf die Platte zu werfen.

      • inkeso@feddit.org
        6·
        16 days ago

        Exakt. Aber wenn es wirklich darum ging auf Funktionstüchtigkeit zu prüfen (und nicht auf Schreibgeschwindigkeit oder so) wäre schlechtblöcke (badblocks) im nichtdestruktiven Modus und bei ausgehängter Partition das bessere Werkzeug. Und sehr, SEHR viel langwieriger.

        • bleistift2@sopuli.xyzOPDeutsch
          4·
          16 days ago

          Danke für den Hinweis. Ich wusste, dass es Tools gibt, die „richtig” prüfen, ob eine Festplatte gut ist. So weit vertraue ich aber meinem Händler. Ich teste gerade hauptsächlich, ob die Kapazität wirklich korrekt angegeben wurde oder ob das Ding nach einem Terabyte wieder Daten überschreibt. Und ob sich sonst irgendwas Komisches bemerkbar macht.

          Die Festplatte soll eigentlich nur das Internet cachen, also kommt es nicht einmal darauf an, dass die Blöcke gut sind.

          • inkeso@feddit.org
            6·
            16 days ago

            Aah OK. Mache ich so ähnlich auch gern bei dubiosen Speichermedien, wo es nur so halb drauf ankommt.

            Wäre ja in dem Fall sogar übertrieben zu gucken, ob korrekt geschrieben wurde. 
            # blocksize 1M * 1k = 1G file
dd if=/dev/urandom bs=1M count=1k status=progress | tee random.junk | md5sum
md5sum random.junk

            (Prüfsummen sollten identisch sein)

            • bleistift2@sopuli.xyzOPDeutsch
              1·
              3 days ago

              Danke für die Idee. Hab’s ein bisschen weiter automatisiert.

              #!/bin/bash

set -euo pipefail

OUTDIR="/mnt/HDD"
COUNT=2621440
for i in $(seq 1 28); do
    outfile="$(mktemp -p ${OUTDIR})"
    checksum=$(dd if=/dev/random bs=4096 count=${COUNT} status=none | tee "$outfile" | sha256sum)
    filename="$(realpath --relative-to=${OUTDIR} ${outfile})"
    echo "${checksum/-/${filename}}" >> "${OUTDIR}/sums"
done

sha256sum -c "${OUTDIR}/sums"
            • bleistift2@sopuli.xyzOPDeutsch
              3·
              16 days ago

              Nettes Skript. Ich würde aber das normale random nehmen statt urandom. Das ist zufällig genug.

              • inkeso@feddit.org
                2·
                16 days ago

                Lieber nicht. random ist kryptografisch guter, “echter” Zufall. Wenn die Enthropie im System leer ist, blockiert das und man kann dann erst wieder lesen, wenn genug neue Enthropie vorhanden ist. urandom ist ein auf random basierender Pseudozufall, der niemals blockiert und schnell Daten liefert.

                • bennypr0fane@discuss.tchncs.de
                  2·
                  16 days ago

                  Oh. Ich wusste nicht, dass einem irgendwo die Entropie ausgehen kann. Klingt irgendwie sehr unphysikalisch (nicht, dass ich was davon verstünde). Woher weiß dass System denn, wann sie weg ist, und wie kommt sie wieder zurück?

                  • inkeso@feddit.org
                    3·
                    16 days ago

                    Enthropie wird aus u.a. sowas wie Mausbewegung und Tastatureingaben gewonnen. Was genau die Quellen sind, weiß ich aus dem Stehgreif nich.

                    Ich hatte es schon, daß bei einem frisch gebooteten RasPi bei der ssh-key-erzeugung die Enthropie alle war und ich erstmal auf der Tastatur rumrollen musste, bis es weiter ging. Ist aber ne Weile her (4er Kernel)

                    Auf 'nem normalen Desktop gibt es vermutlich genug andere Quellen oder da hat sich was an der Implementierung geändert, aber ich habe gerade testhalber problemlos 50GB aus /dev/random gelesen… Vermutlich isses also einfach egal. :-)