[Users] SSD trim support over a LUKS layer

Sat Apr 27 17:39:03 MSK 2019

Furthermore there might be issues using old legacy OpenVZ6 kernel on modern
hardware, e.g. NVMe or any newer NIC cards.

Seeing as you've been using Debian as well as me for quite some time I'd
recommend - https://proxmox.com

In proxmox you can use unprivileged LXC containers (for security) as well
as containers with directory storage though they don't support quotas (but
you save on precious nvme disk storage).

There is also fancy webui, but I don't use it, mainly sticking to the
console pct tool and template's system.

There is a bit hassle regarding using external IPs in the containers, but
it's possible via certain workaround with iptables and routing.

Proxmox also works natively with latest Debian Stretch (with systemd) and
it's using recent kernel, e.g.:

# uname -r
4.15.18-12-pve

and yes discards work just fine on proxmox:

# dmsetup table|grep discards
***: 0 123 crypt aes-xts-plain64
0000000000000000000000000000000000000000000000000000000000000000 0 9:1 4096
1 allow_discards

Migration from OpenVZ6 is also very straightforward to Proxmox: in most
cases containers just do work (if you've been using simfs before) and not
requiring any modifications.

сб, 27 апр. 2019 г. в 17:28, CoolCold <coolthecold at gmail.com>:

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