[Users] SSD trim support over a LUKS layer
spameden
spameden at gmail.com
Sat Apr 27 23:15:03 MSK 2019
сб, 27 апр. 2019 г. в 20:16, Narcis Garcia <informatica at actiu.net>:
> 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
> > 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
> > <mailto: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
> > <mailto: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 <mailto: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 <mailto: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 <mailto:Users at openvz.org>
> >> https://lists.openvz.org/mailman/listinfo/users
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at openvz.org <mailto:Users at openvz.org>
> >> https://lists.openvz.org/mailman/listinfo/users
> > _______________________________________________
> > Users mailing list
> > Users at openvz.org <mailto:Users at openvz.org>
> > https://lists.openvz.org/mailman/listinfo/users
> >
> > _______________________________________________
> > Users mailing list
> > Users at openvz.org <mailto:Users at openvz.org>
> > https://lists.openvz.org/mailman/listinfo/users
> >
> > _______________________________________________
> > Users mailing list
> > Users at openvz.org <mailto: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/f98c7efa/attachment-0001.html>
More information about the Users
mailing list