Posts by Leroy Cemoi

    Um den Trollverdacht zu entkräften könntest Du das Inkubator script hier zeigen. Das sagt mehr als 1000 Worte.

    Ansonsten besteht die Gefahr, dass sich der Inkubator für die Wachteln in einen Grill verwandelt.

    Das wollen ja alle nicht.

    Hast Du in #17 auch folgendes berücksichtigt: (aus Quelle in #18)


    eeprom_write_protect

    Configures the EEPROM Write Status Register. This can be set to either mark the entire EEPROM as write-protected or clear write-protection.

    Code
    This option must be used in conjunction with the EEPROM /WP pin which controls updates to the EEPROM Write Status Register. Pulling /WP low (CM4 EEPROM_nWP or on a Raspberry Pi 4 TP5) does NOT write-protect the EEPROM unless the Write Status Register has also been configured.

    See the Winbond W25x40cl or Winbond W25Q16JV datasheets for further details.

    eeprom_write_protect settings in config.txt for recovery.bin.

    ValueDescription
    1Configures the write protect regions to cover the entire EEPROM.
    0Clears the write protect regions.
    -1Do nothing.
    NOTEflashrom does not support clearing of the write-protect regions and will fail to update the EEPROM if write-protect regions are defined.

    On Raspberry Pi 5 /WP is pulled low by default and consequently write-protect is enabled as soon as the Write Status Register is configured. To clear write-protect pull /WP high by connecting TP14 and TP1.

    Default: -1

    Seit Will Smith als Aladdin in der Lampe wohnt ist sie weg😀

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    So ihr Lieben:),

    ich hab noch ein paar Backups gemacht. Kurz meine Konfiguration:

    1x pi5 8GB, 1x Lenovo Thinkpad T470s 20GB als Referenz, 1x HP Proliant Microserver 2 Cpus, 16 GB Ram, TP-Link 1 Gb switch 16 ports.

    Ich kann keine Störungen durch aktiviertes ipv6 feststellen. Die Messergebnisse sind identisch, egal ob mit oder ohne ipv6.

    Das Backup über nfs dauert ca. 6x länger als das Backup über rsync-ssh-rsync , abgekürzt r-s-r ab jetzt.

    Bei nfs sind die Einbrüche in der Übertragung deutlich zu sehen, bei r-s-r sieht man konstante Werte.

    pi5 braucht für 27GB bei nfs ca. 29 Minuten entsprechend ca. 15 MB/s , bei r-s-r ca.5 Minuten, entsprechend ca. 81 MB/s.

    T470s braucht bei nfs 160 Minuten für 80 GB -> ca. 8,3 MB/s, bei r-s-r 17 Minuten -> ca. 77 MB/s.


    Ich hefte ein paar screenshots an:

    Code
    pi@bookpi>18:49 mount | grep linux
    192.168.177.17:/mnt/Daten1/raspi on /mnt/linux type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=10,sec=sys,clientaddr=192.168.177.161,local_lock=none,addr=192.168.177.17)
    Code
    pi@bookpi>18:50 time sudo rsync -aHx -q --no-progress --delete  / root@192.168.177.17:/mnt/Daten1/raspi/bookpi_rsr
    root@192.168.177.17's password: 
    
    <<< Kommentar: bei -aHx kann ich kein -A anwenden; der rsync auf der NAS Seite kann das nicht im zfs unterbringen.>>>
    
    real	5m17,816s
    user	0m0,009s
    sys	0m0,001s
    pi@bookpi>18:55
    Code
    pi@bookpi>18:55 time sudo rsync -aHx -q --no-progress --delete  / /mnt/linux/bookpi_nfs
    
    <<< Kommentar: bei -aHx kann ich kein -A anwenden; der rsync auf der NAS Seite kann das nicht im zfs unterbringen.>>>
    
    real	30m46,612s
    user	0m0,008s
    sys	0m0,000s
    pi@bookpi>19:26 

    Von 18:44 bis ca. 18:56 läuft zweimal das r-s-r Backup. Von 18:55 bis ca. 19:26 läuft das nfs Backup. Deutlich ist der Einbruch ab 19:06 bis 19:25 zu sehen.

    Wahrscheinlich werden in dieser Zeit Unmengen von kleinsten Dateien beackert, welche bei nfs offenbar zeitaufwendig behandelt werden.

    Und jetzt reichts mir erstmal mit Backup^^

    Ich habe ipv6 auch nicht eingeschaltet, aber habe trotzdem den gleichen Schneck-Effekt bei rsync auf ein nfs share. Ich hatte mal die wsize und rsize parameter erhöht, bringt aber auch nichts. Sehr merkwürdig. Ich werde das bei Gelegenheit nochmal mit meinen alten Note- und Laptops probieren.

    Jetzt fällt mir auch wieder ein warum ich mit tar auf eine lokale disk sichere und dann den .tar.gz auf mein nas schiebe...

    ---

    Da die Ergebnisse bei rsync-ssh-rsync (pi-ssh-nas) erstaunlich gut sind werde ich mein backup darauf umstellen. Ist schlanker.

    Zwischendurch habe ich mal pi5|p4 nach nas backup betrachtet. Ich habe den p5 mit SD Karte getestet, dann die SD karte in den pi4 und nochmal getestet. Der pi5 ist rund doppelt so schnell fertig.

    Die beiden hohen Türme sind der pi5, die beiden anderen der pi4. Beim pi4 rsync einmal mit -v, einmal ohne. Macht was aus.

    (Irgendwie erinnern mich die Türme an Köln, warum nur?)

    Schaun wir mal wie es weitergeht.

    Das erscheint mir hilfreich:

    NFS performance over high latency is poor, rsync over ssh is about 100x faster
    We are using rsync to synchronize data from two NFS servers. One NFS server is on the east coast, the other is on west coast. RTT is about 110ms. On the east…
    unix.stackexchange.com

    Money quote:

    That is rsync is designed to work:

    Code
                [fast]        [slow SSH]        [fast]
    File system <----> rsync <----------> rsync <----> File system

    Rsync is optimised for network performance between the two agents, but it has no way to control the protocol used to access the disk. So when you mount a remote NFS file system you change the profile of network access:

    Code
                [fast]        [fast]        [slow NFS]
    File system <----> rsync <------> rsync <---------> File system

    Rsync can't do anything about this because it has absolutely no control over the NFS protocol.

    Kein Performance Einbruch festzustellen:)

    Kein nfs festzustellen:)

    Rahmenbedingungen: Lenovo Thinkpad T470s mit 1TB nvme über 1Gb/s an single port HP Proliant microserver mit TrueNAS auf 2 x 4TB cmr disks pool zfs (mirrored)

    127GB in knapp 40 Minuten. Ich bin auch überrascht8)

    Ich werde noch ein wenig am rsync command arbeiten weil ich etwas sehr einfaches zum Test genutzt habe:

    Code
    sudo rsync -a / --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/","/mnt/","/media/","/lost+found"} pi@192.168.177.36:/mnt/Daten0/linux/t470s

    Da ist noch einiges an Mist mitgekommen oder auch nicht:)

    Ich werde berichten was geht...

    VG Leroy

    Hm, leider keine Info welche disk jetzt wirklich da drin ist. Blöd auch, dass Linux explizit nicht in der Kompatibilitätsliste steht. Nur Windows und Mac.

    Falls der eingebaute Controller das Problem sein sollte wird der Austausch nichts bringen.

    In #15 war es ähnlich, ich hatte 2 Boxen mit eingebauten controllern und je 1x 6TB disk. Es war unmöglich die disks unter linux mit ext4 zu formatieren, auch mit Datenrettungstools ging nichts. Unter Windows waren die disks auch nicht mehr zu gebrauchen.

    Habe die disks dann vom Gehäuse und Controller befreit, ans PC mainboard gesteckt und siehe da, sie liessen sich wieder zum Leben erwecken.

    Ich habe die später an mein truenas auf einem HP ProLiant microserver Gen8 angeschlossen und dort laufen sie seit Jahren mit zfs an einem HP controller.

    rsync muss natuerlich fuer jede Datei pruefen ob sie sich geaendert hat. Wenn Du sehr viele kleine Dateien hast dauert das entsprechend.

    Mir fällt gerade ein, dass es ja smr und cmr Platten gibt. Wenn smr disks im Einsatz sind und im lan nix auffälliges zu sehen ist, würde ich das Performance Problem fast dort verorten. Viele kleine Datenänderungen sind für smr nix.