Habe gerade udev-usb-sync deinstalliert und erneut installiert. Nun scheints zu funzen wie man erwarten sollte. Hoffe das bleibt jetzt so. Hat echt genervt dieses ewige warten auch wenn der Fortschrittsdialog schon längst geschlossen war … wo ist da die Logik?
auch an @Michi
Geht das denn nun insgesamt aus irgendeinem Grunde schneller -
oder stimmt nur die Fortschrittsanzeige genauer mit der tatsächlichen Schreibgeschwindigkeit überein?
Ich würde ja eher auf das zweite tippen … also eher kosmetischer Natur
weiß es aber nicht, weshalb ich frage.
This is just a repackage to fix some inconsistencies in file headers.
Nothing changed with functionality.
Translation
Dies ist lediglich eine Neuverpackung, um einige Inkonsistenzen in den Dateikopfzeilen zu beheben.
An der Funktionalität hat sich nichts geändert.
A) Die Fortschrittsanzeige stimmt überein.
B) Nach Abschluss der Fortschrittsanzeige, wird nicht mehr im Hintergrund noch übertragen.
Es ist nicht schneller, sondern akkurater. Ich verweise mal auf die Zusammenfassung:
Bei 1GB und 4-6MB/s Übertragung dauert es ca. 50-70 Sekunden länger, aber man kann es sofort abstöpseln und muss nicht noch sync
eingeben oder ewig warten, denn ohne einen forcierten sync
dauert es noch länger.
Nein, er meinte die neue Version 0.9, die im Gegensatz zu 0.8 funktioniert.
Na gut, danke!
Hätte mich auch gewundert, wenn so die tatsächliche Schreibgeschwindigkeit auf ein USB Gerät steigen würde.
Nein, ich meinte tatsächlich nicht eine spezielle Version, sondern ob sich an der insgesamt benötigten Zeit was ändert oder ob nur die Fortschrittsanzeige in einem grafischen Dateimanager besser mit der Realität übereinstimmt.
Die zum Schreiben der Daten auf den USB-Stick benötigte Zeit ist mit oder ohne Paket gleich.
Was sich bei Verwendung des Pakets ändert, ist, wann Sie den USB-Stick entfernen können und ob Sie auf die Synchronisierung warten müssen oder nicht.
Ohne das Paket müssen Sie warten, bis die Synchronisierung abgeschlossen ist.
Mit dem Paket ist das Kopieren abgeschlossen und Sie können den Stick fast sofort entfernen, wenn es fertig ist.
Man könnte sagen: Wir verlangsamen den Computer, um ihn der menschlichen Wahrnehmung anzupassen.
Above is a translation using lingva.ml
The time taken to write the data to the usb stick the same with or without the package.
What changes when using the package is when you can remove the usb stick and whether you need to wait for sync or not.
Without the package you must wait for sync to complete.
With the package when the copy is done it is done and you can almost immediately remove the stick.
One could say - we slow the computer down to fit human perception.
Thank you!
Danke!
This is what I meant with: “eher kosmetischer Natur”
which roughly means: it’s now more “what we see is what we get”
Das ist, was ich mit “eher kosmetischer Natur” meinte.
Die Geschwindigkeit habe ich nicht gemessen.
Ich weiß nur, dass jetzt, mit dem tool, alles viel problemloser geht. Wenn ich, z.B. nur den Namen eines Videos auf dem Stick ändere, dann ist der Vorgang jetzt sehr schnell abgeschlossen und ich kann ihn fast sofort entfernen. Das ist prima.
Ich finde es einfach vollkommen unplausibel und sogar gefährlich in Hinblick auf Datenverlust, wenn der Fortschrittsbalken nicht dem tatsächlichen Fortschritt entspricht und nach dem Schließen des Kopieren-Dialogs bei großen Dateien, z.B. Linux-ISOs noch immer auf das Medium geschrieben werden.
Ich hab mir damit in der Vergangenheit schon ein paar ISOs zerschossen.
Zu früh gefreut der alte Krampf ist immer noch da: Fortschrittsdialog ist geschlossen aber bei “Sicher entfernen” geht die Warterei wieder von vorne los … was macht denn thunar da? Bezieht sich die Fortschrittsanzeige nur auf den cache mit 1,7 MB/s . Mir ist das alles unverständlich, Nemo probieren ?
könnte es sein, dass noch eine Anwendung (Thunar oder etwas anderes) auf den Stick zugreift?
Tumbler maybe? locate tumbler.rc
and check it, maybe disable thumbnails on videos, or external usb drives?
Jetzt hab ich es mit Midnight commander im Terminal probiert: keine Besserung bei “sicher entfernen”
Was für ein Gezerre!
Welche Werte bekommst du hier raus @JohnML ?
Auch: “Sicher entfernen” funktioniert nur, wenn nichts mehr darauf zugreift. Ein Terminal oder Datei-Manager, das den Einhängepunkt offen hat, blockiert das Aushängen aus Sicherheitsgründen.
A) Habs gerade mal unter Fedora 40 probiert. Da wird etwas ehrlicher ewig “noch 0 Sekunden” angezeigt.
B) Habe aber auch einen grottenlahmen USB-Stick
C) Zu deinen Fragen:
USB Stick ist laut lsblk:
/dev/sdb1: LABEL=“Ventoy” UUID=“5048-2E5E” BLOCK_SIZE=“512” TYPE=“exfat” PARTUUID=“735166d7-01”
grep . /sys/block/sd*/bdi/{max_bytes,max_ratio,strict_limit}
grep: /sys/block/sd*/bdi/max_bytes: Datei oder Verzeichnis nicht gefunden
/sys/block/sda/bdi/max_ratio:100
/sys/block/sdb/bdi/max_ratio:100
grep: /sys/block/sd*/bdi/strict_limit: Datei oder Verzeichnis nicht gefunden
Werds später noch mal unter Win 10 probieren …
Ganz klar: keine Begrenzung. Scheinst Linux v5 oder darunter zu verwenden. Da kann man das nur auf max. 1% des gesamten RAMs heruntersetzen. Erst ab v6.1 geht das akkurat. Aber normal sollte da nicht 100, sondern 1 stehen… Sind das wirklich USB Geräte?
Versuch mal das:
sudo udev-usb-sync sda 480
sudo udev-usb-sync sdb 480
Und wieder:
grep . /sys/block/sd*/bdi/{max_bytes,max_ratio,strict_limit}
Ich habe Kernel 6.1
[john1@manjaro ~]$ sudo udev-usb-sync sda 480
sudo udev-usb-sync sdb 480
[sudo] Passwort für john1:
/dev/sda:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/usr/bin/udev-usb-sync: line 61: /sys/block/sda/bdi/strict_limit: Permission denied
/dev/sdb:
setting drive write-caching to 0 (off)
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
write-caching = not supported
/usr/bin/udev-usb-sync: line 61: /sys/block/sdb/bdi/strict_limit: Permission denied
[john1@manjaro ~]$ uname -a
Linux manjaro 6.1.106-1-MANJARO #1 SMP PREEMPT_DYNAMIC Mon Aug 19 10:07:05 UTC 2024 x86_64 GNU/Linux
[john1@manjaro ~]$ grep . /sys/block/sd*/bdi/{max_bytes,max_ratio,strict_limit}
grep: /sys/block/sd*/bdi/max_bytes: Datei oder Verzeichnis nicht gefunden
/sys/block/sda/bdi/max_ratio:100
/sys/block/sdb/bdi/max_ratio:100
grep: /sys/block/sd*/bdi/strict_limit: Datei oder Verzeichnis nicht gefunden
[john1@manjaro ~]$
Ich geh jetzt erst mal im Park ne Runde flitzen, danach probier ich Win 10. Habe ausserdem noch schnellere USB-Sticks
The script cannot be run with sudo - if you want to run from terminal you need a root terminal using su
Das Skript kann nicht mit sudo ausgeführt werden. Wenn Sie es vom Terminal aus ausführen möchten, benötigen Sie ein Root-Terminal mit su
.
//EDIT
To my understanding, the max_bytes
and strict_limit
is only supported with kernels newer than 6.2.
And a comment I misses last time is that strict_limit
has no effect if max_ratio
is 100%.
I have modified the script to account for the kernel minor version as well.
German translation
Meines Wissens werden max_bytes
und strict_limit
nur mit Kerneln neuer als 6.2 unterstützt.
Und ein Kommentar, den ich beim letzten Mal übersehen habe, ist, dass strict_limit
keine Wirkung hat, wenn max_ratio
100 % beträgt.
Ich habe das Skript geändert, um auch die Nebenversion des Kernels zu berücksichtigen.
//EDIT
We did some rework of kernel detection rule - to identify minor version. Package is at v0.12.
Wir haben die Kernel-Erkennungsregel überarbeitet, um Nebenversionen zu identifizieren. Das Paket liegt bei v0.12.
Die Fortschrittsanzeige ist jetzt ehrlich geworden, wenn sie sich schliesst ist das kopieren wirklich beendet … Danke für das heutige update von udev-usb-sync (0.9-3 → 0.11-1)
@linux-aarhus
Wird das Skript optional bleiben oder zukünftig in Manjaro integriert werden?
Will the script remain optional or will it be integrated into Manjaro in the future?