Skript zum einfachen formatieren von USB-Stick & Co.

[Caramon2]

Hallo.

Um USB-Sticks und andere Datenträger, die nicht in mehrere Partitionen unterteilt werden sollen, schnell einzurichten, habe ich mir vor einiger Zeit ein Skript geschrieben.

Warnung: Der Zieldatenträger wird gleich nach Eingabe des sudo-Passworts platt gemacht. Es erfolgt keine Plausibilitätskontrolle. Wer das falsche Laufwerk erwischt, darf anschließend seine letzte Sicherung wiederherstellen. - Ich lasse aber vorher das Ziellaufwerk anzeigen, so dass man notfalls abbrechen kann.

So formatiert man z. B. /dev/sde mit fat32 und dem Namen "Verbatim":

part e fat32 Verbatim

Wobei der Datenträger nicht leer sein muss, da das Skript ihn im ersten Schritt sicherheitshalber alle ggfs. eingehängten Partitionen aushängt und dann löscht.

Edit: Das Skript nenne ich "part" (ohne Endung) und muss natürlich als ausführbar markiert im Pfad liegen.

Ich lasse nur Windows-Dateisysteme partitionieren, da das als ganzes formatiert Datenträger nicht mag. Ans Alignment nehme ich die Clustergröße der anschließenden Formatierung, so dass es glatt aufgeht und nichts verschwendet wird (ich bin Perfektionist ):

#!/bin/bash
if [ -z $2 ];then echo "part /dev/sd? fs Name";exit;fi
if [ -z $3 ];then l=$2;else l=$3;fi

echo;lsblk -f /dev/sd$1;read -p [Enter/Strg+C]

sudo umount -l /dev/sd$1*
sudo dd if=/dev/zero of=/dev/sd$1 oflag=direct status=none bs=4M count=1
case "$2" in

fat16) sudo parted -s /dev/sd$1 mklabel msdos;sleep 1
sudo parted -sa none /dev/sd$1 mkpart primary fat16 64kiB 100%;sleep 1
sudo mkfs.vfat -F16 -s128 -n $l /dev/sd$1"1"
;;

fat32) sudo parted -s /dev/sd$1 mklabel msdos;sleep 1
sudo parted -sa none /dev/sd$1 mkpart primary fat32 64kiB 100%;sleep 1
sudo mkfs.vfat -s128 -n $l /dev/sd$1"1"
;;

exfat) sudo parted -s /dev/sd$1 mklabel msdos;sleep 1
sudo parted -sa none /dev/sd$1 mkpart primary ntfs 64kiB 100%;sleep 1
sudo mkfs.exfat -s128 -n $l /dev/sd$1"1"
;;

ntfs) sudo parted -s /dev/sd$1 mklabel msdos;sleep 1
sudo parted -sa none /dev/sd$1 mkpart primary ntfs 4kiB 100%;sleep 1
sudo mkfs.ntfs -QIL $l /dev/sd$1"1"
;;

f2fs) sudo mkfs.f2fs -l $l /dev/sd$1
sudo mount /dev/sd$1 /mnt && sudo chmod 777 /mnt && sudo umount -l /mnt
;;

xfs) sudo mkfs.xfs -L $l /dev/sd$1
sudo mount /dev/sd$1 /mnt && sudo chmod 777 /mnt && sudo umount -l /mnt
;;

*) echo "fs: fat16/32|exfat|ntfs|f2fs|xfs"
;;
esac

Wenn keine/zu wenig Parameter oder ein unbekanntes Dateisystem angegeben werden, gibt es eine Kurzhilfe aus.

Wird kein Name angegeben, wird das gewählte Dateisystem als Bezeichnung genutzt.

Linux-Dateisysteme werden anschließend auf 777 gesetzt, damit man sie als normaler Nutzer verwenden kann (wegen "sudo" könnte das sonst nur der Root).

Nachtrag: Das obige Skript bleibt weiterhin die Finale Version. Der Thread beinhaltet Alternativen, pro/contra, zusätzliche Infos und Begründungen, weshalb ich es auf diese Art umgesetzt habe. - Danke an alle Mitwirkenden.

Wichtig:

Da bei FAT(16/32) ausschließlich 64k-Cluster Sinn machen (bzgl. Verwaltungsaufwand/Geschwindigkeit), muss für Datenträger bis 4 GiB fat16 genutzt werden, da nur das bis 2¹⁶ Cluster unterstützt. fat32 unterstützt nur über 2¹⁶ Cluster.

ext4 nutze ich nicht:

Das ist mir im Vergleich zu xfs viel zu lahm (z. B. bei Sicherungsplatten, oder einer Linux-Installation auf einem USB-Stick) und da meine ersten SSD (250 GB BX100) nicht nur Host- sondern auch Flash-Writes anzeigte, habe ich in den Monaten nach der Umstellung auf xfs gemerkt (ich protokolliere das regelmäßig), dass damit das Verhältnis Flash-Writes zu Host-Writes deutlich besser als im Jahr vorher mit ext4 ist: ca. 17x statt ca. 2,3x. - Also für SSDs ist xfs entsprechend schonender.

Ein Bekannter mit Win10/ntfs hatte übrigens bei seiner SSD auch ca. 2,3x, so dass ich vor xfs dachte, das wäre technisch bedingt.

