udev- und udisk2-Regeln (z. B. für ntfs3)

Caramon2

Lieutenant
Registriert
Jan. 2004
Beiträge
627
Alles als root durchführen:

Damit ntfs3 automatisch genutzt wird, "/etc/udev/rules.d/99-ntfs3.rules" erstellen:
Code:
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3" , ENV{UDISKS_FILESYSTEM_SHARED}="0"
Das mit "udevadm control -R" übernehmen (oder reboot).

Für besondere Mountoptionen "/etc/udisks2/mount_options.conf" erstellen/bearbeiten:
Code:
[defaults]

defaults=noatime
allow=exec,noexec,nodev,nosuid,atime,noatime,nodiratime,relatime,strictatime,lazytime,ro,rw,sync,dirsync,noload,acl,nosymfollow

ntfs3_defaults=uid=$UID,gid=$GID,noacsrules,discard
ntfs3_allow=uid=$UID,gid=$GID,umask,dmask,fmask,iocharset,nohidden,sys_immutable,discard,force,sparse,showmeta,prealloc,noacsrules,acl

btrfs_defaults=compress-force=zstd
btrfs_allow=compress,compress-force,datacow,nodatacow,datasum,nodatasum,autodefrag,noautodefrag,degraded,device,discard,nodiscard,subvol,subvolid,space_cache
"noatime" setze ich als Standard, da atime m. E. nur unnütz bremst/Schreibzugriffe durchführt.

"noacsrules" bewirkt, dass keine speziellen Rechte genutzt werden, so dass es z. B. zu keinen Zugriffsproblemen kommt, wenn ein anderer Nutzer etwas erstellt hat.

"discard" für SSDs (wird bei anderen Laufwerken ignoriert): Online-Discard, da ntfs3 weiterhin (Kernel 5.16.3) kein fstrim unterstützt und deshalb nicht regelmäßig (durch cronjob, systemd-timer) getrimmt werden kann.

Wichtig: Wenn man z. B. mit einem anderen Gerät, dass kein Online-Discard nutzt (in meinem Fall ein Sat-Receiver), von einer ext. SSD etwas löscht, wird der davon belegte Bereich nicht freigegeben. Deshalb lösche ich nur noch am PC.

Alternativ kann man sie zum trimmen manuell mit ntfs-3g mounten und fstrim nutzen. - Oder sie mit wiper.sh (von hdparm) trimmen: Das funktioniert auch ohne ntfs-3g, ist aber umständlicher.

btrfs nutze ich höchstens wegen der Dateikomprimierung und dann mit "compress-force=zstd", da standardmäßig nur getestet wird, ob sich der Anfang der Datei gut komprimieren lässt und sie unkomprimiert gespeichert wird, wenn nicht: Das ist viel zu ineffizient.
 
Zuletzt bearbeitet: (Tippfehler: w*h*iper.sh)
  • Gefällt mir
Reaktionen: octra
Ich glaube die Thematik ist zu technisch für dieses Forum. Du musst irgendeine Distribution bezüglich ihrer Eignung für Spiele untersuchen. Da kriegst Do sofort hundertfach Feedback. :-)
 
  • Gefällt mir
Reaktionen: Caramon2
Ich bevorzuge Qualität statt Quantität. ;)

Da ich mich als versierter Laie sehe (ich weiß genug, um einschätzen zu können, dass ich sehr viel noch nicht weiß), schreibe ich das nicht nur um anderen zu helfen, sondern auch um selbst etwas zu lernen und für neuen Input. - Immerhin war es dein Tipp bzgl. udev in dem anderen Thread, der mir den Anstoß dazu gab, mich endlich damit zu beschäftigen.

Hier hatte ich das zu ntfs3 übrigens gefunden:

https://askubuntu.com/questions/137...he-default-settings-for-mounting-ntfs-disks-w

https://aur.archlinux.org/packages/ntfs3-dkms?O=10&PP=10
Performance tips:
noatime option can speed up filesystem operations.
prealloc option reduces disk fragmentation (useful for HDD).

Alle Mountoptionen: https://www.kernel.org/doc/html/v5.15-rc6/filesystems/ntfs3.html

Bzgl. trimmen:

Zum gelegentlichen offline-discard habe ich mir schon letztes Jahr (ntfs3 (obiges AUR) nutze ich schon seit letzten Februar) das Skript "ntfsclean" geschrieben (als ausführbar markieren und in den Pfad kopieren):
Code:
#!/bin/bash
if [ $# == 0 ];then echo "ntfsclean /dev/sd??";exit;fi
umount -l /dev/sd$1 2>/dev/null
sudo ntfswipe -dlmpt /dev/sd$1
sudo mount -t ntfs-3g /dev/sd$1 /mnt/
sync;sleep 1;echo
sudo fstrim -v /mnt/
sync;sleep 1
sudo umount -l /mnt/
(z. B. "ntfsclean b1" für /dev/sdb1)

Vorher lasse ich u. a. die undel-Daten löschen (s. https://man.archlinux.org/man/ntfswipe.8 ), da nach dem trimmen ja sowieso nichts gelöschtes mehr da ist, was wiederhergestellt werden kann. - Das hält die Liste übersichtlich, wenn man etwas noch nicht getrimmtes wiederherstellen muss.

"ntfswipe" nutze ich schon seit vielen Jahren regelmäßig: U. a. um das Win10 eines Nachbarn vor der Sicherung mit "ntfsclone" zu bereinigen, um die Sicherung möglichst klein zu halten. Dabei kam es noch nie zu Problemen.



Mit wiper.sh kann man ntfs3 auch eingehängt trimmen:
Code:
mount|grep ntfs
/dev/sdb1 on /ntfs type ntfs3 (rw,nosuid,nodev,noexec,noatime,uid=1000,gid=1000,iocharset=utf8,discard,noacsrules,user=user)

sudo wiper.sh --commit /ntfs/
[sudo] Passwort für andreas: abc123 ;-)

wiper.sh: Linux SATA SSD TRIM utility, version 3.6, by Mark Lord.
Preparing for online TRIM of free space on /dev/sdb1 (ntfs3 mounted read-write at /ntfs).

This operation could silently destroy your data.  Are you sure (y/N)? y
Allocating temporary file (49729704 KB)..
Syncing disks..
Beginning TRIM operations..

/dev/sdb:
trimming 33553920 sectors from 512 ranges
succeeded
trimming 33503302 sectors from 512 ranges
succeeded
trimming 32402186 sectors from 503 ranges
succeeded
Removing temporary file..
Syncing disks..
Done.
Mit der Option "--please-prematurely-wear-out-my-ssd" umgeht man die Sicherheitsabfrage. - Die Option wird nicht kommuniziert: Ich habe in wiper.sh nach "--" gesucht.

Ich bin gestern Abend auf die Aussage gestoßen, dass "fstrim" die Trim-Funktion des Kernels nutzt (die es bei ntfs3 noch nicht gibt) und dass es mit "wiper.sh" trotzdem funktioniert, weil das über hdparm direkt aufs Laufwerk zugreift.

Wiper.sh habe ich in den letzten Jahren nur ein paar Mal genutzt: Zu Datenverlusten ist es dabei nicht gekommen und auch im Internet bin ich auf keine entsprechenden Meldungen gestoßen.

Es scheint also sicher zu sein und die Warnung eher ein Relikt aus längst vergangener Zeit, als besonders Samsung-SSD dabei sehr Fehleranfällig waren.
 
  • Gefällt mir
Reaktionen: andy_m4
Um ntfs3-Partitionen (z. B. ext. SSD - s. o.) manuell (per RMB/Trimmen) trimmen zu können:

"~/.local/bin/trim.sh" erstellen (und als ausfühbar markieren):
Code:
#!/bin/bash
sync -f .
sudo wiper.sh --commit --please-prematurely-wear-out-my-ssd . && espeak-ng check! || espeak-ng fail
"sync -f ." schreibt den Schreibcache der betreffenden Partition, damit beim trimmen alles abgeschlossen ist.

Für die vebale Ausgabe braucht man "espeak-ng" (und Lautsprecher ;) ), ansonsten kann oben " && espeak-ng check! || espeak-ng fail" weg. - Alternativ kann man auch "libnotify" installieren und "espeak-ng" durch "notify-send" ersetzen.

Dann eine benutzerdefinierte Aktion erstellen (Xfce/Thunar):
Code:
Tab "Allgemein":
  Name:   Trimmen
  Befehl: ~/.local/bin/trim.sh
  Synbol: edit-clear

Tab "Dateizuordnung":
  Dateimuster: *
Erscheint … :  Odner

Und zuletzt die "wiper.sh" in "/etc/sudoers" hinzufügen (z. B. mit "sudo EDITOR=nano visudo"), damit für "sudo wiper.sh …" keine Passworteingabe benötigt wird (Pfad ggfs. anpassen):
Code:
%wheel ALL=(ALL) NOPASSWD:/usr/bin/wiper.sh
Dazu muss man der Gruppe "wheel" angehören, was normalerweise Standard ist (mit "id" kontrollieren).

Das habe ich inzwischen schon ein paar mal bei unterschiedlichen Laufwerken und Dateisystemen (xfs und ntfs3) gemacht, ohne dass es zu Beschädigungen oder Datenverlusten gekommen ist. Da ich schon vorher diesbzgl. nichts im Internet gelesen habe, scheint das also sicher zu sein.

Nachtrag:

Da mir das trimmen per RMB/Trim langsam erschien, habe ich das mit einer leeren, ntfs-formatierten 120 GB BX500 im USB-Gehäuse getestet (jeweils den 2. Versuch gewertet):
  • mit ntfs-3g gemountet und mit fstrim getrimmt: 4,2s
  • dto. nur mit wiper.sh getrimmt: funktioniert nicht (this kernel (der 5.16.7) may not support 'fallocate' on a fuseblk filesystem)
ntfs3 lässt sich nur mit wiper.sh trimmen:
  • ohne "discard" gemountet: 2,2s
  • mit "discard" gemountet: 4,1s
  • nicht gemountet: 7,2s (dafür wird übrigens ein installiertes ntfs-3g benötigt, sonst kommt die Meldung, dass "ntfsinfo" nicht gefunden wird)
