Some notes:
1) There is good documentation on how to replace a failed disk. See chapter "Replacing a failed bootable device": https://pve.proxmox.com/wiki/ZFS_on_Linux#_zfs_administration
But yes, would be really nice if that could be part of the webUI as I don't see why this couldn't be easily automated and then heavily reduce human error by not having people to type everything in or getting confused by what partitions to choose for the commands. I could even script a UI for that myself. All thats needed is some UI for selecting the pool name and its failed vdev, the healthy disk, the new disk and some warning that data on the new disk will be wiped. I bet I could also easily pre-select the pool by looking at "zpool status", a healthy disk by looking at the partition layout and a new disk by looking at the size and looking for unpartitioned or factory-prepartitioned NTFS/Exfat formated disks so in most cases replacing a disk would be a single click.
I really don't get why such an important feature is still missing. Especially in cases like this where some typos or missing understanding could cause massive data-loss that easily, there should be done everything possible to reduce human error.
Only problem I see would be people like me not sticking to defaults and doing manual partitioning by encrypting the rpool, adding encryped mdadm swap partitions and so on. But these people probably know what they are doing and are fine replacing the disk manually via CLI like it is done now. You could even exclude disks from the UI that doesn't match the default partitioning scheme by looking for part 1-3 or 1+9 and if other partitions are found.
2.) While only the 3rd ZFS partition is actually mirrored I don't see a problem why this should be a problem. Only other things on those disks are the first partition that is there for legacy reasons and not used at all. And the second ESP with the bootloader. But that one doesn't need to be mirrored because it is automatically kept in sync with the other disk via the proxmox-boot-tool. So there is always a working and recent copy of the bootloader on the other disk in case any disk fails.
I've got a lot of failed mirrored system disks and once you understand how to replace a disk there is really no problem at all. Once a disk fails everything will continue running as usual and you can hotswap the failed disk and fix the mirror without any downtime. And even if the whole server would crash or you reboot it with a failed disk, as long as you set up both disks as the first and second boot options in bios it will boot as normal from the remaining disk.
3) Those firecudas aren't enterprise/datacenter grade SSDs. They are only pro-sumer grade. They are missing the power-loss protection that is needed to not totally suck on sync writes. Once you do sync writes (like ZFS does when storing metadata) performance will be magnitudes worse (like factor 100) and write amplification (and therefore wear) will be much higher. As sync writes then can't be cached in DRAM.
SSDs without a buikt-in power-loss protection behave like HW raid cards without a BBU+cache.
1) There is good documentation on how to replace a failed disk. See chapter "Replacing a failed bootable device": https://pve.proxmox.com/wiki/ZFS_on_Linux#_zfs_administration
But yes, would be really nice if that could be part of the webUI as I don't see why this couldn't be easily automated and then heavily reduce human error by not having people to type everything in or getting confused by what partitions to choose for the commands. I could even script a UI for that myself. All thats needed is some UI for selecting the pool name and its failed vdev, the healthy disk, the new disk and some warning that data on the new disk will be wiped. I bet I could also easily pre-select the pool by looking at "zpool status", a healthy disk by looking at the partition layout and a new disk by looking at the size and looking for unpartitioned or factory-prepartitioned NTFS/Exfat formated disks so in most cases replacing a disk would be a single click.
I really don't get why such an important feature is still missing. Especially in cases like this where some typos or missing understanding could cause massive data-loss that easily, there should be done everything possible to reduce human error.
Only problem I see would be people like me not sticking to defaults and doing manual partitioning by encrypting the rpool, adding encryped mdadm swap partitions and so on. But these people probably know what they are doing and are fine replacing the disk manually via CLI like it is done now. You could even exclude disks from the UI that doesn't match the default partitioning scheme by looking for part 1-3 or 1+9 and if other partitions are found.
2.) While only the 3rd ZFS partition is actually mirrored I don't see a problem why this should be a problem. Only other things on those disks are the first partition that is there for legacy reasons and not used at all. And the second ESP with the bootloader. But that one doesn't need to be mirrored because it is automatically kept in sync with the other disk via the proxmox-boot-tool. So there is always a working and recent copy of the bootloader on the other disk in case any disk fails.
I've got a lot of failed mirrored system disks and once you understand how to replace a disk there is really no problem at all. Once a disk fails everything will continue running as usual and you can hotswap the failed disk and fix the mirror without any downtime. And even if the whole server would crash or you reboot it with a failed disk, as long as you set up both disks as the first and second boot options in bios it will boot as normal from the remaining disk.
3) Those firecudas aren't enterprise/datacenter grade SSDs. They are only pro-sumer grade. They are missing the power-loss protection that is needed to not totally suck on sync writes. Once you do sync writes (like ZFS does when storing metadata) performance will be magnitudes worse (like factor 100) and write amplification (and therefore wear) will be much higher. As sync writes then can't be cached in DRAM.
SSDs without a buikt-in power-loss protection behave like HW raid cards without a BBU+cache.
Last edited:
