fstrim scheint eine Partition, die lvm und dm-crypt verwendet, nicht zu trimmen

Ich versuche, Fedora 25 mit dm-crypt und LVM einzurichten, habe aber Schwierigkeiten, TRIM zum Laufen zu bringen.

$ sudo fstrim -av                                                                            
/boot: 28.6 MiB (30003200 bytes) trimmed
/: 56.5 GiB (60672704512 bytes) trimmed

$ sudo fstrim -av                                                                            
/boot: 0 B (0 bytes) trimmed
/: 56.5 GiB (60671877120 bytes) trimmed

Wie Sie der obigen Ausgabe entnehmen können , fstrimfunktioniert das wiederholte Ausführen auf unverschlüsseltem ext4 /boot , scheint jedoch keine Auswirkungen auf /(das sich auf derselben Festplatte befindet) zu haben.

Das Setup ist SSD -> dm-crypt -> LVM -> XFS

$ lsblk -D                                                                                                                                                                                     
NAME                                          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                                  0      512B       2G         0
├─sda2                                               0      512B       2G         0
│ └─luks-dd5ce54a-34c9-540c-a4cf-2a712b8a3a5e        0      512B       2G         0
│   └─fedora-root                                    0      512B       2G         0
└─sda1                                               0      512B       2G         0

Nach dieser Frage DISC-ZERO == 0 sollte das nicht das Problem sein

# cat /etc/crypttab
luks-dd... UUID=dd.. none discard

# cat /etc/lvm/lvm.conf
devices {
...
     issue_discards = 1
...
}

Ich habe auch die rd.luks.options=discardOption /etc/default/grubinitramfs und grub.cfg hinzugefügt und aktualisiert:

# grub2-mkconfig -o /boot/grub2/grub.cfg
# dracut -f

Die Option zum Verwerfen wurde korrekt weitergegeben:

# dmsetup table luks-d...                                                                                                                        
0 233385984 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:2 4096 1 allow_discards

Ich habe Variationen des oben genannten Setups ausprobiert, die im Internet zu finden sind, aber dies scheint den Handbuchseiten zu folgen. Was ich nicht versucht habe, war die Verwendung eines anderen Dateisystems, aber XFS sollte unterstützt werden.

Ich denke, Ihre Tests stimmen nicht mit der Dokumentation überein ( man fstrim).

-v, --verbose

Ausführliche Ausführung. Mit dieser Option gibt fstrim die Anzahl der Bytes aus, die vom Dateisystem über den Blockstapel an das Gerät übergeben werden, um sie möglicherweise zu verwerfen. Diese Zahl ist aus Sicht des Speichergeräts ein maximaler Verwerfungsbetrag, da FITRIM ioctl, das wiederholt aufgerufen wird, weiterhin dieselben Sektoren wiederholt zum Verwerfen sendet.

fstrim meldet jedes Mal die gleichen potenziellen Verwerfungsbytes , aber nur Sektoren, in die zwischen den Verwerfungen geschrieben wurde, werden vom Speichergerät tatsächlich verworfen. Darüber hinaus behält sich die Kernelblockschicht das Recht vor, die Verwerfungsbereiche an die Raid-Stripe-Geometrie, nicht trimmfähige Geräte in einem LVM-Setup usw. anzupassen. Diese Reduzierungen würden sich nicht in fstrim_range.len (der Option --length) widerspiegeln.

Ich schlage vor, stattdessen mit blktrace nach Verwerfungsanforderungen zu suchen , dh gleichzeitig mit dem Ausführen von fstrim. Hoffentlich wird angezeigt, ob Verwerfungsanforderungen an das Blockgerät am unteren Rand des Stapels gesendet werden. Sie können die Ergebnisse zwischen sda1 und sda2 vergleichen (nach einem Neustart, um das undokumentierte Verhalten von sda1 zu vermeiden).

btrace -a discard $DEV