Arch Linux ignoriert Mount-Flags

[mrshadowtux]

Moin,

hier mal ein interessanter Fall für alle Tuxer.

Ich habe in meiner fstab Mountflags für /dev/sda2 definiert. Dazu gehört auch das Flag discard, welches automatisch TRIMt.

Meine gesamte fstab sieht folgendermaßen aus (Swap brauch ich nicht):
/dev/sda2 / ext4 rw,noatime,discard 0 1


Schaue ich dann aber mal zur Kontrolle nach, sehe ich folgendes:
18:48 afeld@feldibook /home/afeld
% mount | grep -i sda2
/dev/sda2 on / type ext4 (rw,noatime,data=ordered)


Statt meinem gewünschten discard steht hier ein data=ordered, welches ich nie gesetzt habe. Ein sudo fstrim -v / zeigt mir außerdem, dass in der Tat nicht automatisch getrimmt wird.

Meine Frage daher: Warum zum Teufel wird die fstab knallhart ignoriert?

Vielen dank im Voraus für Antworten!

---

Bonus-Info:
Auch ein sudo mount /dev/sda2 / -o remount,rw,noatime,discard aktiviert das Flag nicht. Die SSD ist ein Samsung 850 Pro, die kann definitiv TRIM.

[tk1908]

Steht irgendwas im Journal?

[mrshadowtux]

Gerade mal nachgeschaut, nichts mount-spezifisches drin. Wie exportiert man das Journal-Dings als Datei? Dann häng ichs an.

[DosAmp]

Wenn laut tune2fs -l discard bereits zu den im Superblock definierten Standard-Mount-Flags gehört, was bei einem auf einer SSD angelegten Dateisystem vermutlich der Fall ist, wird es nicht angezeigt, auch wenn es explizit angegeben wird. Das ist ein "Feature" des Kernels.

Dass fstrim auch bei aktivem discard nach einem Neustart und etwas Benutzung ein paar Gigabyte getrimmte Daten anzeigt, ist normal, zumal das Queued TRIM auf Samsung-SSDs kaputt ist (kann zu Datenkorruption führen) und daher auf Linux deaktiviert ist. Sie unterstützen nur synchrone TRIM-Befehle, die alle anderen ATA-Befehle und daher I/O-Operationen kurzzeitig aufhalten – was Samsung-Entwickler bisher nicht weiter gestört hat, weil Windows nichts anderes unterstützt.

data=ordered bezieht sich nur auf den standardmäßigen Commit-Modus, der Daten erst schreibt und dann im Journal als geschrieben ablegt. Ein solches Flag (alternativ data=writeback oder data=journal) wirst du immer unter den Mount-Optionen finden.

EDIT: Das ist ein primitiver Test (der direkt den Sektor von der Platte liest), der überprüft, ob TRIM funktioniert:
https://nedoboi.wordpress.com/2011/11/12...-it-works/

[mrshadowtux]

Danke für die fundierte und detailierte Antwort, das wusste ich noch nicht. Interessant, dass der Kernel das versteckt und einen so verwirrt.

Bedeutet der Samsung-Bug, dass ich lieber auf discard verzichten und fstrim per Cronjob machen sollte?

EDIT: Habe den Test gerade durchgeführt, discard scheint tatsächlich zu tun, ich krieg nach dem rm Nullen an dem Sektor. Danke!

[Alpha]

Nein, was DosAmp meint, ist sicher. Im Kernel wird das bereits deaktiviert, daher kann da nix mehr passieren. Bei der Crucial war das auch so mit alter Firmware, was inzwischen gefixt ist. Trim ist aber nicht deaktiviert

[mrshadowtux]

Dann ist jetzt ja alles richtig eingestellt. Danke!