Search results

This worked for me: rm /etc/zfs/zpool.cache Reboot -- though restarting zed may be enough. The reboot may take a minute longer than usual. If your pool(s) fails to import, this will import it and recreate the cache using updated values: zpool import -a

Possibly related (this comment and the one immediately after it): https://forum.proxmox.com/threads/proxmox-ve-7-0-released.92007/post-402308

It looks like this is changed with the cpupower tool: cpupower frequency-set -g SCHEDULER # Examples cpupower frequency-set -g performance cpupower frequency-set -g schedutil

2.0.5 is a bugfix release while 2.1.0 is a new branch with functional ZFS changes that increase the scope of the change. I'd be happy with either one.

Thanks for the update and glad to hear it's on your radar!

ZFS 2.0.5 contains bugfixes for issues that hang ZFS threads and prevent send/receive from functioning (until the next reboot). Particularly (from the changelog): Do not hash unlinked inodes #9741 #11223 #11648 #12210 It was released on June 23, 2021 and we're eager to get this change on to our...

I filed this bug report for the issue: https://bugzilla.proxmox.com/show_bug.cgi?id=3210

I traced the bug to lxcfs: Working: 4.0.3-pve2 Broken: 4.0.3-pve3 I think help is needed from a Proxmox team member on this one.

We've noticed that in recent versions of Proxmox, that /proc/swaps is wrong. It boils down to this inside the container: # free -m total used free shared buff/cache available Mem: 64738 118 64610 7 8 64619...

I have seen the issue on a Proxmox node without any (client or server) NFS.

I have removed "Solved" from the title as the only solution is to manually install and maintain a 4.18+ kernel which isn't feasible / desirable for most users.

This thread may be relevant to your situation: https://forum.proxmox.com/posts/241473/

Based on your listing: Yes, 17754 is the process you want to kill if the nice ways of shutting down the container have failed.

LnxBil is right, snapshots make a terrible situation a non-issue through rollback. I consider this tool mandatory on all ZFS systems: https://github.com/zfsonlinux/zfs-auto-snapshot If you have snapshots and end up with a system that won't boot, you can use a ZFS enabled rescue CD to do the...

When it hits the Grub boot screen, hit 'e'dit. Then remove "quiet" from the kernel options and continue on with the boot. I don't remember the exact key to boot the modified options, but instructions will be on the bottom of the screen when you're editing. That should hopefully give you more...

Although we have Oracle support, we know we're running an unsupported configuration so we focus on MetaLink articles. The biggest gotcha so far has been been that even with all IO set to ASYNCH, Oracle Automatic Diagnostic Repository (ADR) still does Direct IO (which ZFS doesn't support). The...

Have you considered running it in a container (LXC) instead of KVM? That would give you bare metal performance.

It could be a few things. 1) Original Debian install likely wasn't based on ZFS 0.7.12 (latest). After cutting over to the new PVE kernel a ZFS upgrade process will run for 1+ hours in the background impacting performance. If you want to watch for it, hit 'K' (capital) in htop to show kernel...

With sync=disabled, writes are buffered to RAM and flushed every 5 seconds in the background (non-blocking unless it takes longer than 5s to flush). With sync=standard, writes must be flushed to disk anytime software issues a sync request and sync operations block until the disk has acknowledged...

If AppArmor doesn't work you can boot back into an your current kernel and it will be fine. I suspect you won't be able to take libapparmor and apparmor (the package that contains apparmor_parser) from Ubuntu's repos without breaking a bunch of dependencies. If you decide to try the Ubuntu...