Haelt eine SD Karte laenger wenn man nicht vollstaendig partitioniert?

  • Normalerweise nutze ich immer 8GB SD Karten auf meinen Raspberries. Wenn mehr Platz notwendig ist wird eine SSD oder USB Platte drangehaengt.

    Jetzt hatte ein Nutzer von raspiBackup Probleme einen Backup auf eine 64GB SD Karte zu restoren und deshalb habe ich mir mal eine 64GB SD Karte besort: EVO Select von Samsung [Anzeige]. Der Restore funktioniert und das restorte System bootet auch. Soweit - so gut. Der raspiBackup Nutzer hat offensichtlich eine 64GB SD Karte erwischt die nicht von einer Raspberry erkannt wird.

    Diese Karte jetzt fuer Backup/Restoretests zu nutzen macht keinen Sinn da ich dafuer nur immer 8GB SD Karten brauche. Also habe ich mir ueberlegt diese SD Karte in einer meiner Produktionsraspberries zu nutzen. Kann ich die SD Kartenlebensdauer erhoehen wenn ich nur eine Bootpartition von 512 MB und eine Rootpartition von 8GB anlege und den restlichen Space (ca 56GB) unpartitioniert lasse? Oder ist es egal? Wenn ich das wear leveling richtig verstehe sollte es egal sein. Aber ich kann mich erinnern dass es bzgl SSDs mal im Netz den Ratschlag gab eine SSD nicht vollstaendig zu partitionieren um die Lebensdauer zu verlaengern.

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Garten

    3 * RPi2B, 2 * RPi3B, 2 * RPi4B, 1 * CM4, 1 * RPi5

  • Haelt eine SD Karte laenger wenn man nicht vollstaendig partitioniert?? Schau mal ob du hier fündig wirst!

  • ich würde tippen, dass das bei einem vernünftig implementierten wear-level auf dem SD-Controller keine Rolle spielt. Bei schlecht umgesetztem oder gar nicht vorhandenem wear-level wird damit evtl. sogar die Lebensdauer verkürzt, da nur die Sektoren beschrieben werden, die innerhalb der vorgegebenen (Teil-)Partition liegen.

    Wenn Dein raspiBackup-Benutzer eine (no-name) SD-Karte aus einer obskuren Quelle verwendet, kann alles Mögliche schief gehen.

    Ein anderer Punkt ist noch (dr)exFAT bei SD-Karten >32GB (SDXC), aber diese Problematik sollte mit dem Verschwinden von NOOBS eher der Vergangenheit angehören. Wobei ich nicht weiß, was Windows, das ich dem Nutzer unterstelle, beim Formatieren von großen SDXC-Karten so alles fabriziert.

  • Das Thema hatten wir schon mal. Es müsste egal sein, wenn ich mich richtig erinnere. Zumindest so lange der Karten Kontroller die Datenverteilung übernimmt und man da keinen Einfluss drauf hat. Ich denke wenn die Schreibzugriffe auf das nötigste begrenzt werden, ist man auf einem guten Weg, was die Lebensdauer verlängern angeht.

  • Das Thema hatten wir schon mal.

    Hast Du den Link auf den Thread? Ich habe hier gesucht aber keinen Hit bekommen :(

    Schreibzugriffe auf das nötigste begrenzt

    Das sollte man natuerlich immer machen. Aber waere ja schoen wenn meine Idee noch etwas Haltbarkeit obendrauf legt :)

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Garten

    3 * RPi2B, 2 * RPi3B, 2 * RPi4B, 1 * CM4, 1 * RPi5

  • Danke hyle . Da geht es jetzt weniger um meine konkrete Frage bzgl Wear-leveling und der Groesse der Partitionen auf der SD Karte. Aber es war trotzdem noch mal gut den Thread wieder zu lesen.

    Ich denke letztendlich ist es wohl unsicher ob das was bringt. Die Lebensdauer verlaengert definitiv ein RO Filesystem - sofern man das nutzen kann oder dann das Mappen von intensiv genutzen Verzeichnissen in tmpfs (/var/log, /tmp, et al).

    Erfahrung mit F2FS habe ich bislang noch nicht. Aber gemaess dieser Anleitung ist das relativ schnell auf der Raspberry aktiviert. Vielleicht gibt es ja Leute die dieses Nutzen und koennen ihre Erfahrung einbringen :)

    EDIT: Hier wird F2FS von dem Entwicklern vorgestellt

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Garten

    3 * RPi2B, 2 * RPi3B, 2 * RPi4B, 1 * CM4, 1 * RPi5

  • Es wurde in einem anderen Thema besprochen; wohl auch nur beiläufig. Daher wird es auch schwer das Thema zu finden. Im Grunde müsste man wissen, wie die SD Karte genau funktioniert. In den meisten Fällen, wenn nicht immer, wird der Karten Kontroller eine Blackbox sein. Ich nehme aber an, dass die meisten Karten, die Daten gleichmässig auf der gesamten Karte verteilen. Egal wie man partitioniert.

    Um ein "totschreiben" zu vermeiden würde ich neben dem schon genannten, grössere Karten verwenden. Auch wenn die Karte nur halb mit Daten gefüllt wird. Die Karte möglichst nicht vollschreiben.

  • Kann ich die SD Kartenlebensdauer erhoehen wenn ich nur eine Bootpartition von 512 MB und eine Rootpartition von 8GB anlege und den restlichen Space (ca 56GB) unpartitioniert lasse?

    Ja, wobei 56 GByte leicht übertrieben ist ;)

    Für das Wear-Leveling wird vom OS der Karte der Speicher verwendet, der nicht für eine Partition verwendet wird.

    Früher™, also zu den Anfängen von SSD-Datenträgern hatten die Hersteller keinen oder zu wenig Speicher fürs Wear-leveling reserviert.

    Heutzutage ist das normalerweise genügend (der dann auch nicht partitioniert werden kann)

    Doch wenn man einem System, das wirklich viel beschrieben wird, mehr Platz bereitstellt, sollte diese SSD länger viel beschrieben werden.

    Wobei hier dann vielleicht der Speicher zerschrieben wird, der die Übersetzung zwischen physikalischen und logischer Speicherposition ist.

    Denn bei SSDs wird ja nicht der dem Betriebssystem des Rechners bekannte Block beschrieben, sondern ein Block, der zu diesem Zeitpunkt mit die geringste Schreibrate hat. Und hierfür wird dann eine Tabelle benötigt, um den System den richtigen Speicherinhalt auszuliefern.

    Computer ..... grrrrrr

  • Naja wenn die nicht ganz blöd sind die Kartenhersteller, dann wird natürlich auch die Metainformation über die Abnutzung der Blöcke nicht immer in die gleichen Böcke geschrieben. Sonst bringt das ja nichts wenn *die* kaputt gehen und alle anderen schön soweit geschont werden wie es ging. 😃

    “I am Dyslexic of Borg, Your Ass will be Laminated” — unknown

  • In der Regel sollten genug Speicherzellen auf Reserve gehalten werden aber wenn Du sicherer unterwegs sein willst, nimm ne SSD.

    Die werden gerade auch in kleineren Größen einem nachgeworfen.

    ;) Gruß Outi :D

    Mein Zeug

    Pis: 2x Pi B, 1x Pi B+, 1x Pi 2 B in Rente / 2x Pi 3 B (Tests / Repetier Server) / 2x Pi Zero 1.2 / 2x Pi Zero 1.3 / 2x Pi Zero W 1.1 / 1x Pi Zero 2 (BW+CUPS/SANE) /
    1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (HomeAssistant) / Pi 400 (BW) / 1x Pi 5 8GB (BW) / 2x Pico / 2x Pico W / 2x Pico 2 / 2x Pico 2 W
    HATs: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT / Pimoroni NVMe BASE / M.2 HAT+
    Cams: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • aber wenn Du sicherer unterwegs sein willst, nimm ne SSD.

    Die werden gerade auch in kleineren Größen einem nachgeworfen.

    Das ist sicherlich eine gute Idee. Aber fuer mich ist das keine Alternative: Ich moechte keine weitere HW an meine Raspis anschliessen. Just die plain HW mit Gehaeuse. Daran nur noch ein Netzwerkkabel und eine Stromversorgung angeschlossen.

    Outlaw Vielleicht postest Du einen Link auf eine SSD die als eine Alternative siehst fuer diejenigen, die nicht so restriktive Anforderungen haben wie ich :)

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Garten

    3 * RPi2B, 2 * RPi3B, 2 * RPi4B, 1 * CM4, 1 * RPi5

  • Ich habe hier einige ältere Kingstons mit 120GB, ne OEM Micron mit 240GB, ne 1TB WD Blue 3D, u.v.a.m. ....

    Schau einfach im Geizhals bei den SSDs, die günstig sind (auch einige Marken dabei) und keine komischen Namen haben.

    Geschwindigkeit ist bei ner SSD über einen USB3 Adapter zweitrangig, trotzdem im Normalfall aber schneller als bei ner SD.

    Geil wird beim 5er, wenn das NVMe HAT draußen ist und sich bewahrheiten sollte, dass der PCIe doch schneller ist, als angegeben.

    ;) Gruß Outi :D

    Mein Zeug

    Pis: 2x Pi B, 1x Pi B+, 1x Pi 2 B in Rente / 2x Pi 3 B (Tests / Repetier Server) / 2x Pi Zero 1.2 / 2x Pi Zero 1.3 / 2x Pi Zero W 1.1 / 1x Pi Zero 2 (BW+CUPS/SANE) /
    1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (HomeAssistant) / Pi 400 (BW) / 1x Pi 5 8GB (BW) / 2x Pico / 2x Pico W / 2x Pico 2 / 2x Pico 2 W
    HATs: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT / Pimoroni NVMe BASE / M.2 HAT+
    Cams: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • Die guten SSDs müssten neben dem Flash-Speicher noch einen Flash-Speicher fürs Mapping haben. Das Mapping löst logische Adressen in physikalische Adressen auf. Wenn eine Speicherzelle kaputt ist, dann wird der Zeiger der logischen Adresse geändert und zeigt dann auf eine andere Speicherzelle.

    Ich habe aber auch eine alte SSD, bei der die Speichermenge an Flash-Chips verbaut ist, was der Gesamtkapazität entspricht (16 x 64GBit == 128GB bzw. 119 GiB). Die alten SSDs müssten bei defekten Speicherzellen kleiner werden, da keine Reserve vorhanden ist.

  • Man erkennt SSDs mit mehr reserviertem Speicher u.A. auch an den aufgedruckten Größen:

    128GB werden zu 120GB, 256GB zu 240GB, ....

    Also quasi alles, was nicht ins 8el Raster passt.

    ;) Gruß Outi :D

    Mein Zeug

    Pis: 2x Pi B, 1x Pi B+, 1x Pi 2 B in Rente / 2x Pi 3 B (Tests / Repetier Server) / 2x Pi Zero 1.2 / 2x Pi Zero 1.3 / 2x Pi Zero W 1.1 / 1x Pi Zero 2 (BW+CUPS/SANE) /
    1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (HomeAssistant) / Pi 400 (BW) / 1x Pi 5 8GB (BW) / 2x Pico / 2x Pico W / 2x Pico 2 / 2x Pico 2 W
    HATs: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT / Pimoroni NVMe BASE / M.2 HAT+
    Cams: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • 128GB werden zu 120GB, 256GB zu 240GB, ....

    Also quasi alles, was nicht ins 8el Raster passt.

    Ganz sicher?

    Ich behaupte, dass es aufgrund des Umrechnungsfaktors weniger angezeigt wird.

    Code
    >>> 128e9 / 1024 ** 3
    119.20928955078125
    >>> 256e9 / 1024 ** 3
    238.4185791015625

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!