[Users] SSD trim support over a LUKS layer

[Paulo Coghi - Coghi IT]

LXC is far to be an option, IMHO.

I'm happily using Virtuozzo 7 with multiple NVMe storages with zero issues
for more than a year.

On Sat, Apr 27, 2019 at 4:28 PM CoolCold <coolthecold at gmail.com> wrote:

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