fstab für usb-hdd / freigabe

Probleme mit Samba, NFS, FTP und Co.
Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: fstab für usb-hdd / freigabe

Beitrag von MSfree » 04.06.2022 14:25:21

miriki hat geschrieben: ↑ zum Beitrag ↑
04.06.2022 13:29:09
Das ist schade, aber es gibt ja vielleicht einen anderen Mechanismus? Wie gesagt: Mir ging es nicht um umask an der Konsole für die Session, sondern als Option in der fstab für das Device.
umask wirkt in der Login-Session für alle Programme, die unter deinem Namen laufen. Da Linux nunmal aus der Welt der Mehrbenutzer- und Serverbetriebssysteme stammt, ist es auch völlig normal, daß Rechte benutzerbezogen sind. Folglich ergeben solche Einstellungen für Dateisysteme (in der fstab) auch keinen Sinn und sowas ist auch nicht vorgesehen. Finde dich damit ab, daß es keine Brechstange für dein Problem gibt. umask ist das beste, was man dir auf der Konsole und im graphischen Login auf der Linuxseite bieten kann.

Setzen kannst du das in deiner Profildatei (.profile).
Naja, auf diesem Gerät speziell dann doch wohl schon, oder? Mit 0111 verhindere ich dann doch grundsätzlich ein "x" für die Files
Nicht nur für Dateien sondern auch für Verzeichnisse. Und Verzeichnisse ohne Execute-Bit darf man nicht betreten. Ergo ergibt eine umask 0111 keinen Sinn. Linuxprogramme legen Dateien aber sowieso immer ohne Execute-Bit an, so daß man das nicht maskieren muß.
Mit 0022 kann ich ja Files als 755 erstellen, womit der Besitzer ausführbare Files erzeugen kann,
Nein, neu erstellte Dateien werden nicht ausführbar erzeugt. Ausnahmen bilden hier nur Compiler, weil die Ergebnisse Programme sind, die ausführbar sein müssen.
Ich bin schon am Überlegen, wenn es mit dem Samba force mode 0666 doch noch mal irgendwie klappt, ob ich die Platte lokal nicht auch über Samba mounten kann. Dann würde ich das erreichen, was ich mir vorstelle mit den Rechten.
Für Samba lies bitte mal das hier, vielleicht erhellt das dein Verständnis.
https://blog.jonaspasche.com/2010/11/24 ... tevergabe/

Für die Linuxseite mußt du nur die umask auf 0000 setzten, dann hast du immer neu erstellte Dateien, die für jeden les- und schreibbar sind. Es hat aber schon einen Sinn, warum man 0022 nimmt. Damit sind neu erstellte Dateien zumindest schreibgeschützt ausser für dich, so daß kein anderer Benutzer sie versehentlich oder mutwillig manipulieren kann.

Und falls es noch nicht klar ist, vorhandene Dateien werden weder durch smb.conf noch von umask in ihren Rechten verändert. Eine Brechstange auf Dateisystemebene gibt es nicht.

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 04.06.2022 23:17:12

MSfree hat geschrieben: ↑ zum Beitrag ↑
04.06.2022 14:25:21
miriki hat geschrieben: ↑ zum Beitrag ↑
04.06.2022 13:29:09
Wie gesagt: Mir ging es nicht um umask an der Konsole für die Session, sondern als Option in der fstab für das Device.
umask ist das beste, was man dir auf der Konsole und im graphischen Login auf der Linuxseite bieten kann. Setzen kannst du das in deiner Profildatei (.profile).
Siehst selber, oder?
Naja, auf diesem Gerät speziell dann doch wohl schon, oder? Mit 0111 verhindere ich dann doch grundsätzlich ein "x" für die Files
Nicht nur für Dateien sondern auch für Verzeichnisse.
Ja, ok, da hab ich einmal nicht ausführlich genug geschrieben... Es geht neben umask auch um fmask für Files und dmask für Verzeichnisse. (Und parallel dazu ggf. auch um umode, fmode und dmode). Diese Optionen gibt es, nur eben wohl nicht für ext4, in der fstab.

