7 ms·

My experience has been aggravated by being simultaneously affected by https://github.com/openzfs/zfs/issues/11893 https://github.com/openzfs/zfs/issues/11893, w

by 3np 3y ago

My experience has been aggravated by being simultaneously affected by https://github.com/openzfs/zfs/issues/11893 https://github.com/openzfs/zfs/issues/11893, which results in all zfs operations hanging (kill -9 is ineffective) until a power cycle. This round of upgrades was not fun. Debian bookworm users: You need to enable backports for zfs. Both bugs are fixed in backports but still present in stable. Let's do away with the tribalism in both ways? Calling it perfect is quite a stretch. I'm not saying "don't use zfs", just "you want to be prepared for the worst-case if your data matters". 3-2-1 and "validate your backups" still apply.

buildbot 3y ago
Perfect for me is not perfect for others of course. I have not run into the issue you linked, that sounds frustrating to deal with. Backups is the only (near) 100% way to insure you data I agree.
sgarland 3y ago
As someone currently rewriting Ansible plays to build Bookworm QEMU images with ZFS support, thank you for this incredibly niche and useful bit of information.
- 3np 3y ago
  Np! Actually, in case you're able to share some of those plays in any form, that could be very useful here, however niche :)
  - sgarland 3y ago
    I have an older version [0] for Bullseye that you're welcome to take a look at. It's actually combined Ansible + Packer, so if you point it at a Proxmox host, you get an image in ~10-15 minutes. It's a fork of other work [1], modified and updated for Debian and Debian only. It also in absolutely no way has any best practices, which is why I'm doing a complete re-write with proper role dependencies, modularity, etc. When that's done, I'll be marking [0] as archived and linking to the new repo. The new version also replaces the incredibly hacky shell script builder (hooray dialog) with Python, and updates Packer's JSON with HCL2. [0]: https://github.com/stephanGarland/packer-proxmox-templates https://github.com/stephanGarland/packer-proxmox-templates [1]: https://github.com/chriswayg/packer-proxmox-templates https://github.com/chriswayg/packer-proxmox-templates
    - 3np 3y ago
      Thank you!

by 3np 3y ago

buildbot 3y ago

Perfect for me is not perfect for others of course. I have not run into the issue you linked, that sounds frustrating to deal with. Backups is the only (near) 100% way to insure you data I agree.

sgarland 3y ago

As someone currently rewriting Ansible plays to build Bookworm QEMU images with ZFS support, thank you for this incredibly niche and useful bit of information.

3np 3y ago
Np! Actually, in case you're able to share some of those plays in any form, that could be very useful here, however niche :)
- sgarland 3y ago
  I have an older version [0] for Bullseye that you're welcome to take a look at. It's actually combined Ansible + Packer, so if you point it at a Proxmox host, you get an image in ~10-15 minutes. It's a fork of other work [1], modified and updated for Debian and Debian only. It also in absolutely no way has any best practices, which is why I'm doing a complete re-write with proper role dependencies, modularity, etc. When that's done, I'll be marking [0] as archived and linking to the new repo. The new version also replaces the incredibly hacky shell script builder (hooray dialog) with Python, and updates Packer's JSON with HCL2. [0]: https://github.com/stephanGarland/packer-proxmox-templates https://github.com/stephanGarland/packer-proxmox-templates [1]: https://github.com/chriswayg/packer-proxmox-templates https://github.com/chriswayg/packer-proxmox-templates
  - 3np 3y ago
    Thank you!