Der einzige Nachteil von xfs ist, dass man es zwar sogar im laufenden Betrieb vergrößern kann, aber generell nicht verkleinern. - Noch nicht: Angeblich soll das noch kommen.

Gruß,

Andreas

 

[elgorro]

Wäre das nicht eher was für Gitlab oder Konsorten? Btrfs?

 

[Caramon2]

Mit Gitlab kenne ich mich nicht aus. Das Skript ist aber auch eher eine kleine Fingerübung, die für mich gut funktioniert.

Btrfs habe ich lange gemieden, weil man viel schlechtes darüber gehört hat, fehleranfällig, angeblich voll, obwohl eigentlich noch genug Platz frei ist, usw. Als es dann auch zStd. unterstützt hat, habe ich es ausprobiert und da es meine Systempartition auf nur noch 1/3 komprimert hat, habe ich es mehrere Monate lang genutzt, später auch auf den Sicherungsplatte, weil es stabil zu sein schien. - Bis ich dann auch einer der Sicherungsplatten auf ein paar beschädigte Videos (Spielfime: recodete DVB-Aufnahmen) gestoßen bin: Das kopieren brach schon nach ein paar MB ab, obwohl alles i. O. aussah und auch btrfs-check nicht finden konnte.

Seit dem meine ich es, weil es mir zu heikel für meine Daten ist. - Mit Snapshot hatte ich übrigens nichts am Hut. Ich habe es als normales Dateisystem genutzt, nur eben mit Komprimierung. Gesichert habe ich normal per "rsync -vaxH --del …", also auch ohne spezielle btrfs-Funktionen, wo man auch mal was von "experimentell", oder so liest.

 

[Caramon2]

Hatte ich ganz vergessen: Das Skript nenne ich "part" (ohne Endung) und muss natürlich als ausführbar markiert im Pfad liegen.

noch zur ext4: Das formatiert standardmäßig unvollständig und schließt die Formatierung erst ab, wenn die Partition eingehängt wird. - Bei einer 1 TB Platte hat es ca. eine halbe Std. lang ständig kurze Zugriffe gegeben, bevor die Formatierung endlich fertig war.

Wenn man gleich vollständig formatieren will, kann man das deaktivieren: "mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -FL (Name) /dev/sdXX"

Um btrfs mit Komprimierung zu formatieren, hatte ich mir das aufgeschrieben (das sind nur die verwendeten Befehlszeilen, kein Skript):

lw=/dev/sdX
pt=$lw"X"

mkfs.btrfs $pt -msingle -L[Name] -U[UUID]
mount -o noatime,compress-force=zstd,ssd,discard $pt /mnt/ && chmod 777 /mnt/
btrfs pr set /mnt/ compression zstd && btrfs pr get /mnt/

grub-install --boot-directory=/mnt/boot/ $lw

umount -l /mnt/

Um bei diesen Partitionen "compress-force=zstd" zu aktivieren *), wenn ich z. B. von einem Livesystem darauf zugriff (ansonsten hatte ich es in der fstab), hatte ich mir dieses Skript geschrieben und im Rootverzeichnis der Partition (nur dort funktioniert es) abgelegt und nach dem Einhängen gleich ausgeführt:

#!/bin/bash
sync -f .
sudo mount -o remount,noatime,compress-force=zstd . && espeak-ng check! || espeak-ng fail

"espeak-ng" muss dazu natürlich installiert sein.

*) ansonsten wird vieles nicht komprimiert, bei dem es viel bringen würde, nur weil der Anfang der jeweiligen Datei schlecht komprimierbar ist

 

[andy_m4]

Warnung: Der Zieldatenträger wird gleich nach Eingabe des sudo-Passworts platt gemacht. Es erfolgt keine Plausibilitätskontrolle. Wer das falsche Laufwerk erwischt, darf anschließend seine letzte Sicherung wiederherstellen.

Ich finde es generell problematisch wenn solche Angelegenheiten als root ausgeführt werden. Dazu besteht gar keine Notwendigkeit, wenn das auf dem betreffenden Blockgerät die entsprechenden Rechte gesetzt sind. Dann kann man das Anlegen von Partitionen und Formatieren auf dem USB-Stick nämlich als normaler User machen und kommt nicht in Probleme, wenn man mal ein falsches Device angibt.

ich bin Perfektionist

Dann würde ich zumindest als Plausibilitätsprüfung einbauen, das das Skript nachguckt ob das ein Wechseldatenträger ist.
Außerdem würde ich doppelten Code vermeiden und entsprechende Funktionen anlegen.
Von perfekt ist das Skript weit weg.

Da bei FAT(16/32) ausschließlich 64k-Cluster Sinn machen (bzgl. Verwaltungsaufwand/Geschwindigkeit), muss für Datenträger bis 4 GiB fat16 genutzt werden

FAT16 macht bei den heutigen Speichergrößen fast gar kein Sinn mehr. Es geht natürlich, aber wozu? Bis auf spezielle Szenarien fällt mir nix ein.

ext4 nutze ich nicht:
Das ist mir im Vergleich zu xfs viel zu lahm

xfs dürfte in vielen Fällen Overkill sein. Und etwaige Geschwindigkeitsprobleme kriegt man dadurch in den Griff, das man bei ext4 z.B. das Journaling ausschaltet. atime dürfte auch in den meisten Fällen überflüssig sein.

 