Sagte ich schon, dass es um die Optionen in der fstab geht, nicht um die User-Session?
Für Samba lies bitte mal das hier, vielleicht erhellt das dein Verständnis.
https://blog.jonaspasche.com/2010/11/24 ... tevergabe/
Welches Verständnis meinst Du, das mir noch fehlen würde? Ich schrieb zu Samba doch bereits, dass ich es mit

Code: Alles auswählen

create mask 0666
directory mask = 0777
force create mode = 0666
force directory mode = 0777
force group = miriki
force user = miriki
eingestellt habe. So sollte ich nur Files mit min/max 0666 erhalten. Und nu?

Ok, jetzt wird aus welchem Grund auch immer trotzdem ein File mit 0766 erzeugt, dem muss ich noch auf die Schliche kommen.

Bis dahin behelfe ich mir mit einem Shell-Script, dass ich von Zeit zu Zeit aufrufe:

Code: Alles auswählen

#!/bin/bash
cd /media
find ./usb -type f -print0 | xargs -0 sudo chmod -c 666
find ./usb -type d -print0 | xargs -0 sudo chmod -c 777
Letztendlich ist das eine Brechstange... ;-)

Gruß, Michael

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: fstab für usb-hdd / freigabe

Beitrag von Tintom » 05.06.2022 17:31:35

miriki hat geschrieben: ↑ zum Beitrag ↑
04.06.2022 23:17:12

Code: Alles auswählen

#!/bin/bash
cd /media
find ./usb -type f -print0 | xargs -0 sudo chmod -c 666
find ./usb -type d -print0 | xargs -0 sudo chmod -c 777
Letztendlich ist das eine Brechstange... ;-)
...und auch gleichzeitig die Begründung warum du für ext*-Dateisysteme keine Mountoption (u|f|d)mask finden wirst :THX:

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 05.06.2022 17:59:44

heisenberg hat geschrieben: ↑ zum Beitrag ↑
03.06.2022 18:01:56
PS: Das mit dem gemeinsamen Zugriff würde ich wohl über Gruppen in Verbindung mit dem bisher besprochenen regeln.
Yup, ich denke, ich werde sowas wie eine Gruppe "smbshare" o.s.ä. einrichten. Dort wird dann miriki Miglied und später die anderen dann auch, wenn's soweit ist. In der smb.conf kann ich die Gruppe für neue Files erzwingen. Aber wenn im Linux miriki:miriki erzeugt wird, muss ich ja trotzdem noch (nachträglich) eingreifen und auf miriki:smbshare ändern, wenn's unterhalb /media/usb ist, oder?

Gruß, Michael

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: fstab für usb-hdd / freigabe

Beitrag von heisenberg » 07.06.2022 11:00:47

Ein paar Gedanken dazu noch:
miriki hat geschrieben:Aber wenn im Linux miriki:miriki erzeugt wird, muss ich ja trotzdem noch (nachträglich) eingreifen und auf miriki:smbshare ändern, wenn's unterhalb /media/usb ist, oder?
miriki:miriki ist verallgemeinert: <USERNAME>:<PRIMARY_GROUP_NAME>, d. h. durch Veränderung die primäre Gruppe Deines Benutzers ändert sich auch die Gruppe beim anlegen von Dateien und Verzeichnissen. Ist die Frage, ob man das für sein Home-Verzeichnis will, dass da eine Samba-Gruppe darauf Zugriff hat, selbst wenn kein Share auf das Home-Verzeichnis zeigt.

Setzen des set-Group-ID Bits auf einem Verzeichnis

Das sorgt dafür, dass neu erstellte Dateien und Verzeichnisse die Gruppe dieses Verzeichnisses und das set-Group-ID Bit übernehmen. In Verbindung mit einer passenden umask (z. B. 0002).

Zugriff vom Linux-Rechner via Samba

Man könnte auch über den Linux-Rechner nicht lokal auf die USB-Festplatte zugreifen, sondern über einen lokalen Samba- bzw. CIFS-Mount. Dann geht alles über Samba, d. h. über den gleichen Kanal. Allerdings ist Samba teilweise viel langsamer als ein direkter Festplattenzugriff.

Zum Entwickeln von Verständnis

