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

[CoolCold]

On Mon, Apr 29, 2019 at 3:53 PM Paulo Coghi - Coghi IT 
wrote:

> Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
> features, it's more insecure, has a network standard that is a nightmare,
> etc.
>
As some members of this maillist mentioned, not everyone wants to change
into specific distribution comparing to general purpose distribution. I.e.
having Debian based instalation action as application server with, for
example some containers as an addition (my case). Moving to Centos based
world brings it's own complications for some people.

>
> I stopped using proxmox from the exact moment it removed OpenVZ support
> and replaced it with LXC.
>
> Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using
> multiple NVMe drives with zero issues for almost 2 years.
>
> On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia 
> wrote:
>
>> Definitely we'll not migrate to Proxmox because it's suboptimal writing
>> this in OpenDocument format from an HTML5 interface.
>>
>>
>> El 28/4/19 a les 14:37, spameden ha escrit:
>> > No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots
>> > of effort to port their patches over the fresh kernel.
>> >
>> > The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there
>> > is an issue with discard (it doesn't work).
>> >
>> > The discard issue has been fixed in 3.1-mainline kernel I think, you can
>> > look over newish RHEL kernel and try to port those changes to the old
>> > legacy OpenVZ 6 kernel.
>> >
>> > Regarding 4.x kernel:
>> > I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
>> > containers and KVM - and there is no issue with discards at all.
>> > and what I also meant is: that you can easily migrate your existing
>> > OpenVZ containers to the Proxmox.
>> >
>> > Proxmox is based on latest Debian Stretch and specifically designed as a
>> > distro for contrainers.
>> > It has GUI, networking support (including openvswitch and other),
>> > KVM/LXC support and many other things (e.g. ceph/glusterfs support).
>> >
>> > Though, reading you again you've mentioned that you need a specific
>> > simfs quota in containers:
>> > most likely that would be impossible for unprivileged containers with
>> > directory storage (simfs analogue), althrough you could use qcow2 or
>> > LVM-based storage for containers.
>> >
>> >
>> > вс, 28 апр. 2019 г. в 09:47, 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 perfectly working on Proxmox kernel 4.15.18-12-pve or
>> > even on
>> > > 4.13 kernel on DM-Crypt/LUKS setup.
>> > >
>> > > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
>> > > talking about.
>> >
>> > Are you really using OpenVZ 6 with Linux kernel 4.x?
>> > Did you see any difficult with Discard when using other context with
>> > Linux 4.x ?
>> > ___
>> > Users mailing list
>> > Users@openvz.org 
>> > https://lists.openvz.org/mailman/listinfo/users
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@openvz.org
>> > https://lists.openvz.org/mailman/listinfo/users
>> >
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>


-- 
Best regards,
[COOLCOLD-RIPN]
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[Paulo Coghi - Coghi IT]

Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
features, it's more insecure, has a network standard that is a nightmare,
etc.

I stopped using proxmox from the exact moment it removed OpenVZ support and
replaced it with LXC.

Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using multiple
NVMe drives with zero issues for almost 2 years.

On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia 
wrote:

> Definitely we'll not migrate to Proxmox because it's suboptimal writing
> this in OpenDocument format from an HTML5 interface.
>
>
> El 28/4/19 a les 14:37, spameden ha escrit:
> > No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots
> > of effort to port their patches over the fresh kernel.
> >
> > The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there
> > is an issue with discard (it doesn't work).
> >
> > The discard issue has been fixed in 3.1-mainline kernel I think, you can
> > look over newish RHEL kernel and try to port those changes to the old
> > legacy OpenVZ 6 kernel.
> >
> > Regarding 4.x kernel:
> > I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
> > containers and KVM - and there is no issue with discards at all.
> > and what I also meant is: that you can easily migrate your existing
> > OpenVZ containers to the Proxmox.
> >
> > Proxmox is based on latest Debian Stretch and specifically designed as a
> > distro for contrainers.
> > It has GUI, networking support (including openvswitch and other),
> > KVM/LXC support and many other things (e.g. ceph/glusterfs support).
> >
> > Though, reading you again you've mentioned that you need a specific
> > simfs quota in containers:
> > most likely that would be impossible for unprivileged containers with
> > directory storage (simfs analogue), althrough you could use qcow2 or
> > LVM-based storage for containers.
> >
> >
> > вс, 28 апр. 2019 г. в 09:47, 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 perfectly working on Proxmox kernel 4.15.18-12-pve or
> > even on
> > > 4.13 kernel on DM-Crypt/LUKS setup.
> > >
> > > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> > > talking about.
> >
> > Are you really using OpenVZ 6 with Linux kernel 4.x?
> > Did you see any difficult with Discard when using other context with
> > Linux 4.x ?
> > ___
> > Users mailing list
> > Users@openvz.org 
> > https://lists.openvz.org/mailman/listinfo/users
> >
> >
> > ___
> > Users mailing list
> > Users@openvz.org
> > https://lists.openvz.org/mailman/listinfo/users
> >
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[Paulo Coghi - Coghi IT]

I apologize for the duplicate message. I forgot that I had already sent a
message before.

On Mon, Apr 29, 2019 at 10:52 AM Paulo Coghi - Coghi IT <
pauloco...@gmail.com> wrote:

> Why suggest LXC when we have OpenVZ 7? LXC is far behind, it has less
> features, it's more insecure, has a network standard that is a nightmare,
> etc.
>
> I stopped using proxmox from the exact moment it removed OpenVZ support
> and replaced it with LXC.
>
> Now a happy customer with Virtuozzo 7 (the same as OpenVZ 7) using
> multiple NVMe drives with zero issues for almost 2 years.
>
> On Mon, Apr 29, 2019 at 10:42 AM Narcis Garcia 
> wrote:
>
>> Definitely we'll not migrate to Proxmox because it's suboptimal writing
>> this in OpenDocument format from an HTML5 interface.
>>
>>
>> El 28/4/19 a les 14:37, spameden ha escrit:
>> > No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots
>> > of effort to port their patches over the fresh kernel.
>> >
>> > The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there
>> > is an issue with discard (it doesn't work).
>> >
>> > The discard issue has been fixed in 3.1-mainline kernel I think, you can
>> > look over newish RHEL kernel and try to port those changes to the old
>> > legacy OpenVZ 6 kernel.
>> >
>> > Regarding 4.x kernel:
>> > I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
>> > containers and KVM - and there is no issue with discards at all.
>> > and what I also meant is: that you can easily migrate your existing
>> > OpenVZ containers to the Proxmox.
>> >
>> > Proxmox is based on latest Debian Stretch and specifically designed as a
>> > distro for contrainers.
>> > It has GUI, networking support (including openvswitch and other),
>> > KVM/LXC support and many other things (e.g. ceph/glusterfs support).
>> >
>> > Though, reading you again you've mentioned that you need a specific
>> > simfs quota in containers:
>> > most likely that would be impossible for unprivileged containers with
>> > directory storage (simfs analogue), althrough you could use qcow2 or
>> > LVM-based storage for containers.
>> >
>> >
>> > вс, 28 апр. 2019 г. в 09:47, 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 perfectly working on Proxmox kernel 4.15.18-12-pve or
>> > even on
>> > > 4.13 kernel on DM-Crypt/LUKS setup.
>> > >
>> > > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
>> > > talking about.
>> >
>> > Are you really using OpenVZ 6 with Linux kernel 4.x?
>> > Did you see any difficult with Discard when using other context with
>> > Linux 4.x ?
>> > ___
>> > Users mailing list
>> > Users@openvz.org 
>> > https://lists.openvz.org/mailman/listinfo/users
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@openvz.org
>> > https://lists.openvz.org/mailman/listinfo/users
>> >
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[Narcis Garcia]

Definitely we'll not migrate to Proxmox because it's suboptimal writing
this in OpenDocument format from an HTML5 interface.


El 28/4/19 a les 14:37, spameden ha escrit:
> No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots
> of effort to port their patches over the fresh kernel.
> 
> The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there
> is an issue with discard (it doesn't work).
> 
> The discard issue has been fixed in 3.1-mainline kernel I think, you can
> look over newish RHEL kernel and try to port those changes to the old
> legacy OpenVZ 6 kernel.
> 
> Regarding 4.x kernel:
> I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
> containers and KVM - and there is no issue with discards at all.
> and what I also meant is: that you can easily migrate your existing
> OpenVZ containers to the Proxmox.
> 
> Proxmox is based on latest Debian Stretch and specifically designed as a
> distro for contrainers.
> It has GUI, networking support (including openvswitch and other),
> KVM/LXC support and many other things (e.g. ceph/glusterfs support).
> 
> Though, reading you again you've mentioned that you need a specific
> simfs quota in containers:
> most likely that would be impossible for unprivileged containers with
> directory storage (simfs analogue), althrough you could use qcow2 or
> LVM-based storage for containers.
> 
> 
> вс, 28 апр. 2019 г. в 09:47, 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 perfectly working on Proxmox kernel 4.15.18-12-pve or
> even on
> > 4.13 kernel on DM-Crypt/LUKS setup.
> >
> > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> > talking about.
> 
> Are you really using OpenVZ 6 with Linux kernel 4.x?
> Did you see any difficult with Discard when using other context with
> Linux 4.x ?
> ___
> Users mailing list
> Users@openvz.org 
> https://lists.openvz.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[spameden]

No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots of
effort to port their patches over the fresh kernel.

The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there is
an issue with discard (it doesn't work).

The discard issue has been fixed in 3.1-mainline kernel I think, you can
look over newish RHEL kernel and try to port those changes to the old
legacy OpenVZ 6 kernel.

Regarding 4.x kernel:
I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
containers and KVM - and there is no issue with discards at all.
and what I also meant is: that you can easily migrate your existing OpenVZ
containers to the Proxmox.

Proxmox is based on latest Debian Stretch and specifically designed as a
distro for contrainers.
It has GUI, networking support (including openvswitch and other), KVM/LXC
support and many other things (e.g. ceph/glusterfs support).

Though, reading you again you've mentioned that you need a specific simfs
quota in containers:
most likely that would be impossible for unprivileged containers with
directory storage (simfs analogue), althrough you could use qcow2 or
LVM-based storage for containers.


вс, 28 апр. 2019 г. в 09:47, 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 perfectly working on Proxmox kernel 4.15.18-12-pve or even on
> > 4.13 kernel on DM-Crypt/LUKS setup.
> >
> > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> > talking about.
>
> Are you really using OpenVZ 6 with Linux kernel 4.x?
> Did you see any difficult with Discard when using other context with
> Linux 4.x ?
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[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 perfectly working on Proxmox kernel 4.15.18-12-pve or even on
> 4.13 kernel on DM-Crypt/LUKS setup.
> 
> I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> talking about.

Are you really using OpenVZ 6 with Linux kernel 4.x?
Did you see any difficult with Discard when using other context with
Linux 4.x ?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[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.

I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm talking
about.


> 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:
> > 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
> >  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  > >:
> >
> > 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 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
> > mailto:informat...@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?
> >>
> >> 

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

[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 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 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 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
> mailto:informat...@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
>> mailto:informat...@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.
>>
>>
>> 

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

[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:
> 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
>  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  >:
> 
> 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 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
> mailto:informat...@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
>> mailto:informat...@actiu.net>>:
>>
>> Does anybody know how can I solve this?
>>
>> $ lsb_release -d
>> Description:    Devuan GNU/Linux 1.0 (jessie)
>>
>>

Re: [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  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  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 :
>>
>>> 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 :
>>>
 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
 ├─sda10  512B   2G 0
 └─sda20  512B   2G 0
   └─sda2_crypt00B   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@openvz.org
 https://lists.openvz.org/mailman/listinfo/users

>>>
>>> ___
>>> Users mailing 
>>> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>>>
>>> ___
>>> Users mailing list
>>> Users@openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[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 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
 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 :

> 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 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'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 :
>>>
 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
 ├─sda10  512B   2G 0
 └─sda20  512B   2G 0
   └─sda2_crypt00B   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@openvz.org
 https://lists.openvz.org/mailman/listinfo/users

>>>
>>> ___
>>> 

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

[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 dedication) depend on
me. This is the reason to still be polishing OpenVZ/6 with Devuan/1.


El 27/4/19 a les 16:25, CoolCold ha escrit:
> 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 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'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
>> mailto:informat...@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@openvz.org 
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@openvz.org 
>> 

Re: [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  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 :
>
>> 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 :
>>
>>> 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
>>> ├─sda10  512B   2G 0
>>> └─sda20  512B   2G 0
>>>   └─sda2_crypt00B   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@openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>
>> ___
>> Users mailing 
>> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [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 :

> 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 :
>
>> 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
>> ├─sda10  512B   2G 0
>> └─sda20  512B   2G 0
>>   └─sda2_crypt00B   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@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
> ___
> Users mailing 
> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[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 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  >:
>
> 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@openvz.org 
> https://lists.openvz.org/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

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

[spameden]

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 :

> 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
> ├─sda10  512B   2G 0
> └─sda20  512B   2G 0
>   └─sda2_crypt00B   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@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users