Skript zum einfachen formatieren von USB-Stick & Co.

[rgbs]

Sorry, der Satz:

Bzgl. chown ist mir noch was eingefallen: Nicht alle haben uid/gid1000 *), weshalb ich es beim root lasse und die Rechte auf 777 setze: Dann kann jeder dort Dateien und Verzeichnisse erstellen, die dann ihnen gehören und deren Rechte sie selbst bestimmen können.

war für mich missverständlich.
Und um das klarzustellen, wenn Du lieber mit Script formatierst ist das vollkommen in Ordnung, es führen eben mehrere Wege nach Rom.

Gruß
R.G.

 

[Caramon2]

Sorry, der Satz:

war für mich missverständlich.
Und um das klarzustellen, wenn Du lieber mit Script formatierst ist das vollkommen in Ordnung, es führen eben mehrere Wege nach Rom.

Stimmt, da war ich etwas betriebsblind: Für mich war es selbstverständlich, dass man die 777 mit chmod setzt. Steht so ja auch im Skript.

 

[Caramon2]

Da ich mich endlich dazu durchgerungen habe, mich mit udev zu beschäftigen, habe ich dazu eine Frage:

Deine Regel wie z.B.
KERNEL=="sd?1", SUBSYSTEM=="block", SUBSYSTEMS=="usb" , GROUP=="diskadm"
würde dafür Sorgen das USB-Blockgeräte immer der Benutzergruppe diskadm gehören.

Mich irritiert das "sd?1", bzw. die "1": Ich muss da an sda1, sdb1, usw. denken, also an die jeweils erste Partition.

Mit dem Skript will ich aber den ganzen Datenträger bearbeiten, egal wie viel Partitionen er hat und besonders wenn er "leer" ist, also noch nicht mal eine Partitionstabelle hat.

Hat die "1" dort evtl. eine andere Bedeutung?

 

[andy_m4]

Mich irritiert das "sd?1", bzw. die "1": Ich muss da an sda1, sdb1, usw. denken, also an die jeweils erste Partition.

Deine Gedanken dazu sind völlig richtig.
Das war jetzt auch nur ein Beispiel damit man mal sieht, wie die Syntax grundsätzlich ist und es ist natürlich ggf. an die eigenen Wünsche und Bedürfnisse anzupassen.

 

[Uridium]

Statt /dev/sd* kann man gerne auch /dev/disk/by-* benutzen. Die bleiben stabil.

Bei Flashspeicher (und deren Partitionierung/Alignment) spielt auch die "Erase Block Size" eine Rolle, die man z.B. mit Flashbench ausloten kann. Die Linaro FlashCardSurvey gibt's hier noch.

 

[lutzpime]

Vielleicht etwas OT, aber was ist hier der Vorteil gegenüber der Standardapp Laufwerke?

 

[Caramon2]

Deine Gedanken dazu sind völlig richtig.
Das war jetzt auch nur ein Beispiel damit man mal sieht, wie die Syntax grundsätzlich ist und es ist natürlich ggf. an die eigenen Wünsche und Bedürfnisse anzupassen.

Ok, danke.

Wenn ich einen USB-Stick anschließe, erscheint u. a. ("dmesg -w" - habe ich mir auf Win+D gelegt): "sd 6:0:0:0: [sdc] Attached SCSI removable disk" - Ich hatte gedacht, es könnte sich vielleicht auch auf das führende "sd" beziehen, oder auf etwas anderes.

Statt /dev/sd* kann man gerne auch /dev/disk/by-* benutzen. Die bleiben stabil.

Deshalb nutze ich das (u. a.) in meiner "/etc/cron.monthly/ssdsmart":

#!/bin/sh
sync;cd /home/
date -I >> ssdsmart.txt
echo "--------" >> ssdsmart.txt
smartctl -x /dev/disk/by-id/ata-CT250MX500SSD1_1919E201E172|grep -es_W -ePerc >> ssdsmart.txt
echo "--------" >> ssdsmart.txt
smartctl -x /dev/disk/by-id/ata-Intenso_SSD_3813430-532011020|grep -e"s W" -ePerc >> ssdsmart.txt
echo >> ssdsmart.txt

