91–100 of 151 posts
Has there been any progress on the zfs on linux Linus disagreement front since this article? https://arstechnica.com/gadgets/2020/01/linus-torvalds-zfs-s...
zfs on linux available as root partition since 20.04. Working quite well I might add!
Earlier quoted context omitted.
zfs on linux available as root partition since 20.04. Working quite well I might add!
It's still a big pain if you like to keep your kernel relatively up to date. I switched to btrfs; it just working is worth the few extra warts over ZFS.
Replacing a core system component with an out-of-repo version is always going to hurt, yes.
> I switched to btrfs; it just working is worth the few extra warts over ZFS.
I'm not sure I'd call "catastrophic failure and data loss" a "wart". In all my years of distro hopping, I've had 3 root filesystems become unbootable: 1 F2FS system early on, which I actually did manage to fsck out of, and 2 on an openSUSE tubleweed system using BTRFS as root.
Earlier quoted context omitted.
It's still a big pain if you like to keep your kernel relatively up to date. I switched to btrfs; it just working is worth the few extra warts over ZFS.
> It's still a big pain if you like to keep your kernel relatively up to date. Replacing a core system component with an out-of-repo version is always going to hurt, yes. > I switched to btrfs; it just working is worth the few extra warts over ZFS. I'm not sure I'd call "catastrophic failure and data loss" a "wart". In all my years of distro hopping, I've had 3 root filesystems become unbootable: 1 F2FS system early…
How long ago was that? and have you been using other fully checksummed filesystems (like ZFS) on that hardware since then? I'm asking because if you're using btrfs without any raid features (or with simple RAID modes like 1/0) for the past several years and it breaks, if you dig deep enough into the problem, often the hardware is found to be at fault.
And ext4 or xfs either don't find corruption at all (if it's data corruption), or have better error recovery if the FS's own metadata got trashed (which is a strong argument in favor of them, I agree, but I wouldn't trust such a filesystem anyway and would restore from backups right away).
Edit: it's a strong argument for storing data on them which is checksummed by some higher component in your software stack, like the database. Otherwise, you're just asking for silent data bitrot.
Earlier quoted context omitted.
zfs on linux available as root partition since 20.04. Working quite well I might add!
It's still a big pain if you like to keep your kernel relatively up to date. I switched to btrfs; it just working is worth the few extra warts over ZFS.
This is huge! And very exciting :D One thing I am wondering about is this: > Redacted zfs send/receive - Redacted streams allow users to send subsets of their data to a target system. This allows users to save space by not replicating unimportant data within a given dataset or to selectively exclude sensitive information. #7958 Let’s say I have a dataset tank/music-video-project-2020-12 or something and it is like 40…
That's a protocol problem, use a protocol such as rsync. You don't need to use redacted sends/recvs.
Earlier quoted context omitted.
>in the future XFS (when they have full check-summing). Is this actually planned?
YES! Step by step and keep XFS as stable as it is (the most trustworthy linux FS of them all)
These were all on Gentoo, so with relatively recent tools and vanilla kernels.
The only filesystems that I never had problems with were ext4 and reiserfs.
Has there been any progress on the zfs on linux Linus disagreement front since this article? https://arstechnica.com/gadgets/2020/01/linus-torvalds-zfs-s...
zfs on linux available as root partition since 20.04. Working quite well I might add!
Earlier quoted context omitted.
Why ZFS encryption vs unencrypted ZFS atop LUKS?
I wanted to say "as someone who tends to follow the unix philosophy" and realized the irony of saying that regarding ZFS... That said, I generally agree with you in that do one thing and do it well is a laudable design goal. However, I also am very excited about encrypted ZFS for one main reason: backups. Okay two. Snapshots and backups! ZFS is absolutely amazing to use as a home NAS that does daily (or more) snapsho…
It's just that majority of users never have reason to see more than tiny signs of the layers hidden behind (mostly) 2 command line tools, and for various reasons those layers are compiled into one one module.
But the clean layered design is how LustreZFS happened :)
Earlier quoted context omitted.
Because traditionally, programs do one thing well. And in my experience LUKS works great.
If you're using ZFS, you're already okay with some level of ignoring that; ZFS is a inherently huge layering violation. It's a filesystem and a volume manager with encryption and compression, its own user access system (zfs allow), and its own NFS implementation.
It's a very cleanly layered system, it just doesn't bother end user with details (as implementor, you can play with them, thus LustreZFS): there's separate SPA (block), DMU (OSD) and ZPL (FS) & ZVOL (emulated block device) layers.
Compression and encryption are integrated at DMU level because that's a logical place for them.
NFS actually calls OS nfs server.