The problem I'm looking at is, I had a server start behaving oddly (slowdowns, mostly). You have to adapt to it, not the other way around, and some people find that unacceptable. It also uses some terminology that may take a bit to get straightened out. However, they can potentially mess this up, forcing you to fall back to an older kernel for a bit to maintain access to your backups.Įdit: also, ZFS completely violates the normal Linux layering, so it requires some study to understand what the heck it's doing.
When you install a new kernel, the DKMS subsystem in the package manager will typically recompile and install all the ZFS modules for it, so upgrades are typically seamless. You'll have to do more work to get it running on other distros, although the DKMS system will typically keep you up-to-date without many issues. Only Ubuntu packages the code directly and makes it easy to use. ZFS' main problem is that it's an out-of-tree kernel module, and probably always will be. Just make sure not to use it with SMR disks, as that combo can be extremely troublesome. If you're more serious about preservation, ZFS raidz and especially raidz2 are probably the golden standard for drive reliability. Ext4 or XFS won't know the data is bad unless the disk throws an error, so it's quite possible to get corrupt data from a mirrored pair, as they will typically read from only one disk for any given request. On the other hand, if you're using at least a mirrored disk pair, the bad checksum on one will tell ZFS to use the other, and ZFS then knows for sure which disk has clean data, which makes it better than non-checksumming filesystems.
In a sense, it's worse than other options, because you can't get any of the data back. Once a file comes back as corrupt, any read attempt returns an error. ZFS will be probably the best for telling you if the data is corrupt, but AFAIK it doesn't do recovery on single volumes.
0 kommentar(er)