Die Ausgabe sieht so aus:

2022-01-20
--------
202 Percent_Lifetime_Remain ----CK   096   096   001    -    4
246 Total_LBAs_Written      -O--CK   100   100   000    -    9196023451
0x07  0x008  1               4  ---  Percentage Used Endurance Indicator
--------
0x01  0x018  6      1195064858  ---  Logical Sectors Written
0x07  0x008  1               0  ---  Percentage Used Endurance Indicator

Ich habe mir für jede SSD eine Tabelle erstellt, um einen Überblick zu haben und lasse dort u. a. die GiB/Tag, GiB seit letzten Mal und den vorraussichtlichen "Todestag" errechnen. - Mir ist klar, dass man sich nach letzterem nicht richten kann, finde es aber interessant, wie der sich je nach Nutzung verändert.

Bei Flashspeicher (und deren Partitionierung/Alignment) spielt auch die "Erase Block Size" eine Rolle, die man z.B. mit Flashbench ausloten kann. Die Linaro FlashCardSurvey gibt's hier noch.

Wie oben geschrieben: Wenn 64k Cluster, lasse ich die Partition bei 64k beginnen und bei 4k eben bei 4k: Da beim Sektor 0 auf jeden Fall das Alignment passt, ist das praktisch so, ale wäre der Datenträger vollständig (also bei 0 beginnend) formatiert, nur dass eben der erste "Cluster" für die Partitionstabelle reserviert ist.

Vielleicht etwas OT, aber was ist hier der Vorteil gegenüber der Standardapp Laufwerke?

"Laufwerke" nutze ich nur dazu, um nachzusehen, welches Gerät der Stick ist (also z. B. /dev/sdc). Zum partitionieren (insbes. bei mehreren Partitionen) finde ich es vollkommen ungeeignet, da es die Größe in MB, GB, usw. nutzt (also auf 1000er Basis) und man deshalb keine vernünftige Partitionierung (auf 1024er Basis) erstellen kann: Das ist totaler Murks.

Btw: Ich habe zwei ext. 2,5" Gehäuse, die haben beide die selbe Seriennummer: "Laufwerke" kommt nicht damit klar, wenn beide angeschlossen sind: Es wird nur ein Laufwerk angezeigt, mit den Partitionen des als zweiten angeschlossenen Laufwerks, aber wenn ich es ausschalte, geht stattdessen das erste aus (oder umgekehrt - ich kann es momentan nicht testen).

Wie gesagt: Zum anzeigen des Geräts ist es gut geeignet, auch zum umbenennen von Partitionen (außer ntfs3: das zeigt es als "unbekannt" an (s. Anhang) und beim Umbenennen gibt es einen Fehler), aber bzgl. Partitionierung: Finger weg! - Da ist GParted die weit bessere Wahl.

 

[Uridium]

Wie oben geschrieben: Wenn 64k Cluster, lasse ich die Partition bei 64k beginnen und bei 4k eben bei 4k

Der von dir beschriebene “Cluster“ ist eine logische Dateisystemgröße und hat mit der EBS (Erase Blocksize) nichts zu tun.

Kurz: Die USB-Sticks löschen/schreiben immer in 2M/4M/8M Blöcken und daran sollten die Partitionen ausgerichtet werden (sofern man das möchte), damit Dateisystem und internes Alignment besser zusammen passen, um dadurch wiederum Geschwindigkeits- und WearLevel-Vorteile zu erlangen. Genau beschrieben wird das in den beiden Links, die ich oben gepostet habe.

Edit: Wobei man mittlerweile die generelle Empfehlung von lediglich '1MB Sector Alignment' ausspricht, was sämtliche Tools wie 'fdisk' heutzutage standardmäßig machen.
https://superuser.com/a/1635137