[Caramon2]

@andy_m4:
1. Welche Rechte für ein Blockgerät?

2. Das bezog sich auf die optimierte Partitionierung. Das Skript habe ich so unkompliziert und übersichtlich wie möglich gehalten.

3. Ich hatte extra "bis 4 GiB" geschrieben.

4. ext4 ist schlecht und ohne Journaling erst recht. Für Sicherungsplatten würde ich es dann ganz bestimmt nicht einsetzen und für Sticks ist f2fs das mit Abstand schnellste FS, wenn man kein Journaling braucht.

Was soll an xfs Overkill sein? Das ist schnell, schlank, sehr robust und einfach zu warten.

noatime habe ich überall gesetzt, da dadurch keine Nachteile habe, bei SSD unnötige Schreibzugriffe spare und besonders ein auf einem Stick installiertes Linux wird dadurch nahezu unbrauchbar.

 

[andy_m4]

1. Welche Rechte für ein Blockgerät?

Blockgeräte sind unter Linux/Geräte die "blockweise" angesprochen werden. Typisches Beispiel sind eben Festplatten oder auch einzelne Partitionen. Blockgeräte landen wie alle Geräte im Verzeichnis /dev
So ist /dev/sda1 zum Beispiel das Blockgerät für die erste Partition der ersten Festplatte.
Da das letztlich normale Dateien sind, lassen sich damit natürlich auch die normalen UNIX-Rechte benutzen. Teilweise wird das auch genutzt. Zum Beispiel für die Grafikkarte (der Kram liegt in der Regel unter /dev/dri). Die Karte gehört oft der Gruppe video. Dadurch können alle User die der Gruppe video angehören auf die Grafikkarte zugreifen, was z.B. wichtig ist wenn man X.org oder Wayland benutzt.

Die Blockgeräte für die Festplatten gehören i.d.R. root (weshalb man auch für gparted, mkfs etc. überhaupt root-Rechte braucht). Das muss aber nicht so sein. Das kann man konfigurieren, wie man möchte. Man kann zum Beispiel sagen, das die Blockgeräte für externe Geräte einem selber gehören sollen oder auch einem speziellen User. Damit kann man darauf gparted und Co fahren ohne root sein zu müssen und ohne die Gefahr zu laufen, das man eine interne Festplatte versehentlich überschreibt.

3. Ich hatte extra "bis 4 GiB" geschrieben.

Ja. Aber auch unter 4GB macht FAT16 nur begrenzt Sinn weil Du einfach zu viel Verschnitt durch die Clustergröße hast. FAT16 stammt aus der Mitte der 80er Jahre und ist dementsprechend auch für Datenträgergrößen optimiert, die damals üblich und absehbar waren. Und das ist alles ganz weit weg von 4GB. Schon FAT32 funktioniert in dem Bereich nicht wirklich gut (aus den selben Gründen).
Das einzige, womit man FAT32 noch verargumentieren kann ist die Kompatibilität. Es kann halt plattformübergreifend problemlos gelesen werden. Denn selbst der billigste Multifunktionsdrucker mit USB-Anschluss kann irgendwie FAT32.

4. ext4 ist schlecht

Dafür hätte ich gerne ne Begründung und nicht nur einfach ne Behauptung.

und ohne Journaling erst recht. Für Sicherungsplatten würde ich es dann ganz bestimmt nicht einsetzen

Journaling schützt Dich nicht vor Datenverlust oder so. Journaling dient in erster Linie dazu das wenn man dem Dateisystem im laufenden Betrieb der Saft abgedreht wird, das Du keine langwierige Konsistenzprüfung machen musst. Man kann Journaling auch für mehr einsetzen, aber dann wirds wirklich langsam.

und für Sticks ist f2fs das mit Abstand schnellste FS, wenn man kein Journaling braucht.

Ja. Wenn man Geschwindigkeit haben will ist das vermutlich ne ziemlich gute Wahl.
Bei ext4 schwingt noch so ein wenig der FAT32-Faktor mit. Nämlich Kompatibilität. Man muss halt gucken, was man braucht und je nach dem entscheiden.

Was soll an xfs Overkill sein?

Naja. XFS ist schon ausgelegt für größere Dateisysteme. Das nicht nicht gegen die Verwendung von XFS. Mich wundert nur, das XFS mit reingenommen wird aber ext4 hingegen nicht. Ich vermute mal persönliche Präferenzen was ja auch ok ist. Aber sachlich begründen lässt sich das halt schlecht.

Das ist schnell, schlank

Die Behauptung das ext4 signifikant langsamer ist würde ich so nicht unwidersprochen stehen lassen. Also selbst wenn man jetzt Journaling einschaltet.
Schlank ist es ganz gewiss nicht. Der Codeumfang von xfs ist fast zweieinhalb-fach so groß wie der von ext4

sehr robust und einfach zu warten.

Ich kann mich nicht daran erinnern, das mir jemals schon mal ein ext(2/3/4)-Dateisystem abgeraucht ist.

 

[Caramon2]

Entschuldigung, dass ich jetzt erst antworte. Ich habe momentan nervigen Mist am Hals.

Blockgeräte sind unter Linux/Geräte die "blockweise" angesprochen werden. Typisches Beispiel sind eben Festplatten oder auch einzelne Partitionen. Blockgeräte landen wie alle Geräte im Verzeichnis /dev
So ist /dev/sda1 zum Beispiel das Blockgerät für die erste Partition der ersten Festplatte.
Da das letztlich normale Dateien sind, lassen sich damit natürlich auch die normalen UNIX-Rechte benutzen. Teilweise wird das auch genutzt. Zum Beispiel für die Grafikkarte (der Kram liegt in der Regel unter /dev/dri). Die Karte gehört oft der Gruppe video. Dadurch können alle User die der Gruppe video angehören auf die Grafikkarte zugreifen, was z.B. wichtig ist wenn man X.org oder Wayland benutzt.

Soweit war mir das bekannt.

Die Blockgeräte für die Festplatten gehören i.d.R. root (weshalb man auch für gparted, mkfs etc. überhaupt root-Rechte braucht). Das muss aber nicht so sein. Das kann man konfigurieren, wie man möchte. Man kann zum Beispiel sagen, das die Blockgeräte für externe Geräte einem selber gehören sollen oder auch einem speziellen User. Damit kann man darauf gparted und Co fahren ohne root sein zu müssen und ohne die Gefahr zu laufen, das man eine interne Festplatte versehentlich überschreibt.

Hmm.

1. Wie kann man es einstellen, dass Blockgeräte für externe Geräte automatisch einem selber gehören?

2. Wenn man den falschen ext. Datenträger erwischt (z. B. ext. Sicherungsplatte statt Stick), kann man trotzdem wichtiges löschen. - Muss man dagegen "sudo" nutzen, sollte man spätestens durch die Passwortabfrage daran erinnert werden, dass man sicher sein sollte, das richtige Laufwerk angegeben zu haben.

2b. Ubuntu-Derivate haben die lästige Eigenschaft, die Laufwerke zu würfeln: Ich habe 2 int. SSDs, die normalerweise sda und sdb sind. Schließe ich ein ext. Laufwerk (SSD, Platte) an, bekommt es sdc, aber wenn ich reboote, ist es (zumindest an allen PCs, an denen ich das getestet habe) plötzlich sda und die internen Laufwerke rutschen einen nach hinten: Da kann man schnell das falsche Laufwerk erwischen. Insbes. wenn man eine vorherige Befehlszeile nochmal nutzt.

3. habe ich das nur für diesen Thread so umgesetzt: Mein Benutzer gehört auch der Gruppe "disk" an, so dass ich z. B. zum formatieren von ntfs und fat kein "sudo" brauche. - Andererseits kann ich so aber auch mit einem einfachen "echo > /dev/sda" mein Systemlaufwerk plätten: Ich bin mir dessen bewusst und auch, dass ich dann nur die Partitionstabelle wiederherstellen muss.

Ich werde es so lassen wie es ist. Das erscheint mir sicherer, als das man ext. Laufwerke einfach so partitionieren und formatieren kann.

Ja. Aber auch unter 4GB macht FAT16 nur begrenzt Sinn weil Du einfach zu viel Verschnitt durch die Clustergröße hast. FAT16 stammt aus der Mitte der 80er Jahre und ist dementsprechend auch für Datenträgergrößen optimiert, die damals üblich und absehbar waren. Und das ist alles ganz weit weg von 4GB. Schon FAT32 funktioniert in dem Bereich nicht wirklich gut (aus den selben Gründen).
Das einzige, womit man FAT32 noch verargumentieren kann ist die Kompatibilität. Es kann halt plattformübergreifend problemlos gelesen werden. Denn selbst der billigste Multifunktionsdrucker mit USB-Anschluss kann irgendwie FAT32.

FAT wird um so langsamer, je mehr Cluster es hat.

Ein gutes Beispiel sind meine Sat-Receinver (Xoro): Auf Stick funktioniert die Aufnahme auf FAT mit 64k Cluster am besten. Nur dann funktionieren HDTV-Aufnahmen ohne Aussetzer und Ruckler. NTFS kackt da total ab.

Aber schon beim löschen einer Aufnahme ist die Clustergröße relevant: Damals hatte ich zuerst einen 16 GB Stick, der standardmäßig (auch vom Receiver) mit 8k Cluster formatiert wurde. - Löschte ich eine mehrere GB große Aufnahme, dauerte das z. B. 20 Sek. Mit 16k Cluster dauerte das löschen einer gleich großen Aufnahme nur noch 10 Sek., bzw. das löschen einer doppelt so großen Aufnahme dauerte dann 20 Sek. - Also wie lange das löschen gedauert hat, hing ausschließlich von der Anzahl der belegten Cluster ab. Wie große diese waren, war unerheblich.

Das gleiche beim Aufnahmestart: Bei 8k dauerte es mehrere Sek. nach dem drücken auf Aufnahme, bevor tatsächlich aufgenommen wurde und mit 16k nur halb so lang.

Egal wie, 64k ist bei FAT immer die beste Wahl.

Dass man damit bei sehr vielen, sehr kleinen Dateien einen großen "Verschnitt" hat, ist klar. Aber dafür ist FAT (einschließlich exFAT) sowieso das falsche Dateisystem.

