Zfs does not work well on sparse volumes, it loves new blocks. That's why you don't see it much in a VM or on storage that is sparse (go nimble, NetApp, etc)
Also it's pretty much impossible to grow a zfs pool and there are no consistency check tools or repair tools. So when you actually do get corruption, you lose it all.
Might have been a breakthrough around 2000 but it's time for something new.
> Also it's pretty much impossible to grow a zfs pool and there are no consistency check tools or repair tools.
This is flat out wrong. First you can trivially grow a zpool by adding another vdev to it. If you can't do that, you can grow a vdev, and hence the zpool using that vdev, by swapping the disks for larger disks one at a time. Once all the physical disks in the vdev are of the new, larger size, the new space will become available automatically.
Also there's absolutely a consistency check and repair tool built in. ZFS computes and stores checksums for all blocks, even when you use a single disk!. It also verifies the checksums when reading blocks. In addition you can trigger a verification of all the blocks by running a scrub command, which simply issues a read for all the blocks.
> So when you actually do get corruption, you lose it all.
Hardly. Not only does ZFS have the above, it also stores multiple copies of important metadata blocks (three copies by default), and it even takes effort to spread those blocks out on the physical disks to reduce the chance of them getting corrupted as much as possible.
I'm not saying ZFS is the perfect filesystem. But it's definitely one of the better if you care about your data.
> Also it's pretty much impossible to grow a zfs pool and there are no consistency check tools or repair tools. So when you actually do get corruption, you lose it all.
`zpool scrub` is the consistency check and repair tool. It's happy to detect and repair everything from bit flips to realtime `dd if=/dev/random of=/dev/ada0` of a mirrored/raid-z disk.
Growing a single vdev can be impractical especially for raid-z. Adding new vdevs to a pool is straightforward.
So tired of seeing this. The problem is you don't want to do ANY striping on ANY SMR drives. It's not a ZFS problem. It's not a SMR problem. It's STRIPING on SMR. PERIOD.
Once upon a time people knew what they were talking about. Now everybody's an EXPERT NPC.
Could you explain why? Isn't the problem rather in the fact the filesystem does not know it is SMR and does not have a capability to work with such device optimally?
Pluto tv reminds me of those telemarketers that won't stop calling. Once I signed up I got endless spam and phishing attempts in my inbox making it almost unusable.