Ob das auf USB-Sticks mittlerweile auch zutrifft, weiß ich nicht. Die sind ja meist nicht so "intelligent" (kein TRIM, wear-leveling, usw). Ich hatte damals einen alten 8GB Stick mit Flashbench gemessen und der hatte 8MB EBS, woraufhin ich die Partitionsanfänge und -enden ausgerichtet hatte. Und das hatte messbare Geschwindigkeitsvorteile, so wie auf der Flashbenchseite beschrieben. Das ist aber alles in der Tat schon etwas her. Müsste man vielleicht mal erneut testen mit aktuellen Geräten.

 

[Caramon2]

Offenbar verstehst du meinen Gedankengang nicht: Wenn der Stick als ganzes formatiert ist, also die Formatierung auf Sektor 0 beginnt, passt die EBS auf jeden Fall, da die ja auch mit Sektor 0 beginnen muss, ganz egal wie groß sie ist.

Innerhalb des Dateisystems werden die Daten auf die Cluster verteilt. Dabei ist es vollkommen egal, wo die Partition beginnt.

Ich mache bei meiner Partitionierung praktisch nichts anderes, als den ersten Cluster auszulassen: Der 1. Cluster der Partition ist dadurch deckungsgleich mit dem 2. Cluster bei vollständiger Formatierung, so dass es keinen Unterschied bzgl. des Alignments macht.

Wichtig ist ausschließlich, dass das Alignment an die 4k Sektoren der Flashzellen ausgerichtet sind: Partitioniert man mit der Datenträgervergewaltigung (kein Tippfehler ) von XP, starte die Partition auf Sektor 63, so das für jeden geschriebenen 4k Cluster (z. B. ntfs) zwei 4k Sektoren der Flashzellen beschrieben werden müssen: Das wird langsam! Mein Sat-Receiver konnte auf einem so partitionierten Stick (weil ich es danals noch nicht besser wusste) nicht mal mehr SD-Aufnahmen sauber aufnehmen, obwohl es vorher selbst bei HD-Aufnahmen nur zu gelegentlichen kurzen Aussetzern kam. - Ich dachte, der Stick wäre am Ende, weil ich ihn schon ein paar Jahre lang intensiv dafür genutzt habe, aber als mir das falsche Alignment dann aufgefallen ist und ich ihn korrekt partitioniert habe, funktionierte wieder wie neu - und tut es noch immer, obwohl inzwischen schon 12 Jahre alt: Ich hatte ihn 2010 zusammen mit dem Sat-Receiver gekauft.

Dagegen musst du bei 1 MiB Alignment (auch glatt durch 4k teilbar) berücksichtigen, dass auf dem ersten MiB nie geschrieben wird, es aber z. B. bei 4 MiB EBS immer wieder mit gelöscht werden muss, wenn eigentlich nur nachfolgenden 3 MiB gelöscht werden müssten. - Bzw. wenn du die Partition deshalb bei 4 MiB beginnen lässt, wird der erste EBS nie beschrieben und dafür alle anderen entsprechend häufiger.

Genau deshalb partitioniere ich so knapp wie möglich: Damit der Datenträger bestmöglich genutzt wird.

 

[rgbs]

Partitioniert man mit der Datenträgervergewaltigung (kein Tippfehler ) von XP, starte die Partition auf Sektor 63,

Das lag oder liegt daran, dass unter DOS die Festplattensektoren bis 64 für den Bootblock reserviert waren.
Du kannst es ja machen, wie Du magst, aber meiner Meinung nach ist die Sache mit den Festplattenspeichern unter Linux recht gut gelöst. Das Dateisystem mit seinen Schubladen muss ja auch mit den Schubladen der Hardware, welche ja im Zeitalter der SSDs nicht mehr eineindeutig lokalisierbar sind, übereinander passen.
Schlicht wie ich bin, gehe ich davon aus, dass z.B. Canonical das bei Ubuntu richtig macht und beschäftige mich lieber mit anderen Dingen.

Gruß
R.G.

 

[Caramon2]

Das lag oder liegt daran, dass unter DOS die Festplattensektoren bis 64 für den Bootblock reserviert waren.