Übrigens auch für Livesysteme (Unetbootin, YUMI, Ventoy, usw.) ist FAT mir 64k Cluster die beste/schnellste Wahl: Ich habe hier z. B. für Notfälle einen 4 GB Stick mit den aktuellen (deutschen) LinuxMint-Xfce und Artix-Xfce-Ruinit (passen beide gut drauf) und die Ventoy-Partition habe ich natürlich mit fat16-64k formatiert.

Dafür hätte ich gerne ne Begründung und nicht nur einfach ne Behauptung.

Hatte ich doch geschrieben: Ein auf einem USB-Stick installiertes Linux ist mir ext4 unzumutbar langsam. Im Gegensatz zu xfs mit noatime.

Einen anderen drastischen Unterschied hatte ich beim Tests mit einer Sicherungsplatte: Ich sichere mein System per "rsync -vaxH" in ein leeres Verzeichnis und gebe per "--link-dest=" die vorherige Sicherung an, so dass unveränderte Dateien als Hardlink übernommen werden: Das spart viel Platz und Zeit und trotzdem ist jede einzelne Sicherungsstufe (ich hatte auf 20 Stufen limitiert - die älteste wird vorher gelöscht) vollständig (ca. 80 GiB) und unabhängig von allen anderen wiederherstellbar.