Der Gedanke, den ich bei den Sätzen von MSfree hatte: Es macht recht wenig Sinn, wenn man irgendwo in einem neuen Thema ist, eine Vorstellung davon zu entwickeln, wie es zu laufen hätte und was nach dem eigenen Denken richtig ist. In dem Fall hier: Man muss die Einstellung in der fstab setzen und wenn das nicht geht ist das Mist. Viel sinnvoller erscheint mir: Ich versuche erst einmal zu verstehen, was in dem System alles möglich ist und nutze dann die Möglichkeiten, um meine Ziele zu erreichen. Die Wahrscheinlichkeit, dass zum einen alles Mist ist, woran zahlreiche intelligente Menschen gearbeitet haben ist eher gering. Wenn doch etwas fehlt, dann hat dies meist seine Gründe, warum es noch niemand umgesetzt hat.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 07.06.2022 23:34:48

Jetzt, ja jetzt... ich glaube, wir haben's!
heisenberg hat geschrieben: ↑ zum Beitrag ↑
07.06.2022 11:00:47
miriki:miriki ist verallgemeinert: <USERNAME>:<PRIMARY_GROUP_NAME> [ . . . ] ob man das für sein Home-Verzeichnis will, dass da eine Samba-Gruppe darauf Zugriff hat, selbst wenn kein Share auf das Home-Verzeichnis zeigt.
Nope, eher nicht. Dürfte klar sein...

Ich änder mal die Zitat-Reihenfolge:
Zugriff vom Linux-Rechner via Samba
[ . . . ] nicht lokal auf die USB-Festplatte zugreifen, sondern über einen lokalen Samba- bzw. CIFS-Mount.
Yup, und genau das hatte ich seinerzeit mit einem RasPi genau so gemacht (und hatte es weiter oben auch geschrieben, also nicht das mit dem RasPi, aber das mit lokalem Samba). Beim RasPi war mir allerdings die Geschwindigkeit weitestgehend egal. Es wurden i.a. nur Files mit wenigen KB erzeugt oder wenige KB an eine Datei angehängt, und das auch nicht im Sekundentakt. Jetzt mit dem ThinkCentre ist mir die Geschwindigkeit etwas wichtiger. Ich habe aber noch nicht ausprobiert, ob mir die "lokale Samba" reicht. Das würde ich erst, wenn es nicht mehr 0766 anlegt, obwohl 0666 in der cfg steht.
Setzen des set-Group-ID Bits auf einem Verzeichnis
Das sorgt dafür, dass neu erstellte Dateien und Verzeichnisse die Gruppe dieses Verzeichnisses und das set-Group-ID Bit übernehmen.
Jetzt wird's interessant! Ich meinte auch, dass ich mal dieses "inherit" genutzt hatte, früher, in grauen Vorzeiten. Ich wusste nur nicht mehr, unter welchem System. Das kann unter Uralt-Linux (SuSE zu Kernel 0.9 Zeiten), NT-Server oder sogar OS/2 gewesen sein. Aber das scheint ja dann doch Linux gewesen zu sein. Ich hätte auch nicht mehr dran gedacht, wenn Du es jetzt nicht erwähnt hättest. Ich glaube, ich hatte das mal mit einem "public user" Verzeichnis, allerdings auf der lokalen Platte, gemacht.

Schade, dass dieser Weg trotz meiner Frage nach "oder einer alternativen Methode" erst jetzt kommt. Aber besser spät als nie! Es wäre doch (fast) genau das erreicht, was ich suche, wenn ich das Verzeichnis am Mount-Point entsprechend setze, um alle darunter erzeugten Dirs/Files dann in eine Gruppe zu zwängen. Dann kann ich doch auch eigentlich die Optionen in der smb.conf weg lassen, oder? Mir egal, ob drölfundneunzig verschiedene User Files erstellen, solange die nur alle in der gleichen Gruppe sind und dann untereinander die Files bearbeiten können.

Das macht dann auch meine "Brechstange" überflüssig. Die empfinde ich übrigens nicht als Begründung, sondern eher als Entschuldigung. ;-)
In dem Fall hier: Man muss die Einstellung in der fstab setzen und wenn das nicht geht ist das Mist.
Nope, das hast Du dann falsch verstanden. Mir ging es um das Ergebnis, Files (und Dirs) mit entsprechenden Rechten zu erstellen bzw. zu lassen. Die fstab war nur mein erster Anlaufpunkt, weil zumindest bei anderen Dateisystemen genau dort genau dieser Mechanismus existiert. Wäre ich nicht wegen grottenschlechter Geschwindigkeit von ntfs auf ext4 gewechselt, hätte ich diese Frage hier wahrscheinlich nie gestellt.

