Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread Narcis Garcia
El 27/4/19 a les 22:15, spameden ha escrit: > > сб, 27 апр. 2019 г. в 20:16, Narcis Garcia >: > > I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard > > > What do you mean it doesn't solve the issue with discard? It does. > > Discard is

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread spameden
сб, 27 апр. 2019 г. в 20:16, Narcis Garcia : > I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard > What do you mean it doesn't solve the issue with discard? It does. Discard is perfectly working on Proxmox kernel 4.15.18-12-pve or even on 4.13 kernel on DM-Crypt/LUKS setup

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread Narcis Garcia
The problem of Virtuozzo 7 for me is that this is a distro. I prefer to use general purpose distros, for many reasons around packaged software, community support, future plans and others. El 27/4/19 a les 19:09, Paulo Coghi - Coghi IT ha escrit: > LXC is far to be an option, IMHO. > > I'm happil

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread Narcis Garcia
I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard issue for OpenVZ/6 with a LUKS layer. With any of Devuan 1, 2, Debian 8, 9 kernels, Discard works fine with LUKS layer (with or without LXC), and Proxmox doesn't help in this. El 27/4/19 a les 16:39, spameden ha escrit: > F

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread 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 wrote: > I believe to have fixes and backports like this in to legacy version of > product will not happen, and you should

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread spameden
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 wel

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread Narcis Garcia
Thank you for recommendation; it's in my plans. I hope sometime LXC allows to manage simfs/dir disk quotas, same as vzquota. This is a very important matter for scenarios I have. In the meanwhile, I administrer many OpenVZ/6 hosts without upgrade calendar in short, and not all decisions (and time

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread 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 wrote: > Yes, it's an

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread 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 : > See in the case that /dev/sda1 (Directly mounted as Ext4 on /boot) works > with Trim/Discard. > It

Re: [Users] 100.000 openVZ hosts with contaienrs

2019-04-27 Thread Konstantin Bukharov
Hi, To join CEP you can install disp-helper package and check that service become active. This package is available in OpenVZ distributions, like https://download.openvz.org/virtuozzo/releases/openvz-7.0.10-252/x86_64/os/Packages/d/disp-helper-0.0.171-2.vz7.x86_64.rpm We are going to expose res

Re: [Users] SSD trim support over a LUKS layer

2019-04-27 Thread Narcis Garcia
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 s