Das habe ich mit "rsync -vaxH" auf eine baugleiche Platte (1 TB Toshiba 3,5") übertragen und anschließend mit "du -sBM" kontrolliert, wie viel Platz wirklich belegt wird:

Das übertragen aller Sicherungsstufen hat auf ext4 20 Min. gedauert, "du" hat dann aber 18 Min. gebraucht, um die Belegung der unmittelbar vorher kopierten Dateien zu ermitteltn.

Das selbe (unveränderte Quelle und Ziel frisch formatiert) auf xfs war beim kopieren zwar etwas langsamer "22 Min.) aber "du" war in unter 3 Min. fertig.

Auch das löschen der jeweils letzten Sicherungsstufe (also der erste Schritt vor jeder neuen Sicherung) dauerte auf ext4 deutlich länger als auf xfs. Die genauen Werte weiß ich nicht mehr, aber lange nicht so gravierend wie bei "du".

Journaling schützt Dich nicht vor Datenverlust oder so. Journaling dient in erster Linie dazu das wenn man dem Dateisystem im laufenden Betrieb der Saft abgedreht wird, das Du keine langwierige Konsistenzprüfung machen musst. Man kann Journaling auch für mehr einsetzen, aber dann wirds wirklich langsam.

Theoretisch. Praktisch habe ich das nie getestet.

Bei einer Sicherungsplatte mit hunderttausenden Dateien möchte ich auf Journaling jedenfalls nicht verzichten.

Ja. Wenn man Geschwindigkeit haben will ist das vermutlich ne ziemlich gute Wahl.
Bei ext4 schwingt noch so ein wenig der FAT32-Faktor mit. Nämlich Kompatibilität. Man muss halt gucken, was man braucht und je nach dem entscheiden.

Was unterstütz ext4, aber kein xfs? Beides sind Bestandteile des Kernels.

ext4 ist für mich eher wie Windows: Das wird nur genutzt, weil "alle" es nutzen. - Oder wie früher VHS.

Naja. XFS ist schon ausgelegt für größere Dateisysteme. Das nicht nicht gegen die Verwendung von XFS. Mich wundert nur, das XFS mit reingenommen wird aber ext4 hingegen nicht. Ich vermute mal persönliche Präferenzen was ja auch ok ist. Aber sachlich begründen lässt sich das halt schlecht.

Beim auf dem Stick installierten Linux war der Unterschied wirklich extrem: Mit ext4 blockierte das System alle Nase lang für bis zu 2 Min. (ich dachte zuerst immer, es hätte sich aufgehängt), selbst wenn man es sehr vorsichtig nutzte und immer abwartete, dass die Zugriffs-LED sich wieder beruhigte, mit xfs und noatime wurde es dagegen zwar immer, aber selbst wenn man es mutwillig provozieren wollte, blieb es nie hängen und sobald man dem Stick Zeit gelassen hat, mit allem fertig zu werden, konnte man es wieder in alter Frische nutzen.

Mit kam das damals so vor, wie Internet mit (xfs) / ohne (ext4) Traffic-Shaping, wenn man parallel eine große Datei hochlädt.

ext4 machte auf mich einen ziemlich minderwertigen Eindruck, der sich immer wieder bestätigt hat, egal wofür ich es nutzte.

Ich kann mich nicht daran erinnern, das mir jemals schon mal ein ext(2/3/4)-Dateisystem abgeraucht ist.

Abgeraucht nicht: Im Gegensatz zu btrfs ließ es sich bei Problemen reparieren, aber bei xfs ist eine Reparatur in vergleichbaren Situationen gar nicht erst nötig, da es sich beim einhängen selbst repariert.

xfs ist schnell, robust und auch von den Tools her machte es auf mich einen "schlanken" Eindruck: Als "straight forward" könnte man es m. E. auch beschreiben. Dass der Quellcode so groß ist, wusste ich nicht.

 

[andy_m4]

Entschuldigung, dass ich jetzt erst antworte. Ich habe momentan nervigen Mist am Hals.

Alles gut. Es ist keine Entschuldigung notwendig und gar eine Rechtfertigung.

Wie kann man es einstellen, dass Blockgeräte für externe Geräte automatisch einem selber gehören?

Das Device-Managment wird bei üblicherweise bei den meisten Linux-Distributionen heutzutage über udev abgewickelt. Das kümmert sich dann auch um das anlegen der entsprechenden Device-Nodes in /dev/
Es lassen sich dabei Regeln definieren, die auf spezifische Ereignisse reagieren können.
Die Konfigurationsdateien für diese Regeln liegen typischerweise im Verzeichnis
/etc/udev/rules.d

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.

Muss man dagegen "sudo" nutzen, sollte man spätestens durch die Passwortabfrage daran erinnert werden, dass man sicher sein sollte, das richtige Laufwerk angegeben zu haben.

Aber auch das kann man abbilden. Du kannst Dir ja auch einen entsprechenden Nutzer für solche Dinge anlegen. Der kann dann zwar USB-Sticks voll beschreiben. Dann hast Du ne Notwendigkeit ein Passwort einzugeben, aber kannst trotzdem immerhin keine internen Laufwerke überschreiben.

Ubuntu-Derivate haben die lästige Eigenschaft, die Laufwerke zu würfeln: Ich habe 2 int. SSDs, die normalerweise sda und sdb sind. Schließe ich ein ext. Laufwerk (SSD, Platte) an, bekommt es sdc, aber wenn ich reboote, ist es (zumindest an allen PCs, an denen ich das getestet habe) plötzlich sda und die internen Laufwerke rutschen einen nach hinten: Da kann man schnell das falsche Laufwerk erwischen. Insbes. wenn man eine vorherige Befehlszeile nochmal nutzt.

Das wäre ja eher ein Grund mehr da solche Sicherheitsmechanismen einzubauen.

3. habe ich das nur für diesen Thread so umgesetzt: Mein Benutzer gehört auch der Gruppe "disk" an, so dass ich z. B. zum formatieren von ntfs und fat kein "sudo" brauche.

Das ist eher eine schlechte Idee, weil wie Du ja selbst festgestellt hast führt das dazu, das Du auf alle Festplatten/USB-Sticks zugreifen kannst. Also auch die internen. Da ist es aus Sicherheitsperspektive sogar besser wenn Du es so machst wie vorher mit sudo und root.

An der Stelle aber noch mal etwas anderes:
Ich hab das Gefühl, ich komme etwas belehrend rüber. Das soll es gar nicht sein. Ich gebe lediglich Dinge wieder, die mir auffallen und/oder wozu ich Input geben möchte. Wenn jemand das nicht so machen möchte oder das anders sieht, dann ist das durchaus ok.

Ein gutes Beispiel sind meine Sat-Receinver (Xoro)

Solche Geräte sind sowieso immer mit Vorsicht zu genießen. Die Firmware ist meist nicht die Beste. NTFS würde ich da vermutlich gar nicht erst versuchen. Wenn Du da mit FAT16 die besten Erfahrungen gemacht hast, ok. Das spricht aber weder für noch gegen FAT16 im Allgemeinen, sondern erst mal nur für FAT16 im Zusammenspiel mit diesem Gerät.
Und ich gucke eher auf den allgemeinen Bereich.

Dass man damit bei sehr vielen, sehr kleinen Dateien einen großen Verschnitt hat, ist klar.

Wobei gerade bei Video das ja nicht so dramatisch ist, da man ja eh mit großen Dateien hantiert. Da hätte ich bei FAT16 eher die Sorge das die maximale Dateigröße bzw. maximale Dateisystemgröße ein Problem ist.
Bei 16-Bit (MAX_INT=65535) ist selbst mit 64k-Clustern bei spätestens 4096MB Schluss.

Übrigens auch für Livesysteme (Unetbootin, YUMI, Ventoy, usw.) ist FAT mir 64k Cluster die beste/schnellste Wahl

Das FAT-Dateisystem (das gilt für alle Varianten außer ExFAT) hat natürlich den Vorteil das es extrem einfach ist. Und insbesondere dann, wenns vorwiegend um Readonly geht und bei Flash-Speicher ja noch hinzukommt, das die Zugriffszeit bei nahezu Null liegt, profitiert das natürlich von seiner Einfachheit enorm.
Insofern hab ich zu dem Szenario keine eigenen Erfahrungen, aber es klingt zumindest plausibel.

Hatte ich doch geschrieben: Ein auf einem USB-Stick installiertes Linux ist mir ext4 unzumutbar langsam. Im Gegensatz zu xfs mit noatime.

Ja. Das hattest Du geschrieben. Deckt sich aber nicht mit meinen Erfahrungen und deshalb bin ich darüber gestolpert.
Aber Danke für die genauen Angaben.

Bei einer Sicherungsplatte mit hunderttausenden Dateien möchte ich auf Journaling jedenfalls nicht verzichten.

Man darf sich halt nur nicht einem falschen Gefühl der Sicherheit hingeben und sollte sich klar darüber sein, was Journaling leisten kann und was nicht.

Was unterstütz ext4, aber kein xfs? Beides sind Bestandteile des Kernels.

Richtig. Wenn Du in der Linux-Welt bleibst, ist alles gut.
Unter anderen Systemen wirds dann aber sehr schnell dünn. ext4 kann ich z.B. out-of-box mit FreeBSD lesen/schreiben. Selbst für Windows gibts schon ne ganze Weile Treiber für die ext-Dateisysteme.

ext4 machte auf mich einen ziemlich minderwertigen Eindruck, der sich immer wieder bestätigt hat, egal wofür ich es nutzte.

Die ext-Dateisysteme waren nie meine Lieblingsdateisysteme. Sie sind nicht wirklich gut aber haben auch nicht wirklich Ausreißer nach unten. Die machen halt im Großen und Ganzen ihren Job.
Aus meiner Erfahrung kann ich also nichts wirklich Negatives sagen. Umso interessanter finde ich ja dann auch den Bericht über Deine Erfahrungen. Im Grunde genommen, wie es in einem solchen Forum ja auch sein sollte. Einen Erfahrungsaustausch zu haben.

 

[Caramon2]

Nur kurz, da ich mich mit udev erst noch beschäftigen muss:

"disk" nutze ich für kvm, um z. B. aus einer VM heraus ein BS nativ zu installieren: Das funktioniert sogar mit Win 10 und 11 und so spare ich mir, das ISO erst auf einen Stick zu kopieren und diesen zu booten. Oder ich boote testweise es BS in der VM, oder um aus meinem VM-XP ntfs-formatierte Datenträger zu überprüfen, Windows-Installation mit BootIce zu reparieren, usw. - Ich nutze das ständig.

Mit sudo und "runas=$USER" funktioniert das zwar auch, aber da ich nicht jedesmal das Pw eingeben will, müsste ich "qemu-system-x86_64" in sudoers eintragen: Da erscheint mir "disk" als das geringere Übel.

Da ich viel bastle und auch mal was daneben geht (aus Fehlern lernt man und ich beschäftige mich mit Linux, um viel zu lernen), sichere ich nach jeder gravierenden Änderung und nach gedem größeren Update, auf insgesamt 5 ext. Platten. Davon eine bei meiner Mutter, falls es hier mal so stürmt, wie vor einigen Jahren im knapp 20 km entfernten Minden, wo reihenweise Häuser abgedeckt wurden: Ich wohne hier in der Dachwohnung des höchsten Gebäudes im Umkreis.

 

[andy_m4]

"disk" nutze ich für kvm, um z. B. aus einer VM heraus ein BS nativ zu installieren: Das funktioniert sogar mit Win 10 und 11 und so spare ich mir, das ISO erst auf einen Stick zu kopieren und diesen zu booten.

Selbst für solche Fälle muss man ja nicht zwingend so vorgehen. Du kannst ja auch die Disk/Partition händisch via chown temporär übernehmen.
Ich finde es immer relativ kritisch die Gruppe disk auf die Art und Weise zu benutzen weil Deine Laufwerke quasi ungeschützt sind. Sämtliche Rechte die im Dateisystem implementiert sind können umgangen werden. Und es geht ja jetzt auch nicht nur um den Fall von Malware oder das man mal ein Blockgerät bei seinen Aktionen verwechselt. Auch Bugs können ja dann dazu führen, das man sein Laufwerk löscht oder (was noch wesentlich problematischer ist) das Änderungen vorgenommen werden, die unbemerkt bleiben.

Im Grunde soll man disk nicht benutzen aus dem gleichen Grund warum man root nicht benutzt.

Eigentlich ist es auch ursprünglich so vorgesehen das man für jede Aufgabe immer so wenig Rechte wie möglich und soviel wie nötig verwendet. Leider wird das zugunsten der Bequemlichkeit viel zu oft aufgeweicht. Leider sind da die meisten Distributionen eher suboptimal vorkonfiguriert. Da wird dann häufig sudo genutzt aber dann nur in der Form, das man sich damit root-Rechte besorgt. Dabei könnte man mit sudo viel kleinteiliges Management der benötigten Rechte machen. Es wird unter Linux viel gemacht, was man sonst immer Windows vorwirft. Nämlich das die Sicherheit der Bequemlichkeit geopfert wird.

Aber das auch wieder alles nur so Anmerkungen zu dem Thema. Da kann man verschiedener Meinung drüber sein.

 

[Caramon2]

Mit chown habe ich mich auch noch nicht beschäftigt, da es für mich so funktioniert, wie ich es nutze. Anderen empfehle ich das nicht, bzw. nur wenn sie wissen was sie tun: Nutzung auf eigene Gefahr.

Ich hatte das mit "disk" letztes Jahr im im Arch-Forum gefragt, aber das lief dann auf sudo mit runas hinaus. Ich habe es eine Zeit lang benutzt, aber wie oben geschrieben, fühle ich mich mit "disk" wohler.

 

[rgbs]

Ich erledige so Sachen wie USB Sticks formatieren mit GParted und ändere danach mit chown den Besitzer.

Gruß
R.G.

 

[andy_m4]

Mit chown habe ich mich auch noch nicht beschäftigt

Das ist ja jetzt eigentlich ein gängiges Kommando. Deswegen wundere ich mich jetzt so ein bisschen, das der für Dich neu zu sein scheint. :-)

