Finally, this means we've a way to share "real" filesystems on both FreeBSD and Linux. The only other filesystems you could open without issues on both are FAT and NTFS (thought NTFS-3G), both of which are less than ideal for data you care about.
OpenZFS 2.0
111–120 of 151 posts
Re: OpenZFS 2.0
#112Zstd compression with configurable levels is really interesting: You could write every block first with a level comparable to lz4 for very fast performance. And if a block has not been rewritten for some time you recompress them with a compression level allowing more compression and comparable decompression performance.
So cold data (cold write, cold/hot read) will take less and less space over time while still having the same read performance.
Re: OpenZFS 2.0
#113Earlier quoted context omitted.
zfs on linux available as root partition since 20.04. Working quite well I might add!
That’s Ubuntu-specific where they provide their own kernel bundled with ZFS. It was working fine before 20.04 as well in the same way it does for other distros. Has nothing to do with the comment you’re replying to.
There's not much of a difference betweens building with a kernel module or building an independent kernel module. I can't figure out what the question being asked is, but I don't see how Ubuntu would matter.
Re: OpenZFS 2.0
#114Earlier quoted context omitted.
Ubuntu 20.10 has an option in installer to use ZFS encryption for root partition.
Oh sweet, I don't think encryption was an option in 20.04. Is it still under an "experimental" option in the installer?
Yeah, still experimental but improved over 20.04. Added encryption and "autotrim=on" by default.
I think Canonical planing is to have ZFS as an experimental option only for Desktop version of Ubuntu until next LTS release.
Re: OpenZFS 2.0
#115Earlier quoted context omitted.
YES! Step by step and keep XFS as stable as it is (the most trustworthy linux FS of them all)
During my last >15 years of Linux usage, I had exactly the two filesystems you are advocating for here crashing on me: - XFS, long time ago, had a bug that made it lose files silently - BTRFS twice, most recently about a year ago in a super simple setup (no raid or any other fanciness). I wasn't able to recover it, after a while I at least got it to mount as ro and copied the contents away These were all on Gentoo, s…
>reiserfs
That was exactly the FS that eat my data back in ~2005. Never had problems with XFS or ZFS. With Btrfs well i just use it regularly since 2 years so i cant say much, but i think Redhat chose XFS for a reason.
Re: OpenZFS 2.0
#116I'd love to get rid of my FreeNAS VM and run ZFS directly on my Linux desktop, but having to mess with the kernel has kept me from attempting it so far. Maybe I'm worrying about nothing. btrfs seems like the main alternative if you want native kernel support, but when I checked a couple years ago there seemed to be a lot of concerns about the stability. Is that still the case?
On the btrfs mailing list [1], there are still sporadic reports of unrecoverable FS corruption for whatever reason. See [2], [3] for some recent examples. [1] https://lore.kernel.org/linux-btrfs/ [2] https://lore.kernel.org/linux-btrfs/CAD7Y51i=mTDnEWEJtSnUsq=... [3] https://lore.kernel.org/linux-btrfs/CAMXR++KUj2L7qpR7QZeiM2T...
[3] is interesting, thanks for linking that. [2] has so many moving parts, I wouldn't expect it to be related to btrfs without more information. I mean, there's both the fs and the cache layer being resized down, with unknown method.
Re: OpenZFS 2.0
#117This 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.
rsync doesn't scale like zfs send/recv. It requires scanning of every file at both the source and destination to compute the delta to send. zfs snapshots and send/recv don't need to do that. The delta is already fully described by the snapshots themselves. zfs is also working with immutable snapshots. It guarantees the source and destination copies are identical; rsync can't do much about the source and destination being modified while it is running since it's reliant upon other users of the system not touching the data being synced.
That's not to say rsync doesn't work. It does. But it doesn't scale well, and the data integrity guarantees aren't there.
Re: OpenZFS 2.0
#118Earlier quoted context omitted.
>ZFS directly on my Linux desktop Use BTRFS trust me it's stable now...well the commands are terrible compared to ZFS. All my Server are FreeBSD but on the Laptop and on one Workstation i have openSUSE Tumbleweed since like 2 years and it works great.
> well the commands are terrible compared to ZFS Really? I don’t think so, I find btrfs usage extremely straightforward and easy to grok. ZFS on the other hand has all that confusing lingo about vdevs, etc... I get that this is subjective but I disagree.
The Brtfs commands are very poor compared with what ZFS offers. The ZFS commands are organised around the end user: the system administrator. The Brtfs commands are not.
As an example, you're running low on space and need to find out which datasets (subvolumes) are using the most space. How do you do that? With ZFS it's a single command which runs in a few milliseconds. With Btrfs...
Re: OpenZFS 2.0
#119Side note, they really should have in big-bold letters "DO NOT ENABLE DEDUPLICATION UNLESS YOU HAVE A TON OF RAM!" on their readme. That was a huge mistake on my part. The ram requirements are VERY high for good performance. I realized how bad the performance was when it took about 2 hours to delete 1000 files.
Most guides I read tell you that you should not enabled DEDUP unless you know what you are doing and it will use a lot of ram.