Nicht ganz: Die ersten HDs hatten 63 Sektoren pro Spur und die Partitionen sollte daran ausgerichtet werden. - Schon zu XP-Zeiten war das durch LBA schon längst Geschichte, aber die bei MS sind ja nicht die schnellsten: Bekanntweise haben die z. B. immer noch Probleme mit neumodischen Kram wie Drucker.

Tatsächlich belegt der MBR nur einen Sektor, so dass die Partition gleich auf dem 2. beginnen kann (kann sie wirklich: XP bootet auch davon - hatte ich mit einer alten HD mit 512b Sektoren ausprobiert). Wegen des Alignments lasse ich sie jetzt eben bei 4k beginnen: Davon bootet auch noch Win10 problemlos.

Bei GPT belegt die Partitionstabelle intelligenterweise 33 Sektoren, so dass es nicht auf glatte 4k ausgeht und die Partition deshalb bei 20k beginnen sollte.

Und soll Grub installiert werden, brauche es 56k (soll von btrfs gebootet werden, ca. 130k), so dass die Partition entsprechend später beginnen muss.

Schlicht wie ich bin, gehe ich davon aus, dass z.B. Canonical das bei Ubuntu richtig macht und beschäftige mich lieber mit anderen Dingen.

Ich sage ja nicht, dass das ausrichten an glatte MiB falsch ist. Es ist nur Verschwendung und würde mich stören, obwohl vollkommen unbedeutend.

Wie heißt es so schön: Immer ein Bit übrig behalten.

 

[Uridium]

KERNEL=="sd?1", SUBSYSTEM=="block", SUBSYSTEMS=="usb" , GROUP=="diskadm"

[Fix]: 'GROUP' as 'assignment key' (=), not 'match key' (==).
KERNEL=="sd?1", SUBSYSTEM=="block", SUBSYSTEMS=="usb" , GROUP="diskadm"

Wenn der Stick als ganzes formatiert ist, also die Formatierung auf Sektor 0 beginnt, passt die EBS auf jeden Fall, da die ja auch mit Sektor 0 beginnen muss, ganz egal wie groß sie ist.

Die Partition, bzw. das "Partition Alignment" beginnt so aber nicht an einer 4MB EBS Grenze. Das ist ja das Entscheidende, wenn man das Dateisystem (das sich an der Partitionsgrenze orientiert) an die EBS koppeln will (z.B. mit 'mkfs.ext4 -E stripe-width=1024'). Wobei man generell nicht genau weiß, was unterhalb des FTL (Flash Translation Layer) passiert. Bei einem page-mapped FTL (wie bei SSDs mit TRIM) wäre das eher sinnlos. Bei USB Sticks hingegen weiß man das nicht so genau. Die Controller (und damit Wear Leveling/Garbage Collecting) scheinen aber deutlich rudimentärer.

Wichtig ist ausschließlich, dass das Alignment an die 4k Sektoren der Flashzellen ausgerichtet sind

Korrekt, die "Page Sizes" sind aber selten 4k groß. Meist eher 8k, 16k oder 32k. Dazu kommt, dass die Controller diese nochmals zusammenfassen zu "Write Sizes" (z.B. 32KB oder 256KB). Darum nimmt man gerne 1MB Alignment.

 

[Caramon2]

Die Partition, bzw. das "Partition Alignment" beginnt so aber nicht an einer 4MB EBS Grenze. Das ist ja das Entscheidende, wenn man das Dateisystem (das sich an der Partitionsgrenze orientiert) an die EBS koppeln will (z.B. mit 'mkfs.ext4 -E stripe-width=1024').

Das geht aber ziemlich ins Eingemachte!

Mit RAID habe ich mich noch nie beschäftigt, so dass ich auch nicht auf die Idee gekommen bin, so diese Option bzgl. EBS zu "missbrauchen": Das deckungsgleich zu bringen wäre natürlich optimal, aber außer ext4 scheint das von den gebräuchlichen FS nur noch xfs zu unterstützen (bei btrfs scheint das nur zu funktionieren, wenn btrfs selbst das RAID erstellt, so dass es vermutlich nicht für einen Stick funktioniert - ich habe das aber nur kurz überflogen).