Was nur "Mist" ist, wenn ich dann nur Hinweise auf CLI / Login / User-Session bekomme, und gleich mit dem Zusatz, dass das (auch) nicht funktioniert und ich es nicht (so) nutzen kann. "Ich würde gerne (a) kaufen. - Ah, nun, (b) sind aber viel schöner! Wir haben auch gerade keine (a) vorrätig (lässig an (ä) gelehnt)" ;-)

Und jetzt probier ich mal das mit dem Gruppen-Zwang aus... ;-)

Gruß, Michael

gusi
Beiträge: 26
Registriert: 14.10.2020 08:56:58

Re: fstab für usb-hdd / freigabe

Beitrag von gusi » 19.06.2022 23:08:33

ALSO
Wenn auch von Windows Daten drauf müssen, kommt eig, nur NTFS in Frage
da kannst das Rechte-system eh vergessen , ist alles farce auf ntfs in Linux

"big_writes" parameter ntfs3-g, dann wird das Schreiben 5 X schneller,
Beim Automount gibts diesen Parameter nicht, automount =schnecke
diesen parmeter gibts bei dem neuen Driver ntfs3 nicht mehr, der ist von Haus aus schnell

Verbinden per Label , wer merkt sich eine ID ???
nofail, damit der pc nicht stehen bleibt, wenn die USB nicht einsteckt

ftab-eintrag , volles Schreib- Leserecht für alle ntfs

LABEL=Mein-Stick /mnt/Sticki auto big_writes,umask=0000,users,auto,exec,noatime,nofail 0 0

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: fstab für usb-hdd / freigabe

Beitrag von MSfree » 20.06.2022 08:10:35

gusi hat geschrieben: ↑ zum Beitrag ↑
19.06.2022 23:08:33
Wenn auch von Windows Daten drauf müssen, kommt eig, nur NTFS in Frage
Nein, genau das ist eben nicht richtig. Die Windowseite bekommt ohnehin nicht mit, welches Dateisystem sich auf der Serverseite befindet und auf der Linuxseite ist NTFS nur ein Fremdkörper, den man mehr schlecht als recht ansprechen kann.

gusi
Beiträge: 26
Registriert: 14.10.2020 08:56:58

Re: fstab für usb-hdd / freigabe

Beitrag von gusi » 20.06.2022 09:56:58

Das ist natürlich richtig, so lange ein win-Client nur übers Netz zugreift,

Ich muss ehrlich gestehen, das ich Ext4 aber nur für die Linux-System Partition einsetze.
Ich hab ja auch ne Start-partition mit Windows , dann isses eben kein Netz-Zugriff mehr.#
Oder wie in deinem Falle hab ich auch mehrere UBS-Disks bis 4 TB gross.
Damit bräuchte ich aber gar nicht erst bei Freunden antanzen, um denen was unter Windows
zu installieren, wenn sie Ext4 oder br..fs , xfs wären.
Von meinen ganzen Bekannten bin ich der einzige mit Linux.
Überzeugt bin ich von NTFS gar nicht, gerade die DE-Fragmentierung ist unter Ext4 fast ausgeschlossen.
deswegen, bleibt so eine Platte auch schnell.
Aber man ist halt auf einer Insel , Linux, Marktanteil auf PC/Laptop = 3%

DeletedUserReAsG

Re: fstab für usb-hdd / freigabe

Beitrag von DeletedUserReAsG » 20.06.2022 12:10:22

gusi hat geschrieben: ↑ zum Beitrag ↑
19.06.2022 23:08:33
"big_writes" parameter ntfs3-g, dann wird das Schreiben 5 X schneller,
Beim Automount gibts diesen Parameter nicht, automount =schnecke
Einerseits sollte man heute eh den Kerneltreiber nehmen, der ist je nach Umständen noch deutlich mehr als 5x schneller, als der ntfs-3g-FUSE-Treiber, andererseits sollte man den üblichen Automountern sehr wohl Mountoptionen mitgeben können.

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 28.06.2022 08:58:25