Ich erledige so Sachen wie USB Sticks formatieren mit GParted

Und wie löst Du das Problem, mit dem "nicht ausversehen formatieren einer internen Festplatte"?

 

[rgbs]

Also wenn man trotz der ganzen Infos, welche man bei GParted erhält, im "falschen Haus" landet, sollte man so Sachen wie Formatieren besser lassen.

Gruß
R.G.

 

[Caramon2]

Das ist ja jetzt eigentlich ein gängiges Kommando. Deswegen wundere ich mich jetzt so ein bisschen, das der für Dich neu zu sein scheint. :-)

Sorry, da hatte ich total das Brett vom Kopf: Natürlich kenne ich chown! - Irgendwie war ich der Meinung (ohne weiter darüber nachzudenken) dass das irgendein spezieller Befehl wie chroot wäre: Bei dem habe ich im Ubuntuusers-Wiki nicht mal verstanden, wozu der überhaupt gut ist.

Im Arch-Wiki ist chroot viel besser beschrieben und mit Arch-Version davon konnte ich eine nicht mehr bootende Arch-Installation reparieren.

Bzgl. Gparted:

Daran stört mich, dass das pauschal an 1 MiB ausrichtet, anstatt die Partitionierung an der Clustergröße auszurichten, wie es mein Skript macht.