Du übersiehst aber etwas: Partitionieren tut mein Skript nur DOS/Windows-Dateisysteme, weil Windows oft Ärger macht, wenn ein Datenträger als ganzes formatiert ist. - Bei den Linux-Dateisystemen lasse ich den Datenträger als ganzes formatieren, so dass das Alignment automatisch an die EBS angepasst ist, da beides mit Sektor 0 beginnt: Es müsste nur noch die stripe width passend gesetzt werden.

Da steht für mich der Nutzen aber in keinem Verhältnis zum Aufwand die richtige Größe herauszufinden. Zumal ich Sticks entweder aus Kompatibilitätsgründen mit fat16/fat32 und 64k Cluster formatiere, ansonsten mit f2fs (da dafür das mit großem Abstand schnellste FS), die beide keine stripe width unterstützen.

Wobei man generell nicht genau weiß, was unterhalb des FTL (Flash Translation Layer) passiert. Bei einem page-mapped FTL (wie bei SSDs mit TRIM) wäre das eher sinnlos.

Richtig. Der SSD-Controller packt es sich intern so, wie es ihm am besten passt. Wo der PC es speichern will, interessiert dabei nicht.

Edit: Solange es an 4k ausgerichtet ist: Z. B. eine Sektor 63 Partitionierung wie von XP verdoppelt praktisch die Schreiblast, da für jeden geschriebenen 4k Cluster zwei 4k Sektoren beschrieben würden.

Bei USB Sticks hingegen weiß man das nicht so genau. Die Controller (und damit Wear Leveling/Garbage Collecting) scheinen aber deutlich rudimentärer.

Die meisten (alle? - ich kenne jedenfalls keine Ausnahme) Sticks sind dumm:

Selbst der teure 128 GB SanDisk Extreme Go (ich wollte einen Gutschein nicht verfallen lassen), der definitiv auf SSD-Technik basiert, schafft die beworbenen 150 MB/s Schreibgeschwindigkeit nur beim ersten beschreiben. Dann wird er immer langsamer, weil es immer mehr Flashzellen erst gelöscht werden müssen und zuletzt schaffte er nach intensivem Einsatz (ich hatte mein Produktivsystem darauf installiert und mehrere Monate genutzt) kaum noch 5 MB/s schreibend! - Die Lesegeschwindigkeit blieb davon unbeeinträchtigt bei ca. 200 MB/s

Nachdem ich ihn vollständig mit /dev/zero überschrieben hatte, bliebt er noch mehrer Stunden warm (machte intern also irgendwas), anschließend ließ er sich wieder einmalig mit 150 MB/s beschreiben und es ging von vorne los. - Inzwischen habe ich das schon 4x gemacht, mit dem selben Ergebnis: Das ist also reproduzierbar.

Zwischendurch habe ich versucht, ihn nach dem löschen nicht vollständig zu partitionieren, damit er (wie die ersten SSDs, die noch kein trim kannten) durch den unpartitionierten Bereich immer genug gelöschte Flashzellen hätte, aber das war dem egal: Also nichts mit Wear Leveling/Garbage Collecting.

Da die 16 GiB Linux-Partition durch die Aktualisierungen am schnellsten lahm wurde (dort wurden nur noch 5 MB/s ), habe ich dann versucht, nur die mit Nullen zu überschreiben und wieder mehrere Stunden angeschlossen gelassen, damit er sich berappeln kann. Aber die Schreibgeschwindigkeit blieb bei 5 MB/s: Er muss immer vollständig überschrieben werden, um wieder die volle Schreibleistung zu erreichen: Erst dann erkennt er offenbar, dass er gelöscht wurde und löscht dann alle Flashzellen.

fstrim, blkdiscard, wiper.sh lieferten alle nur Fehlermeldungen, während ich USB-SSDs problemlos an allen USB-Ports des PCs trimmen kann: Sogar am USB3-Hub, der am USB3-Hub des TFTs angeschlossen ist, der am Back-USB3 des PCs angeschlossen ist.