gusi hat geschrieben: ↑ zum Beitrag ↑
19.06.2022 23:08:33
"big_writes" parameter ntfs3-g, dann wird das Schreiben 5 X schneller,
Den müsste ich nochmal testen, hab ich schon woanderes drüber gelesen. Es sei denn...
diesen parmeter gibts bei dem neuen Driver ntfs3 nicht mehr, der ist von Haus aus schnell
... deswegen brauch ich's nicht mehr.

Allerdings schwirrt mir etwas der Kopf bei den FS-Bezeichnern.

Also ich hab bislang 'ntfs' und 'ntfs-3g' (in der fstab) probiert. Beide machten auf den ersten Blick keine grossen Unterschiede.

Mit 'ntfs3' und 'ntfs3-g' hatte ich bislang noch keinen Erfolg. Welches Paket muss ich dazu installieren? Und was ist mit 'ntfs-fuse-3g'?
Verbinden per Label , wer merkt sich eine ID ???
Verbinden per /dev/sdxx ist hier blöd, weil alle Nase lang ein oder zwei USB-Sticks mit ins Spiel kommen und sich dadurch die Reihenfolge verschieben kann. Aber einmalig die UUID auslesen ist ja kein Drama.
nofail, damit der pc nicht stehen bleibt, wenn die USB nicht einsteckt
Unbedingt... Und noatime, um weitere Zugriffe einzusparen.

Was aber wohl absolut dringend wichtig zwingend ist: async - Ohne das Ding komm ich auf 50 kB/s (ja, k, wirklich!) Schreib, auch wenn das Ding bei 120 MB/s Lese hat. Mit async lieg ich bei 75..95 MB/s Schreib. Allerdings hab ich ein ungutes Gefühl bei async und externer, jederzeit abzupfbarer, HDD. Werd ich wohl mit leben müssen...
ftab-eintrag , volles Schreib- Leserecht für alle ntfs
LABEL=Mein-Stick /mnt/Sticki auto big_writes,umask=0000,users,auto,exec,noatime,nofail 0 0
Nicht unbedingt sehr ähnlich: ;-)

Code: Alles auswählen

UUID=82E01A41E01A3C3B   /media/public   ntfs-3g   rw,suid,dev,noexec,auto,nouser,async,nofail,noatime,uid=65534,gid=129,dmask=0000,fmask=0111,fmode=0666,dmode=0777   0   0
Dazu für Samba:

Code: Alles auswählen

[public]
  path = /media/public
  public = yes
  writeable = yes
  comment = public
  printable = no
  guest ok = yes
  create mask = 0111
  directory mask = 0000
  create mode = 0666
  directory mode = 0777
  force create mode = 0666
  force directory mode = 0777
  force group = sambashare
  force user = nobody
Damit bekomme ich dann:

Code: Alles auswählen

drwxrwxrwx 1 nobody sambashare 4096 28. Jun 07:48 .
drwxr-xr-x 5 root   root       4096 26. Jun 17:00 ..
drwxrwxrwx 1 nobody sambashare    0 28. Jun 07:48 miriki.dir
-rw-rw-rw- 1 nobody sambashare    2 28. Jun 07:48 miriki.txt
drwxrwxrwx 1 nobody sambashare    0 28. Jun 07:48 root.dir
-rw-rw-rw- 1 nobody sambashare    2 28. Jun 07:47 root.txt
drwxrwxrwx 1 nobody sambashare    0 28. Jun 07:35 win10.dir
-rw-rw-rw- 1 nobody sambashare    4 28. Jun 07:35 win10.txt
bzw.

Code: Alles auswählen

28.06.2022  07:48    <DIR>          miriki.dir
28.06.2022  07:48                 2 miriki.txt
28.06.2022  07:48    <DIR>          root.dir
28.06.2022  07:47                 2 root.txt
28.06.2022  07:35    <DIR>          win10.dir
28.06.2022  07:35                 4 win10.txt
wobei win10* über Samba von remote erstellt wurden. Auf Grund der fstab-Parameter brauche ich wahrscheinlich die ganzen Einstellungen nicht mehr in der smb.conf, but hey...

