[Users] SSD trim support over a LUKS layer

[spameden]

Yes, it's an issue in kernel.

As dm-crypt/luks layer isn't passing TRIM to the underlying device.

/boot is not encrypted that's why it works for you.

сб, 27 апр. 2019 г. в 11:11, Narcis Garcia <informatica at actiu.net>:

> See in the case that /dev/sda1 (Directly mounted as Ext4 on /boot) works
> with Trim/Discard.
> It's the sda2_crypt (layer over sda2) that is not detected to be
> trimmable. Devuan's stock kernel does.
>
> CentOS issue #6548 may not be this same bug; I've tested now with CentOS
> 6.8 with a similar (but not same) result*:*
>
> $ lsb_release -d
> Description:    CentOS release 6.8 (Final)
>
> $ uname -a
> Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP Tue May 10
> 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> $ 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
>   └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0)        0
> 512B       2G         0
>
> $ cat /etc/crypttab
> luks-f691f48b-8556-487d-ac64-50daa99ed4c9
> UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none luks,discard
>
> $ mount | grep -e discard
> /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 on / type ext4
> (rw,discard)
> /dev/sda1 on /boot type ext4 (rw,discard)
>
> $ sudo fstrim /boot
> # (same result as Devuan/1 and OpenVZ/6 kernel: success)
>
> $ sudo fstrim /
> fstrim: /: FITRIM ioctl failed: Operation not supported
>
>
> El 26/4/19 a les 21:36, spameden ha escrit:
>
> Hi.
>
> I've asked this question years ago (in 2013):
> https://lists.openvz.org/pipermail/users/2013-August/005250.html
>
> Let me know if it helps, but this bug should have been fixed in CentOS and
> RHEL at least: https://bugs.centos.org/view.php?id=6548
>
> Maybe OpenVZ maintainers didn't pick up this fix in the openvz6 legacy
> kernel?
>
> Thanks.
>
> ср, 10 апр. 2019 г. в 10:45, Narcis Garcia <informatica at actiu.net>:
>
>> Does anybody know how can I solve this?
>>
>> $ lsb_release -d
>> Description:    Devuan GNU/Linux 1.0 (jessie)
>>
>> $ uname -a
>> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP Fri Dec 7 17:18:40
>> MSK 2018 x86_64 GNU/Linux
>>
>> $ 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
>>   └─sda2_crypt        0        0B       0B         0
>>
>> $ cat /etc/crypttab
>> sda2_crypt UUID=***** none luks,discard
>>
>> $ mount | grep -e discard
>> /dev/mapper/sda2_crypt on / type ext4
>> (rw,noatime,errors=remount-ro,barrier=1,data=ordered,discard)
>> /dev/sda1 on /boot type ext4 (rw,relatime,barrier=1,data=ordered,discard)
>>
>> $ sudo fstrim /
>> fstrim: /: the discard operation is not supported
>>
>> Thank you.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20190427/f83e478e/attachment.html>