Es liegt also ausschließlich am Stick: In meinen Augen eine "extreme" Mogelpackung. - Daher wohl auch der Name.

Da nicht das erste Mal, dass mir SanDisk negativ ausgefallen ist, werde ich nie wieder etwas von denen kaufen!

 

[Evil E-Lex]

Selbst der teure 128 GB SanDisk Extreme Go (ich wollte einen Gutschein nicht verfallen lassen), der definitiv auf SSD-Technik basiert,

Glaub ich nicht. Hab den Extreme Go auf der Arbeit. Das ist ein stinknormaler, wenn auch einigermaßen schneller, USB-Stick. Die Variante mit SSD-Technik ist der Extreme Pro. Der ist deutlich schneller und hat ein Metallgehäuse, um die nicht unerhebliche Abwärme beim Lesen/Schreiben loszuwerden.

 

[Caramon2]

Und wie erklärst du dir das extreme nachlassen der Schreibleistung und dass er sich durch vollständiges überschreiben wiederherstellen lässt?

Ein "normaler" USB-Stick macht sowas nicht.

 

[Uridium]

Du übersiehst aber etwas: Partitionieren tut mein Skript nur DOS/Windows-Dateisysteme, weil Windows oft Ärger macht, wenn ein Datenträger als ganzes formatiert ist. - Bei den Linux-Dateisystemen lasse ich den Datenträger als ganzes formatieren, so dass das Alignment automatisch an die EBS angepasst ist, da beides mit Sektor 0 beginnt

Ich hatte in der Tat nur die Windows Dateisysteme beachtet. Das, was Du "als ganzes formatieren" bezeichnest, kenne ich auch unter dem Begriff "Partitionless Disk".

Selbst der teure 128 GB SanDisk Extreme Go (ich wollte einen Gutschein nicht verfallen lassen), der definitiv auf SSD-Technik basiert

Du könntest schauen, ob er er als 'UAS' (USB Attached SCSI) oder nur als 'Bulk' erkannt wird (hier). Letzteres leitet die ATA Kommandos meist nicht weiter und ein "echter" SSD Controller wäre hier "Perlen vor die Säue".
Bei UAS dürfte 'hdparm -I' funktionieren, bei 'Bulk' vermutlich nicht.

Nachdem ich ihn vollständig mit /dev/zero überschrieben hatte, bliebt er noch mehrer Stunden warm (machte intern also irgendwas), anschließend ließ er sich wieder einmalig mit 150 MB/s beschreiben

Das könnte eine Art "umgekehrtes" DZAT (Deterministic read Zero After Trim) sein. Also er trimmt den Block intern selbst, bei der Erkennung von 0x00 Blöcken.

Zwischendurch habe ich versucht, ihn nach dem löschen nicht vollständig zu partitionieren, damit er (wie die ersten SSDs, die noch kein trim kannten) durch den unpartitionierten Bereich immer genug gelöschte Flashzellen hätte, aber das war dem egal: Also nichts mit Wear Leveling/Garbage Collecting.

Ist wahrscheinlich nur billiges block-mapped FTL, kein page-mapped FTL. Er schreibt also (fast) immer auf die gleichen Zellen, wie bei einer Festplatte.

Er muss immer vollständig überschrieben werden, um wieder die volle Schreibleistung zu erreichen: Erst dann erkennt er offenbar, dass er gelöscht wurde und löscht dann alle Flashzellen.

Vermutlich eine individuelle Geschichte des Herstellers. Schon mal "Quickformat" getestet? Vielleicht reagiert der Controller auf bestimmte Sektoren gängiger Formate (z.B. fat32 Quick).

 

[Caramon2]

Du könntest schauen, ob er er als 'UAS' (USB Attached SCSI) oder nur als 'Bulk' erkannt wird (hier). Letzteres leitet die ATA Kommandos meist nicht weiter und ein "echter" SSD Controller wäre hier "Perlen vor die Säue".
Bei UAS dürfte 'hdparm -I' funktionieren, bei 'Bulk' vermutlich nicht.