Und ich sag ja: Hätte ich die andere Platte nicht von ntfs auf ext4 umformatiert, hätte ich die ursprüngliche Frage dieses Threads hier nie gestellt. Denn ntfs auf dieser Platte erzeugt, wenn ich nicht noch was übersehen hab, ganz genau das, was ich mir vorgestellt (und auch in der Vergangenheit schon etliche male realisiert) habe: Files mit 0666 (und Dir mit 0777), bei denen mir dann auch Besitzer oder Gruppe prinzipiell egal sein kann.

Aber ext4 kriegt das nicht hin. Dort wird mir ein File von remote mit 0766 statt der gewünschten 0666 erstellt (woher auch immer das x kommt). und lokal kriegt ein File 0644 statt 0666, was die Benutzung für andere User verhindert. Zwar kriegen sie durch GUID ab Mountpoint abwärts alle die gleiche Gruppe, aber das alleine reicht ja nicht. Und das Gefrickel mit User anlegen und Gruppen zuweisen, im Linux selbst oder im Samba, wollte ich mir schon gerne sparen.
Oder wie in deinem Falle hab ich auch mehrere UBS-Disks bis 4 TB gross.
Damit bräuchte ich aber gar nicht erst bei Freunden antanzen, um denen was unter Windows
zu installieren, wenn sie Ext4 oder br..fs , xfs wären.
Von meinen ganzen Bekannten bin ich der einzige mit Linux.
Bei mir sind's allesamt 2TB, aber den Rest unterschreibe ich Wort für Wort.

Gruß, Michael

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: fstab für usb-hdd / freigabe

Beitrag von Tintom » 28.06.2022 11:52:38

miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 08:58:25
Mit 'ntfs3' und 'ntfs3-g' hatte ich bislang noch keinen Erfolg. Welches Paket muss ich dazu installieren? Und was ist mit 'ntfs-fuse-3g'?
Du verwendest gerade den ntfs-3g. Für ntfs3 brauchst du einen neueren Kernel. In Bullseye ist Kernel 5.10 enthalten, ntfs3 ist aber erst seit 5.19 im Kernel. Aber ob es das Wert ist? Wir reden hier über eine ext. USB-HDD, die Schreib- und Leseraten sehen für mich in Anbetracht der Situation ganz okay aus.

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 28.06.2022 12:45:58

Tintom hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 11:52:38
ntfs3 ist aber erst seit 5.19 im Kernel.
Ah, danke, alles klar. Also so:
ntfs (alt)
ntfs-3g (neu)
ntfs3 (später)

Und diese "fuse"-Treiber? Was sind das für welche und welchen Eintrag hätten die in der fstab? Oder woran erkenne ich die sonst?
die Schreib- und Leseraten sehen für mich in Anbetracht der Situation ganz okay aus.
Yup, bin damit auch eigentlich erstmal zufrieden. Bei weniger als 20 MB/s würd's mich dann doch stören. Aber so geht's erstmal. Ich bin nur etwas zwiespältig mit dem 'async' bei ext. hdd einerseits, der unterirdisch grottenschlechten Schreibrate bei 'sync' andererseits. Da aber speziell diese Platte für den fast durchgehenden ( > 95% ) Gebrauch als Mount am Linux dient, ist das erstmal ok.

Gruß, Michael

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: fstab für usb-hdd / freigabe

Beitrag von heisenberg » 28.06.2022 13:00:49

Ich bin nur etwas zwiespältig mit dem 'async' bei ext. hdd einerseits, der unterirdisch grottenschlechten Schreibrate bei 'sync' andererseits. Da aber speziell diese Platte für den fast durchgehenden ( > 95% ) Gebrauch als Mount am Linux dient, ist das erstmal ok.
Du schreibst, dass Du das problematisch für den Fall ansiehst, dass man die USB-Platte einfach mal so abzieht. Das sollte man unter keinen Umständen tun. Eine Platte muss immer sauber via unmount ausgehängt werden. Ansonsten ist mit Datenverlust zu rechnen.

async ist der default und das ist gut so. Das überlässt "Linux" die Entscheidung die Daten effizient auf den Datenträger zu schreiben. Datenintegrität ist durch den umount gewährleistet.

Ansonsten(man kann das nicht oft genug wiederholen): Synchrones schreiben auf Flashspeicher verkürzt die Lebensdauer des Speichers.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: fstab für usb-hdd / freigabe

Beitrag von Tintom » 28.06.2022 13:40:48

miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 12:45:58
Und diese "fuse"-Treiber? Was sind das für welche und welchen Eintrag hätten die in der fstab? Oder woran erkenne ich die sonst?
FUSE steht für Filesystem-in-Userspace. Normalerweise arbeitet ein Kernelmodul (wie es der Name vermuten lässt) im Kernelspace (also: auf Ebene des Kernels). Problem: Dafür muss das Modul überhaupt im Kernel sein und viele Softwareprojekte schaffen es erst gar nicht erst in den Kernel aufgenommen zu werden aus verschiedenen Gründen (Codequalität, Lizenzprobleme, ...). Ein Dateisystem kann aber nur durch den Kernel in das System eingebunden werden. Um das zu Umgehen nutzt man FUSE, hier mit dem Kernelmodul fuse.ko, welches das Bindeglied zwischen Kernel- und Userspace ist. Dadurch wird das, was normalerweise auf Ebene des Kernels stattfindet in das Userland verlagert. Mit ntfs-3g hast du bereits ein solches FUSE-Modul am Laufen. Die Module ntfs und ntfs3 sind klassische Kernelmodule. Nebenbei gibt's eine Reihe weiterer ganz außergewöhnlicher FUSE-Module, auf die ein Blick lohnt. Ich persönlich finde z.B. noch Debianfuse-zip schön, so lässt sich ein ganzes ZIP-Archiv als Dateisystem einbinden.
miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 12:45:58
der unterirdisch grottenschlechten Schreibrate bei 'sync' andererseits.
Das liegt in der Natur der Sache. Die Option async verwendet Zwischenspeicher, so kann eine wesentlich höhere Datenrate erreicht werden, während sync jedes Bit direkt auf den Datenträger speichert. Der Einbruch der Performance rührt daher, weil die Festplatte für jeden Schreib- und Lesevorgang neu positioniert werden muss. Ohne Zwischenspeicher können währenddessen keine anderen Schreib- und Lesezugriffe stattfinden mit der Folge, dass die Schlange an zu schreibenden und zu lesenden Informationen immer länger wird. Dein Gedanke ist nicht verkehrt, sync ist ja gerade für solche Anwendungsfälle gedacht, wo ein Dateisystem plötzlich durch unsachgemäße Trennung vom System in einen inkonsistenten Zustand geraten kann. Die Realität ist aber, dass man async benutzt (ist sowieso die Standardoption), hofft das nichts passiert und das Medium anschließend sauber aushängt. :wink:

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 28.06.2022 18:02:59

Tintom hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 13:40:48
Mit ntfs-3g hast du bereits ein solches FUSE-Modul am Laufen. Die Module ntfs und ntfs3 sind klassische Kernelmodule.
Ach... Na denn... Ist ja nur, weil ich an einigen Stellen von "diesen #X!M@xGr Treibern für FUSE" gelesen hatte. Klang nicht nett, nicht freundlich.

Aber nochmal die Nachfrage: Woran erkennt man diese FUSE Treiber? Oder ist "apt show" durchlesen die einzige Möglichkeit? Ich hätte ja einen Paketnamen wie "ntfs-3g-fuse" o.s.ä. erwartet.
Debianfuse-zip schön, so lässt sich ein ganzes ZIP-Archiv als Dateisystem einbinden.
So, wie Windows die Zip-Archive als Unterverzeichnis behandelt? Da ich mit Zip und Lzh auf der DOS-CLI aufgewachsen bin (u.a. als SysOp einer BBS), war mir das immer zu suspekt. Ich entpacke, bearbeite und packe ggf. lieber, nach wie vor. ;-)
miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 12:45:58
der unterirdisch grottenschlechten Schreibrate bei 'sync' andererseits.
Das liegt in der Natur der Sache.
Naja, jein... ;-)

Klar ist Schreiben langsamer als Lesen, ggf. auch deutlich langsamer. Und klar ist Schreiben mit Cache wieder deutlich schneller. Aber schreiben mit 50 kB/s (also: ohne Cache), das ist indiskutabel. Da wäre ich ja mit ISDN schneller, das als FAX zu versenden. (Naja, ok, nicht ganz, fehlt aber auch nicht viel...)

