[opensuse] Discard vs. dm-crypt
Hi, On multiple of my machines I have the root filesystem on a dm-crypt device placed on an SSD. Now, I would like to use `fstrim /`. Now, I know about the security implications. But, as encryption for me primarily is a way to be able to throw out disks without further effort, I don't consider those a problem for me. Sadly, on any system I installed directly with Leap 15.0 I cannot get this to work. Despite having `rd.luks.options=discard` in my kernel arguments I get the following output from `lsblk`: # lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─cr_sda3 0 0B 0B 0 Curiously the same works on a different systems which has been upgraded through various versions of Leap and is now also running on 15.0. # lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 └─sda6 0 512B 2G 0 └─luks-081…3e1 0 512B 2G 0 The only difference I can see between the systems is, that the older system uses the UUID instead of the name, and for some reason the newer system does have the device containing root in `/etc/crypttab` while the old system does not. Any hints on what might be causing the different behavior? Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
17.01.2019 23:51, Matthias Bach пишет:
Hi,
On multiple of my machines I have the root filesystem on a dm-crypt device placed on an SSD. Now, I would like to use `fstrim /`. Now, I know about the security implications. But, as encryption for me primarily is a way to be able to throw out disks without further effort, I don't consider those a problem for me.
Sadly, on any system I installed directly with Leap 15.0 I cannot get this to work. Despite having `rd.luks.options=discard` in my kernel arguments I get the following output from `lsblk`:
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─cr_sda3 0 0B 0B 0
dm-crypt != LUKS. Please clarify your configuration.
Curiously the same works on a different systems which has been upgraded through various versions of Leap and is now also running on 15.0.
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 └─sda6 0 512B 2G 0 └─luks-081…3e1 0 512B 2G 0
The only difference I can see between the systems is, that the older system uses the UUID instead of the name, and for some reason the newer system does have the device containing root in `/etc/crypttab` while the old system does not.
Any hints on what might be causing the different behavior?
Kind Regards, Matthias
Hi, Am Freitag, 18. Januar 2019, 04:48:01 CET schrieb Andrei Borzenkov:
17.01.2019 23:51, Matthias Bach пишет:
On multiple of my machines I have the root filesystem on a dm-crypt device placed on an SSD. Now, I would like to use `fstrim /`. Now, I know about the security implications. But, as encryption for me primarily is a way to be able to throw out disks without further effort, I don't consider those a problem for me.
Sadly, on any system I installed directly with Leap 15.0 I cannot get this to work. Despite having `rd.luks.options=discard` in my kernel arguments I get the following output from `lsblk`:
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─cr_sda3 0 0B 0B 0
dm-crypt != LUKS. Please clarify your configuration.
It's LUKS, as I just used the encrypt-flag in Yast. Sorry for the confusion. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
The only difference I can see between the systems is, that the older system uses the UUID instead of the name, and for some reason the newer system does have the device containing root in `/etc/crypttab` while the old system does not.
Any hints on what might be causing the different behavior?
Sorry for the partial mail before, if you even got it. You need to add the discard option to the fourth field: # cat /etc/crypttab cr_sda3 UUID=XXXXXXXX-XXX-XXXX-XXXX-XXXXXXXXXXXX /root/secrets/luks.key discard Also, if you're using LVM (which I think it's not the casa, you also need issue_discards = 1 on /etc/lvm/lvm.conf You may also need to re-generate your initrd. Also, I'm not sure if you can apply the discard option on a running luks block device. Just reboot and see if it works. Hope it helps, -- Rui Santos Veni, Vidi, Linux -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, Yes, I am using LUKS. Sorry for the confusion. Am Freitag, 18. Januar 2019, 10:38:40 CET schrieb Rui Santos:
c/crypttab cr_sda3 UUID=XXXXXXXX-XXX-XXXX-XXXX-XXXXXXXXXXXX /root/secrets/luks.key discard
I already tried that. But as this is the root device it doesn't seem to have an affect. Even when regenerating the initrd. Curiosly, on the one system where it is working, the device doesn't even show up in /etc/crypttab.
Also, if you're using LVM (which I think it's not the casa, you also need issue_discards = 1 on /etc/lvm/lvm.conf
I have that. However, it seems the discard capability already get's lost at the crypto layer. Thanks for confirming I wasn't completely on the wrong track! Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
17.01.2019 23:51, Matthias Bach пишет:
Hi,
On multiple of my machines I have the root filesystem on a dm-crypt device placed on an SSD. Now, I would like to use `fstrim /`. Now, I know about the security implications. But, as encryption for me primarily is a way to be able to throw out disks without further effort, I don't consider those a problem for me.
Sadly, on any system I installed directly with Leap 15.0 I cannot get this to work. Despite having `rd.luks.options=discard` in my kernel arguments I get the following output from `lsblk`:
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─cr_sda3 0 0B 0B 0
Curiously the same works on a different systems which has been upgraded through various versions of Leap and is now also running on 15.0.
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 └─sda6 0 512B 2G 0 └─luks-081…3e1 0 512B 2G 0
The only difference I can see between the systems is, that the older system uses the UUID instead of the name, and for some reason the newer system does have the device containing root in `/etc/crypttab` while the old system does not.
Any hints on what might be causing the different behavior?
Different configuration? Please show from each system /etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\* (yes, last command is exactly as given, it shows content of files). I am not surprised you have no discards; I am surprised where discards come from.
19.01.2019 10:12, Andrei Borzenkov пишет:
17.01.2019 23:51, Matthias Bach пишет:
Hi,
On multiple of my machines I have the root filesystem on a dm-crypt device placed on an SSD. Now, I would like to use `fstrim /`. Now, I know about the security implications. But, as encryption for me primarily is a way to be able to throw out disks without further effort, I don't consider those a problem for me.
Sadly, on any system I installed directly with Leap 15.0 I cannot get this to work. Despite having `rd.luks.options=discard` in my kernel arguments I get the following output from `lsblk`:
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─cr_sda3 0 0B 0B 0
Curiously the same works on a different systems which has been upgraded through various versions of Leap and is now also running on 15.0.
# lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 └─sda6 0 512B 2G 0 └─luks-081…3e1 0 512B 2G 0
The only difference I can see between the systems is, that the older system uses the UUID instead of the name, and for some reason the newer system does have the device containing root in `/etc/crypttab` while the old system does not.
Any hints on what might be causing the different behavior?
Different configuration?
Please show from each system
/etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\*
(yes, last command is exactly as given, it shows content of files).
I am not surprised you have no discards; I am surprised where discards come from.
Could you please also show dmsetup table cat /proc/cmdline from each system.
Hi all, So it turns out the issue magically solved itself on all systems but one. However, that system doesn't have Systemd in its Initrd, so I should probably tackle that issue first. Thanks to everybody for the replies. I really appreciated and learned from them. Am Samstag, 19. Januar 2019, 08:12:52 CET schrieb Andrei Borzenkov:
Please show from each system
/etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\*
(yes, last command is exactly as given, it shows content of files).
I am not surprised you have no discards; I am surprised where discards come from.
Would you still like to see those files from a system with working discard? In that case I'll post 'em. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
20.01.2019 22:11, Matthias Bach пишет:
Hi all,
So it turns out the issue magically solved itself on all systems but one. However, that system doesn't have Systemd in its Initrd, so I should probably tackle that issue first.
Thanks to everybody for the replies. I really appreciated and learned from them.
Am Samstag, 19. Januar 2019, 08:12:52 CET schrieb Andrei Borzenkov:
Please show from each system
/etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\*
(yes, last command is exactly as given, it shows content of files).
I am not surprised you have no discards; I am surprised where discards come from.
Would you still like to see those files from a system with working discard? In that case I'll post 'em.
Please post output of dmsetup table on system where you see "working" discard. I suspect this is false positive.
Hi, Am Sonntag, 20. Januar 2019, 20:15:26 CET schrieb Andrei Borzenkov:
20.01.2019 22:11, Matthias Bach пишет:
Am Samstag, 19. Januar 2019, 08:12:52 CET schrieb Andrei Borzenkov:
Please show from each system
/etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\*
(yes, last command is exactly as given, it shows content of files).
I am not surprised you have no discards; I am surprised where discards come from.
Would you still like to see those files from a system with working discard? In that case I'll post 'em.
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
luks-0XXX1: 0 169615360 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:6 4096 1 allow_discards cr_home: 0 1953517184 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 9:0 4096 system-swap: 0 16777216 linear 254:0 152823808 system-root: 0 152821760 linear 254:0 2048 Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
20.01.2019 23:16, Matthias Bach пишет:
Hi,
Am Sonntag, 20. Januar 2019, 20:15:26 CET schrieb Andrei Borzenkov:
20.01.2019 22:11, Matthias Bach пишет:
Am Samstag, 19. Januar 2019, 08:12:52 CET schrieb Andrei Borzenkov:
Please show from each system
/etc/fstab /etc/crypttab lsinitrd /boot/initrd lsinitrd /boot/initrd etc/cmdline.d/\*
(yes, last command is exactly as given, it shows content of files).
I am not surprised you have no discards; I am surprised where discards come from.
Would you still like to see those files from a system with working discard? In that case I'll post 'em.
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
luks-0XXX1: 0 169615360 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:6 4096 1 allow_discards
Yes, discards are active indeed. Did you explicitly configure it (in /etc/crypttab)?
Hi, Sorry for the late response. I had been forced to go AFK for a while. Am Sonntag, 20. Januar 2019, 21:27:12 CET schrieb Andrei Borzenkov:
20.01.2019 23:16, Matthias Bach пишет:
Am Sonntag, 20. Januar 2019, 20:15:26 CET schrieb Andrei Borzenkov:
20.01.2019 22:11, Matthias Bach пишет:
Am Samstag, 19. Januar 2019, 08:12:52 CET schrieb Andrei Borzenkov: Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.> luks-0XXX1: 0 169615360 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:6 4096 1 allow_discards
Yes, discards are active indeed. Did you explicitly configure it (in /etc/crypttab)?
I use the kernel argument `rd.luks.options=discard`. Nothing else. The one thing that differs from a modern default openSUSE set-up is that I use the classical non-encrypted boot partition (as one would do with a BIOS boot, but I EFI-boot). Only root and swap are on the encrypted device. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
On 20/01/2019 20.15, Andrei Borzenkov wrote:
20.01.2019 22:11, Matthias Bach пишет:
...
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
I'm getting curious. I have two machines in which home is encrypted and on SSD disks. Using that command I get: Laptop with encrypted home on SSD: Legolas:~ # dmsetup table cr_sda8: 0 976746496 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:8 4096 Legolas:~ # Small server with encrypted home on mSATA SSD sengard:~ # dmsetup table ... ... cr_home: 0 146798592 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:5 4096 ... Isengard:~ # Discard is not active. The log has entries like this: # grep -i "discard\|trim" /var/log/messages small server: <3.6> 2018-12-26 11:05:25 Legolas btrfsmaintenance-refresh-cron.sh 1112 - - Refresh script btrfs-trim.sh for uninstall <3.6> 2018-12-26 11:05:25 Legolas btrfsmaintenance-refresh-cron.sh 1112 - - Refresh timer btrfs-trim for none <3.6> 2018-12-26 11:05:47 Legolas fstrim 1134 - - /: 19.3 GiB (20749635584 bytes) trimmed <3.6> 2018-12-26 11:05:47 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-02 03:26:37 Legolas systemd 1 - - Starting Discard unused blocks... <3.6> 2019-01-02 03:26:41 Legolas fstrim 25763 - - /: 1.4 GiB (1513734144 bytes) trimmed <3.6> 2019-01-02 03:26:41 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-07 17:57:17 Legolas systemd 1 - - Starting Discard unused blocks... <3.6> 2019-01-07 17:57:21 Legolas fstrim 16675 - - /: 1.3 GiB (1359900672 bytes) trimmed <3.6> 2019-01-07 17:57:21 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-14 00:00:10 Legolas systemd 1 - - Starting Discard unused blocks... <3.6> 2019-01-14 00:00:18 Legolas fstrim 12369 - - /: 3.8 GiB (4081111040 bytes) trimmed <3.6> 2019-01-14 00:00:18 Legolas systemd 1 - - Started Discard unused blocks. Laptop: <3.6> 2018-12-30T22:58:51.181568+01:00 Isengard btrfsmaintenance-refresh-cron.sh 973 - - Refresh timer btrfs-trim for weekly <3.6> 2018-12-31T00:00:03.446660+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2018-12-31T00:01:41.548922+01:00 Isengard fstrim 6391 - - /: 2.6 GiB (2778935296 bytes) trimmed <3.6> 2018-12-31T00:01:41.551418+01:00 Isengard systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-01T00:00:03.438862+01:00 Isengard systemd 1 - - Started Discard unused blocks on a mounted filesystem. <3.6> 2019-01-01T00:00:03.484872+01:00 Isengard btrfs-trim.sh 23099 - - Path / is not btrfs, skipping <3.6> 2019-01-07T00:00:03.937098+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2019-01-07T00:00:24.922705+01:00 Isengard fstrim 22507 - - /: 588.3 MiB (616849408 bytes) trimmed <3.6> 2019-01-07T00:00:24.923849+01:00 Isengard systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-14T00:00:00.243791+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2019-01-14T00:01:27.403952+01:00 Isengard fstrim 25026 - - /: 2.5 GiB (2691629056 bytes) trimmed <3.6> 2019-01-14T00:01:27.406846+01:00 Isengard systemd 1 - - Started Discard unused blocks. I don't have entries on /etc/crypttab or fstab about discard or trim. Should I? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
21.01.2019 0:17, Carlos E. R. пишет:
On 20/01/2019 20.15, Andrei Borzenkov wrote:
20.01.2019 22:11, Matthias Bach пишет:
...
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
I'm getting curious. I have two machines in which home is encrypted and on SSD disks. Using that command I get:
Laptop with encrypted home on SSD:
Legolas:~ # dmsetup table cr_sda8: 0 976746496 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:8 4096 Legolas:~ #
Small server with encrypted home on mSATA SSD
sengard:~ # dmsetup table ... ... cr_home: 0 146798592 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:5 4096 ... Isengard:~ #
Discard is not active.
The log has entries like this:
# grep -i "discard\|trim" /var/log/messages
small server:
...
<3.6> 2018-12-26 11:05:47 Legolas fstrim 1134 - - /: 19.3 GiB (20749635584 bytes) trimmed <3.6> 2018-12-26 11:05:47 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-02 03:26:37 Legolas systemd 1 - - Starting Discard unused blocks... ...
Laptop:
<3.6> 2018-12-30T22:58:51.181568+01:00 Isengard btrfsmaintenance-refresh-cron.sh 973 - - Refresh timer btrfs-trim for weekly <3.6> 2018-12-31T00:00:03.446660+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2018-12-31T00:01:41.548922+01:00 Isengard fstrim 6391 - - /: 2.6 GiB (2778935296 bytes) trimmed <3.6> 2018-12-31T00:01:41.551418+01:00 Isengard systemd 1 - - Started Discard unused blocks. ...
I don't have entries on /etc/crypttab or fstab about discard or trim.
please show lslbk --discard on both systems.
Should I?
I guess it is up to you - whether you want to actually use TRIM or not.
On 21/01/2019 05.01, Andrei Borzenkov wrote:
21.01.2019 0:17, Carlos E. R. пишет:
On 20/01/2019 20.15, Andrei Borzenkov wrote:
20.01.2019 22:11, Matthias Bach пишет:
...
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
I'm getting curious. I have two machines in which home is encrypted and on SSD disks. Using that command I get:
Laptop with encrypted home on SSD:
Legolas:~ # dmsetup table cr_sda8: 0 976746496 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:8 4096 Legolas:~ #
Small server with encrypted home on mSATA SSD
sengard:~ # dmsetup table ... ... cr_home: 0 146798592 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:5 4096 ... Isengard:~ #
Discard is not active.
The log has entries like this:
# grep -i "discard\|trim" /var/log/messages
small server:
...
<3.6> 2018-12-26 11:05:47 Legolas fstrim 1134 - - /: 19.3 GiB (20749635584 bytes) trimmed <3.6> 2018-12-26 11:05:47 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-02 03:26:37 Legolas systemd 1 - - Starting Discard unused blocks... ...
Laptop:
<3.6> 2018-12-30T22:58:51.181568+01:00 Isengard btrfsmaintenance-refresh-cron.sh 973 - - Refresh timer btrfs-trim for weekly <3.6> 2018-12-31T00:00:03.446660+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2018-12-31T00:01:41.548922+01:00 Isengard fstrim 6391 - - /: 2.6 GiB (2778935296 bytes) trimmed <3.6> 2018-12-31T00:01:41.551418+01:00 Isengard systemd 1 - - Started Discard unused blocks. ...
I don't have entries on /etc/crypttab or fstab about discard or trim.
please show lslbk --discard on both systems.
Isengard:~ # lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 └─sda5 0 512B 2G 0 └─cr_home 0 0B 0B 0 sdb 0 0B 0B 0 └─sdb1 0 0B 0B 0 └─cr_hoard2 0 0B 0B 0 sdc 0 0B 0B 0 └─sdc1 0 0B 0B 0 └─cr_my_book 0 0B 0B 0 sdd 0 0B 0B 0 ├─sdd1 0 0B 0B 0 └─sdd2 0 0B 0B 0 └─cr_waterhoard 0 0B 0B 0 Isengard:~ # Legolas:~ # lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 ├─sda6 0 512B 2G 0 ├─sda7 0 512B 2G 0 ├─sda8 0 512B 2G 0 │ └─cr_sda8 0 0B 0B 0 ├─sda9 0 512B 2G 0 ├─sda10 0 512B 2G 0 └─sda11 0 512B 2G 0 Legolas:~ #
Should I?
I guess it is up to you - whether you want to actually use TRIM or not.
I'm confused with discard vs trim. I understand that "discard" is simply the option word in fstab. I have trim periodically on the filesystem instead of online, I think I prefer it that way. And this thread made me think whether encrypted partitions should be handled differently. Do the periodic trim work on the encrypted filesystem? If it does, then I'm fine. Reading here: https://wiki.debian.org/SSDOptimization Says: «The "discard" options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD.» which is my case. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
21.01.2019 13:52, Carlos E. R. пишет:
On 21/01/2019 05.01, Andrei Borzenkov wrote:
21.01.2019 0:17, Carlos E. R. пишет:
On 20/01/2019 20.15, Andrei Borzenkov wrote:
20.01.2019 22:11, Matthias Bach пишет:
...
Please post output of
dmsetup table
on system where you see "working" discard. I suspect this is false positive.
I'm getting curious. I have two machines in which home is encrypted and on SSD disks. Using that command I get:
Laptop with encrypted home on SSD:
Legolas:~ # dmsetup table cr_sda8: 0 976746496 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:8 4096 Legolas:~ #
Small server with encrypted home on mSATA SSD
sengard:~ # dmsetup table ... ... cr_home: 0 146798592 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:5 4096 ... Isengard:~ #
Discard is not active.
The log has entries like this:
# grep -i "discard\|trim" /var/log/messages
small server:
...
<3.6> 2018-12-26 11:05:47 Legolas fstrim 1134 - - /: 19.3 GiB (20749635584 bytes) trimmed <3.6> 2018-12-26 11:05:47 Legolas systemd 1 - - Started Discard unused blocks. <3.6> 2019-01-02 03:26:37 Legolas systemd 1 - - Starting Discard unused blocks... ...
Laptop:
<3.6> 2018-12-30T22:58:51.181568+01:00 Isengard btrfsmaintenance-refresh-cron.sh 973 - - Refresh timer btrfs-trim for weekly <3.6> 2018-12-31T00:00:03.446660+01:00 Isengard systemd 1 - - Starting Discard unused blocks... <3.6> 2018-12-31T00:01:41.548922+01:00 Isengard fstrim 6391 - - /: 2.6 GiB (2778935296 bytes) trimmed <3.6> 2018-12-31T00:01:41.551418+01:00 Isengard systemd 1 - - Started Discard unused blocks. ...
I don't have entries on /etc/crypttab or fstab about discard or trim.
please show lslbk --discard on both systems.
Isengard:~ # lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 └─sda5 0 512B 2G 0 └─cr_home 0 0B 0B 0 ...
Legolas:~ # lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 ├─sda5 0 512B 2G 0 ├─sda6 0 512B 2G 0 ├─sda7 0 512B 2G 0 ├─sda8 0 512B 2G 0 │ └─cr_sda8 0 0B 0B 0 ├─sda9 0 512B 2G 0 ├─sda10 0 512B 2G 0 └─sda11 0 512B 2G 0 Legolas:~ #
OK this is consistent. I assume you are using Leap 15 with current kernel or TW?
Should I?
I guess it is up to you - whether you want to actually use TRIM or not.
I'm confused with discard vs trim. I understand that "discard" is simply the option word in fstab.
Discard is kernel framework for passing information about unused areas to storage device. Final device driver translates these requests into device-specific commands. TRIM is one such command used by (S)ATA devices. SCSI has UNMAP and some other; NVMe has Deallocate. TRIM is often used colloquially to mean "free unused space on device". All drivers involved in request processing must support and allow discard requests. This is exactly what "allow_discard" dm-crypt option does; so even though your physical devices claim to support discards (using whatever dialect they speak) those requests will be ignored by crypto-container and never reach your physical device. Filesystem "discard" option makes it issue discard requests when space is freed (like when file is deleted). Low level drivers are still free to ignore these requests.
I have trim periodically on the filesystem instead of online, I think I prefer it that way.
And this thread made me think whether encrypted partitions should be handled differently. Do the periodic trim work on the encrypted filesystem? If it does, then I'm fine.
Your encrypted devices (or better underlying physical devices) are never trimmed unless you explicitly allow it.
Reading here:
https://wiki.debian.org/SSDOptimization
Says:
«The "discard" options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD.»
which is my case.
In this case you do not need manual fstrim as well. You still use it.
On 21/01/2019 19.51, Andrei Borzenkov wrote:
21.01.2019 13:52, Carlos E. R. пишет:
On 21/01/2019 05.01, Andrei Borzenkov wrote:
21.01.2019 0:17, Carlos E. R. пишет:
On 20/01/2019 20.15, Andrei Borzenkov wrote:
20.01.2019 22:11, Matthias Bach пишет:
...
OK this is consistent. I assume you are using Leap 15 with current kernel or TW?
Yes, those two use 15.0 with default kernel.
Should I?
I guess it is up to you - whether you want to actually use TRIM or not.
I'm confused with discard vs trim. I understand that "discard" is simply the option word in fstab.
Discard is kernel framework for passing information about unused areas to storage device. Final device driver translates these requests into device-specific commands. TRIM is one such command used by (S)ATA devices. SCSI has UNMAP and some other; NVMe has Deallocate.
TRIM is often used colloquially to mean "free unused space on device".
All drivers involved in request processing must support and allow discard requests. This is exactly what "allow_discard" dm-crypt option does; so even though your physical devices claim to support discards (using whatever dialect they speak) those requests will be ignored by crypto-container and never reach your physical device.
Filesystem "discard" option makes it issue discard requests when space is freed (like when file is deleted). Low level drivers are still free to ignore these requests.
I have trim periodically on the filesystem instead of online, I think I prefer it that way.
And this thread made me think whether encrypted partitions should be handled differently. Do the periodic trim work on the encrypted filesystem? If it does, then I'm fine.
Your encrypted devices (or better underlying physical devices) are never trimmed unless you explicitly allow it.
Let me see if I understood. On an encrypted partition, if /etc/crypttab has "allow_discards", trim will happen when the trim cronjob runs, or online via option in fstab.
Reading here:
https://wiki.debian.org/SSDOptimization
Says:
«The "discard" options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD.»
which is my case.
In this case you do not need manual fstrim as well. You still use it.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
21.01.2019 22:00, Carlos E. R. пишет:
All drivers involved in request processing must support and allow discard requests. This is exactly what "allow_discard" dm-crypt option does; so even though your physical devices claim to support discards (using whatever dialect they speak) those requests will be ignored by crypto-container and never reach your physical device.
Your encrypted devices (or better underlying physical devices) are never trimmed unless you explicitly allow it.
Let me see if I understood. On an encrypted partition, if /etc/crypttab has "allow_discards", trim will happen when the trim cronjob runs, or online via option in fstab.
Yes if all other involved drivers also allow it (this thread mentioned LVM2 as example). If you use filesystem on LUKS on physical device directly it should be enough.
On 21/01/2019 20.10, Andrei Borzenkov wrote:
21.01.2019 22:00, Carlos E. R. пишет:
All drivers involved in request processing must support and allow discard requests. This is exactly what "allow_discard" dm-crypt option does; so even though your physical devices claim to support discards (using whatever dialect they speak) those requests will be ignored by crypto-container and never reach your physical device.
Your encrypted devices (or better underlying physical devices) are never trimmed unless you explicitly allow it.
Let me see if I understood. On an encrypted partition, if /etc/crypttab has "allow_discards", trim will happen when the trim cronjob runs, or online via option in fstab.
Yes if all other involved drivers also allow it (this thread mentioned LVM2 as example). If you use filesystem on LUKS on physical device directly it should be enough.
Ok! I'll try, thanks. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Matthias Bach -
Rui Santos