Ich vermutet, dass es mit "discard" doppelt getrimmt wird:

Es wird eine Daten über den ganzen freien Bereich erstellt, was davon belegt ist per "hdparm" getrimmt und wenn die Datei anschließend gelöscht wird, der Bereich nochmal von der "discard"-Option getrimmt.

Also bräuchte man bei gesetzter "discard"-Option zum trimmen eigentlich "nur" diese Datei erstellen und gleich wieder löschen.

Da ich aber nicht weiß wie man das macht, habe ich "discard" in der /etc/udisks2/mount_options.conf bei ntfs3 entfernt, so dass ext. SSDs nur per RMB/Timmen getrimmt werden. So kann ich am Sat-Receiver beliebig Aufnahmen erstellen und löschen: Wenn ich sie das nächste Mal am PC habe, einfach RMB/Timmen, fertig. :)

Bei der ntfs-Partition auf der internen SSD (benötige ich als Zwischenspeicher beim Videoschnitt mit einem Windows-Programm) lasse ich "discard" dagegen gesetzt:
Code:
UUID=(UUID des Partition) /ntfs ntfs3 noatime,noacsrules,discard,noauto,user 0 0
"noauto,user" damit ich sie im Autostart als normaler Nutzer (egal welcher Nutzer) mounten kann und sie so mit den richtigen UID/GID eingehängt wird.
 
Zuletzt bearbeitet:
Moin! :)

Obwohl es zwar keine Probleme mit wiper.sh gegeben hat, war mir unwohl dabei, Partitionen mit wichtigen Daten (= alles außer NTFS) damit zu trimmen.

Heute Morgen hatte ich beim aufwachen eine Idee, wie ich beides kombinieren kann:
Code:
#!/bin/bash
sync -f .
sudo fstrim . || sudo wiper.sh --commit --please-prematurely-wear-out-my-ssd . && espeak-ng check! || espeak-ng fail
Bei RMB/Trimmen wird zuerst mit fstrim getrimmt und wenn das nicht funktioniert wiper.sh genutzt.

Funktioniert eins von beiden, ertönt "check!", ansonsten "fail".

Wieder was gelernt… :)
 
Caramon2 schrieb:
Für besondere Mountoptionen "/etc/udisks2/mount_options.conf" erstellen/bearbeiten:
Code:
[defaults]

defaults=noatime
allow=exec,noexec,nodev,nosuid,atime,noatime,nodiratime,relatime,strictatime,lazytime,ro,rw,sync,dirsync,noload,acl,nosymfollow

btrfs_defaults=compress-force=zstd
btrfs_allow=compress,compress-force,datacow,nodatacow,datasum,nodatasum,autodefrag,noautodefrag,degraded,device,discard,nodiscard,subvol,subvolid,space_cache
Das habe ich neulich auch bei Zorin 15.3 gemacht, aber es wurde nicht angenommen, obwohl "noatime" und sogar "compress-force=zstd" bei btrfs sich per "mount -o …" problemlos nutzen lässt.

Das gleiche bei einer Gegenkontrolle mit Zorin 16, so dass ich vermute, dass Ubuntu und Derivate das generell nicht annehmen (weshalb auch immer).

Wie es bei anderen Distributionen aussieht, weiß ich nicht. Ich nutze Artix-Xfce-Runit: Ein Arch-Derivat ohne SystemD.

Kontrollieren kann man das einfach indem man eine Partition normal über die Dateiverwaltung öffnet (einhängt) und dann im Terminal "mount|grep noatime" ausführt: Da mit obigem bei allen Dateisystemen "noatime" gesetzt wird (statt standardmäßig "relatime"), müsste das gefunden werden.
 
Caramon2 schrieb:
Das habe ich neulich auch bei Zorin 15.3 gemacht, aber es wurde nicht angenommen, obwohl "noatime" und sogar "compress-force=zstd" bei btrfs sich per "mount -o …" problemlos nutzen lässt.

Das gleiche bei einer Gegenkontrolle mit Zorin 16.1, so dass ich vermute, dass Ubuntu und Derivate das generell nicht annehmen (weshalb auch immer).
Dto. bei LinuxMint 19.3 und 20.3, Elementary OS 6.1 und sogar Solus 4.3, obwohl das ja viel aktueller ist, als jedes Ubuntu und -Derivate.

Ich dachte schon, es würde an meinem zugemüllten, ehemaligen Testsystem liegen, das ich seit letztes Jahr als Produktsystem nutze: Dass es durch irgendwas, was ich dort schon alles installiert habe/hatte, aktiviert wurde, aber auch bei einer frischen Artix-Installation funktionierte es auf Anhieb.

Auch bei LinuxMint Debian-Edition 4 funktionierte es nicht, aber bei LMDE5: Neben Artix die einzige getestete Installation, die das angenommen hat.

Wobei ich davon ausgehe, dass es bei jedem Arch und -Drivat (einschließlich Manjaro) funktionieren wird. Aber ansonsten ist es offebar Glückssache, was ich nicht erwartet hätte.
 
Zurück
Oben