Die baugleiche 2TB Seagate mit ext4 auf "sync" gemountet schreibt noch mit knapp 20 MB/s. Das ist schon relativ wenig mit 17% der Lese-Geschwindigkeit, finde ich, aber damit kann ich ggf. noch leben.

Unter Windows ist der Cache für "removable" Medien per se ausgeschaltet. Dort erreiche ich aber trotzdem i.a. um die 75% der Lese-Geschwindigkeit beim Schreiben. Der eine oder andere ältere USB-Stick, den ich habe, erreicht auch mal "nur" 30%. Aber wir reden hier eher von eher 0,04% <-- das meine ich mit indiskutabel.
dass man async benutzt (ist sowieso die Standardoption), hofft das nichts passiert und das Medium anschließend sauber aushängt. :wink:
Yup, darauf wird's wohl hinauslaufen.

Aber danke für die Info!

Gruß, Michael

miriki
Beiträge: 108
Registriert: 19.05.2022 10:49:21
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Kiel

Re: fstab für usb-hdd / freigabe

Beitrag von miriki » 28.06.2022 18:27:09

heisenberg hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 13:00:49
Du schreibst, dass Du das [ sync/async ] problematisch für den Fall ansiehst, dass man die USB-Platte einfach mal so abzieht. Das sollte man unter keinen Umständen tun. Eine Platte muss immer sauber via unmount ausgehängt werden. Ansonsten ist mit Datenverlust zu rechnen.
Das ist schon klar. Aber die Realität... Da liegt eine Platte "offen" herum. Daneben liegt ein USB-Hub "offen" herum. Der Hub hat unter dem Tisch noch ein Netzteil in der Steckdose, kann man noch "offen" nennen. Der Hub hat Schalter für jeden einzelnen Port, ganz "offen". Und alle diese Punkte können dazu führen, dass die Platte "schwupps, mal eben" off geht - nicht gewollt, ganz und gar nicht.
Ansonsten(man kann das nicht oft genug wiederholen): Synchrones schreiben auf Flashspeicher verkürzt die Lebensdauer des Speichers.
Tja, nun ist das hier aber eine HDD, keine SSD. Und unter Windows wird pauschal bei "removable" Medien kein Schreib-Cache aktiviert, also auch "sync" geschrieben. Deswegen ist die Hysterie, dass man den Stick immer erst "trennen" soll, weil man sonst in die Hölle kommt, dort auch reichlich übertrieben. Auch unter Windows ist ein quasi "umount" sicher und stilvoll, aber andererseits eigentlich nicht zwingend notwendig.

Aber egal... Ich denke, ich werde die ext4 wieder zu ntfs machen und dann eben mit async einhängen. Wird schon schief gehen... ;-)

. o O ( oder ich schau mir mal FAT an... Hmmm... )

Gruß, Michael

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: fstab für usb-hdd / freigabe

Beitrag von heisenberg » 28.06.2022 18:45:45

Das ist schon klar. Aber die Realität... Da liegt eine Platte "offen" herum. Daneben liegt ein USB-Hub "offen" herum.
Da ist Debianautofs vielleicht geschickter. Das hängt sich bei Inaktivität aus und automatisch wieder ein bei Zugriff. Ob das im Zusammenspiel mit Samba rumzickt weiss ich nicht.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: fstab für usb-hdd / freigabe

Beitrag von Tintom » 28.06.2022 21:09:53

miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 18:02:59
Ach... Na denn... Ist ja nur, weil ich an einigen Stellen von "diesen #X!M@xGr Treibern für FUSE" gelesen hatte. Klang nicht nett, nicht freundlich.
Einen Grund für diese Aussage hast du schon gefunden:
miriki hat geschrieben: ↑ zum Beitrag ↑
28.06.2022 18:02:59
Die baugleiche 2TB Seagate mit ext4 auf "sync" gemountet schreibt noch mit knapp 20 MB/s.
Die Performance von allen fuse-Modulen ist aus Prinzip schlechter als von klassischen Kernelmodulen, weil der Kernel inkl. dessen Module mit der höchsten Priorität laufen. Du könntest aus Spaß mal ext4-fuse mit klassischem ext4 als Kernelmodul vergleichen um valide Aussagen zu bekommen. Der Vergleich ntfs-3g (FUSE) mit ext4 (Kernel) hinkt etwas.

Antworten