[Users] SSD trim support over a LUKS layer

[CoolCold]

I believe to have fixes and backports like this in to legacy version of
product will not happen, and you should consider upgrading. Personally,
I've upgraded to lxc.. it's quite primitive comparing to ovz 6, but it's
enough for my needs.

On Sat, Apr 27, 2019, 17:49 spameden <spameden at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/acb163fe/attachment-0001.html>