upgrade zfs-0.7.0
- Thread starter flexyz
- Start date
That's why I asked Fabian if it was fixed in the new release!! Maybe in your country fix mean something else. but please stop trolling.I don't think my comment is useless
I know there was a new .iso, that does not mean that packages that are not already in regular pve-no-subscription repo are included in the .iso, they build the .iso with stable packages..
Also, a new feature/version is not a "fix" .. a fix is if something is broken.
Hi
Is it possible in any way to compile latest zfs to proxmox - I just want to do some basic testing with the encryption part
Thanks
Is it possible in any way to compile latest zfs to proxmox - I just want to do some basic testing with the encryption part
Thanks
encryption in ZFS is not part of any released version yet (the PR has been merged in to the master branch, but that was after 0.7 was split off). it will likely be part of the 0.8.x release
Yes I know that 
- but if I can compile zfs for proxmox I could test it - so if it is possible please let me know - I could compile deb packages
- but if I can compile zfs for proxmox I could test it - so if it is possible please let me know - I could compile deb packages
you can find our packaging (on top of the one done by debian) on our public git mirror: https://git.proxmox.com/?p=zfsonlinux.git;a=tree
but adapting that to work with ZFS and SPL master is not an easy task unless you are both familiar with Debian packaging and the relevant code bases.
but adapting that to work with ZFS and SPL master is not an easy task unless you are both familiar with Debian packaging and the relevant code bases.
It is possible to build ZFS 0.7.1 yourself. Bear in mind that unless you know what you're doing, this is a great way to have an unbootable Proxmox host (especially if you upgrade the pool or the kernel). I would definitely experiment with this on a test box to make sure you're comfortable with the procedure.
That said, the basic idea is to download the source, build the packages, then make sure they're packed into the initramfs (which is tricky because by default the new modules aren't found). You'll have to repeat this every time you update the kernel, since ZFS doesn't support DKMS on Debian.
Try this:
After this you'll need to reboot to actually use the new kernel modules (you can't rmmod them because they're in use for your root filesystem). I'd advise rebooting immediately, because the new ZFS tools won't play well with the old kernel module.
If anyone wants, I can post prebuilt packages for kernel version 4.10.17-2-pve.
That said, the basic idea is to download the source, build the packages, then make sure they're packed into the initramfs (which is tricky because by default the new modules aren't found). You'll have to repeat this every time you update the kernel, since ZFS doesn't support DKMS on Debian.
Try this:
Code:
#!/bin/sh
# This script builds and installs ZFS 0.7.1 packages on a Proxmox host.
# This is unsupported and you do so at your own risk!
# Install dependencies (pve-headers is Proxmox-specific)
apt-get install build-essential autoconf libtool gawk alien fakeroot pve-headers git \
zlib1g-dev uuid-dev libattr1-dev libblkid-dev libselinux-dev libudev-dev parted lsscsi wget ksh
# Build SPL
git clone git://github.com/zfsonlinux/spl.git
cd spl
git checkout spl-0.7.1
./autogen.sh
./configure
make pkg-utils pkg-kmod
apt remove spl
dpkg -i -- *.deb
cd ..
# Build ZFS
git clone git://github.com/zfsonlinux/zfs.git
cd zfs
git checkout zfs-0.7.1
./autogen.sh
./configure
make pkg-utils pkg-kmod
apt remove libuutil1linux libzfs2linux libzpool2linux zfs-initramfs zfsutils-linux
dpkg -i *.deb
cd ..
# Force depmod to find the new packages
mkdir -p /etc/depmod.d
echo 'search extra' > /etc/depmod.d/zfs.conf
depmod -a
update-initramfs -uAfter this you'll need to reboot to actually use the new kernel modules (you can't rmmod them because they're in use for your root filesystem). I'd advise rebooting immediately, because the new ZFS tools won't play well with the old kernel module.
Last edited:
please don't, and I would advise anybody else to stay away from those instructions. I know this was probably well-intended, but these packages are akin to something Dr. Frankenstein might create in his spare time. upstream only provides a way to "build" Debian packages by building RPM packages, and then "converting" them using alien. this means that any and all integration into Debian is missing, and not even all of the package contents which are supposed to be there are (e.g., currently all systemd units are missing from the packages). if you do install packages this way, please clearly say so in any posts referring to potential issues, so I can skip them
just be patient, we will have early test packages available soon.
Yeah, I agree, unless you're just experimenting I'd definitely wait for official Proxmox support. Upstream's notion of Debian support is not up to normal Debian packaging standards, and certainly not up to the level of stability you expect from your hypervisor.
Case in point.
Yay!
I'll rescind my offer of binaries, just to minimize the headache they might indirectly cause Proxmox devs.
as always - when it's done it's done
Hi Fabian.
I have a question, what is the estimated time of completion on this?
Do you have any blockers that stop the creation of the latest ZFS+SPF in Proxmox-Test?
Kindly
// T
the main blocker currently is that zfs send from 0.7 and zfs recv from 0.6.5 are incompatible.
no it is not, it is unintentional breakage on upstream's part, and leads to hanging zfs recv threads in kernel space. given that we have a ZFS-based replication feature that would trigger this on all replication targets once the first node is updated, this is definitely a blocker for PVE at the moment (until either we either have a working fix for ZFS, or implemented a workaround in PVE - currently working on the former, the latter is our 'emergency exit'
).I have tested your script in a test box and it worked like a charm.
The performance with zfs 0.7.1 has been increased a lot.
Hope it will be added to pve-test repository soon.
Strange...I have been able to send and receive datasets between hosts with 0.6.5 and 0.7.1 without errors
What you expect is "forward compatibility", but in software industry it is rarely guaranteed without back-porting new features to previous version...
no it is not. what I expect (and ZFS does in most cases) is backwards compatibility - zfs send will hide features breaking backwards compatibility behind a feature flag (see the large_dnode feature for an example of this), so that it is possible to send and recv to an older version. while this is not guaranteed, it is very much desired - and in this case, an unintentional incompatibility slipped into 0.7, with no way of turning it off.
@javildn: possibly you have not tested the correct direction (it's only broken from new to old)? it is very easily reproducible here.