Außerdem muss man bei Gparted ausrichten an nichts wählen, damit die Partition wirklich bis zum Ende des Datenträgers geht (vorne fängt sie trotzdem bei 1 MiB an), was bei GPT zu einer Fehlermeldung führt, da Gparted dabei die Kopie der Partitionstabelle am Ende nicht berücksichtigt.

Btw:

Auch interne Datenträger müssen ggfs. Partitioniert und formatiert werden: Die will ich gar nicht pauschal ausschließen.

Auch habe ich das Skript so übersichtlich gehalten, damit man auch einfach Teile daraus für eigene Skripte verwenden kann, oder man darin auch einfach nachsehen kann, wie man z. B. f2fs formatiert, wenn man das manuell im Terminal machen will.

Nicht zuletzt für mich selbst: Ich schreibe nicht ständig irgendwelche Skripte und wenn ich z. B. mal wieder irgendwas mit der case-Funktion machen will, sehe ich mir einfach in diesem Skript an, wie das funktioniert.

Meine Skripte sind sozusagen auch Nachschlagewerke für mich selbst und für jeden anderen, der sich damit beschäftigen möchte.

 

[andy_m4]

Genau. chroot ist eigentlich ein Namespace-Konzept. Kann man im Prinzip auch nehmen. Man macht einen eigenen "Container" auf und mappt da nur die Devices rein, auf die man zugreifen können soll. :-)

Daran stört mich, dass das pauschal an 1 MiB ausrichtet, anstatt die Partitionierung an der Clustergröße auszurichten, wie es mein Skript macht.

Wobei dies eigentlich kein großes Problem ist. Du verlierst zwar minimal Speicherplatz, aber völlig unbedeutend angesichts der heute üblichen Speichergrößen.
Übrigens ist wesentlich für ein Alignment das man sich an der Blockgröße des Devices orientiert. Also wenn Du jetzt eine Clustergröße von 512 Bytes hast aber das Gerät mit physikalischen 4k-Blöcken/Sektoren arbeitet ist das eher ungünstig.
Das haut jetzt mehr oder weniger zufällig hin, weils praktisch keine Geräte gibt die ne Blockgröße >64kb haben. :-)

Auch interne Datenträger müssen ggfs. Partitioniert und formatiert werden: Die will ich gar nicht pauschal ausschließen.

Es geht auch gar nicht ums ausschließen. Gerade bei der Lösung über die Rechtevergabe kannst Du ja das Skript überall verwenden, sofern Du nur vorher explizit die Rechte freigegeben hast.

 

[Caramon2]

Wobei dies eigentlich kein großes Problem ist. Du verlierst zwar minimal Speicherplatz, aber völlig unbedeutend angesichts der heute üblichen Speichergrößen.

Mich stört das: Wieso sinnlos fast ein ganzes MiB verschwenden?

Wenn ich z. B. bei ntfs (4k Cluster) die Partition schon nach 4k beginnen lasse, ist das das gleiche Alignment, wie wenn der ganze Datenträger (also ohne Partitionierung) formatiert wird. - Der erste "Cluster" wird dann eben für die Partitionstabelle reserviert.

Gleiches bei 64k Cluster und Partitionsstart nach 64k.

In einer früheren Version des Skipts hatte ich sogar eingebaut, dass man bei FAT die Clustergröße angeben konnte und dann wurde auch entsprechend partitioniert, aber das habe ich wieder entfernt, da FAT mit kleineren Clustern als 64k kontraproduktiv ist. Das hatte ich ja schon beschrieben.

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.

*) besonders Livesysteme von Ubuntu-Derivaten können da echt nerven, da man dort uid/gid999 hat. - Deshalb nutzte ich, als ich noch LinuxMint nutzte, immer ein fat32-Stick als Zwischenspeicher (zw. Livesystem und installiertem BS), da das kein gid/uid speichern kann: Ich habe das outlaw-Dateisystem genannt.

 

[rgbs]

chown != chmod

Gruß
R.G.

 

[Caramon2]

chown != chmod

Was willst du damit sagen?