Der Extreme Go hat kein UAS (aufs relevante gekürzt):

dmesg:
scsi host6: usb-storage 9-1:1.0
scsi 6:0:0:0: Direct-Access     SanDisk  Extreme          1.00 PQ: 0 ANSI: 6

lsusb -t:
Class=Mass Storage, Driver=usb-storage, 5000M

lsusb -v|grep InterfaceProtocol:
bInterfaceProtocol     80 Bulk-Only

Als Gegenprobre eine SSD in einem trimmbaren USB-Gehäuse:

dmesg:
scsi host7: uas
scsi 7:0:0:0: Direct-Access     JMicron  Generic          0508 PQ: 0 ANSI: 6

lsusb -t:
Class=Mass Storage, Driver=uas, 5000M

lsusb -v|grep InterfaceProtocol:
bInterfaceProtocol     98

(hinter "98" stand nichts)

Vermutlich eine individuelle Geschichte des Herstellers. Schon mal "Quickformat" getestet? Vielleicht reagiert der Controller auf bestimmte Sektoren gängiger Formate (z.B. fat32 Quick).

Da es nicht man etwas bewirkt hat, die 16 GiB Partiton komplett mit Nullen zu überschreiben, wird er Dateisysteme erst recht nicht analysieren. - Dagegen spricht auch, dass er selbst frisch "revitalisiert" am Sat-Receiver (Xoro 8590, fat32-64k) vollkommen unbrauchbar ist: Nicht mal SD-Aufnahmen bekommt der sauber hin, obwohl die unter 1 MB/s Bandbreite haben.

Wie oben geschrieben: Selbst mein erster PVR-Stick (16 GB Medion von 2010) schaffte sogar HD-Aufnahmen fast ohne Aussetzer, dabei hat der eine lineare Schreibgeschwindigkeit von gerade einmal 10 MB/s.

Der Sandisk-Stick ist einfach nur Kundenverarsche: Hauptsache man kann besonders hohe Werte angeben…

Fazit:

Selbst teure "Markensticks" sind dumm: Kein Wearleveling & Co. und besonders hohen Schreibwerten ist nicht zu trauen, da auf irgendeine Art "ermogelt". - Es mag Ausnahmen geben, aber mir sind bisher keine untergekommen.

Auch z. B. ein 64 GB Corsair Voyager, der mit "bis zu" 50 MB/s Schreibleistung beworben wurde, schafft effektiv nur ca. 22 MB/s. Die 50 MB/s erreichte er unter keinen Umständen auch nur annähernd. Nicht mal als Peak.

Billig-Sticks sind da "ehrlicher": Von Anfang an lahm, woran sich dann aber auch nichts mehr ändert.

Positiv haben mich bisher nur die Trascent JetFlash überrascht: Ich habe einen 16 GB USB2- und einen 64 GB USB3-Stick. Beide übertreffen die angegebene Schreibleistung etwas und das dauerhaft: Selbst nach Jahren intensiver Nutzung (auch auf denen hatte ich Linux installiert *) und längere Zeit genutzt) schwächeln die nicht.

*) richtig installiert: mit Aktualisierungen, usw. - kein Livesystem

Ich habe das "SoS" (System on Stick) genannt und immer mit, wenn jemand Probleme mit seinem PC hat: So hatte ich mein Produktivsystem (natürlich ohne die großen Daten-Ordner), allen Tools (sogar ein VM-WinXP, um per chkdsk und BootIce Windows reparieren zu können) und der gewohnten Umgebung dabei.

Dabei habe ich dann auch gemerkt, wie ungeheuer lahm das "SoS" mit ext4 ist und um wie viel besser es mit xfs und noatime funktioniert (wie weiter oben beschrieben).

Inzwischen nutze ich dafür eine ext. SSD und allen meinen Daten (die Homepartition verschlüsselt, falls mir die SSD mal abhanden kommt). Das ist aber ein anderes Thema.