61–70 of 90 posts
https://github.com/openzfs/zfs/pull/15529#pullrequestreview-... Honestly, ZFS is the best thing on the (Free)BSDs only... On Linux it doesn't even use the page cache, and you conflict severely with L2ARC. I know there's a variety of people who don't care, but still for real users it's not an actual option.
This is the case on FreeBSD as well, ZFS uses its own cache, but UFS and I guess other filesystems use the kernel page cache.
Is there any good beginner friendly documentation for zfs? I've started using it as a testing/learning NAS with a raspberry pi (cloning my google library to immich). It has not been a clearly easy process and errors are very much not clear. I recently extended a single drive to 2 and now I can't import due to corrupted metadata and reports bad disk but smartctl reports all fine. Stack overflow is all over the place a…
I find klarasystems articles and Mr Salter articles on arstechnica are a good start point
Earlier quoted context omitted.
I think he means an equivalent for `fsck`.
`zfs scrub` is equivalent to `fsck`. It just has a different name, and it can fix more kinds of corruption (including corrupted data, which `fsck` for other file systems can never do), and can do so on line. Of course zfs can fix those same errors on line while doing ordinary reads, so really all `zfs scrub` does is read everything. `zfs scrub` is better than `fsck`.
`zpool scrub` walks every block in the pool, and implicitly, you do checksums and other things while doing that. That's it.
It's not doing any sort of logic bug repairs or cleanup or anything else.
It's also not checking that you can, say, decrypt things, since that would mean you needed the keys to scrub.
Since the problem is in the read path, having copied them off ZFS might result in them being incorrect on the destination, modulo all the caveats about this being quite rare and hard to hit unless you're very deliberately trying.
You can reproduce this back on 0.6.5 and pre-OpenZFS merge FreeBSD and illumos, if you really want to.
I come from the GPFS, Lustre, and Panasas world of HPCC. Personally, I used (past tense) ZoL in 2014-2017 on Ubuntu. The issue is that the array eventually entered an unrecoverable state where it could no longer be mounted RW. That wasn't the end of the world, but the support from ZoL was to shrug at it. That was the end of that because without support and without pride, something that appears shiny is effectively us…
I would suggest that you should probably have a support contract with _somebody_ if you want a guaranteed turnaround time on responses. Plenty of people are paid to work on OpenZFS, but if you're not the one paying them, then it's always going to be a best effort thing.
Since the incorrect code dates back to Sun, I don't know that you should be using this specific bug to cast stones.
Earlier quoted context omitted.
The packaging was a major reason for switching to btrfs. I run sudo dnf upgrade and that's it, my system is upgraded. Zero issues ever. With ZFS I had to pin to older kernel versions, not to mention a bunch of manual steps and cleanup after any major version upgrade (every 6-12 months). Re btrfs raid 5/6, yes everyone knows about this, and this is why I have it only on my backup system. My primary data which holds 15…
I wonder if a metapackage that always depends on kernel <= supported would resolve the issue by ensuring you don't need to pin a specific version manually.
This bug shouldn't really scare people. It's requires such an incredibly specific workload to hit Here's a post by RobN (the dev who wrote the fix) on the ZFS On Linux mailing list > There's a really important subtlety that a lot of people are missing in this. The bug is _not_ in reads. If you read data, its there. The bug is that sometimes, asking the filesystem "is there data here?" it says "no" when it should say…
> ask yourself if you've ever had highly parallel workloads that involve writing and seeking the same files at the same moment. Uhhhh, databases?
Earlier quoted context omitted.
`zfs scrub` is equivalent to `fsck`. It just has a different name, and it can fix more kinds of corruption (including corrupted data, which `fsck` for other file systems can never do), and can do so on line. Of course zfs can fix those same errors on line while doing ordinary reads, so really all `zfs scrub` does is read everything. `zfs scrub` is better than `fsck`.
It is not. `zpool scrub` walks every block in the pool, and implicitly, you do checksums and other things while doing that. That's it. It's not doing any sort of logic bug repairs or cleanup or anything else. It's also not checking that you can, say, decrypt things, since that would mean you needed the keys to scrub.
In truth fsck is a wart, a kludge, a bag on the file system design.
Earlier quoted context omitted.
It is not. `zpool scrub` walks every block in the pool, and implicitly, you do checksums and other things while doing that. That's it. It's not doing any sort of logic bug repairs or cleanup or anything else. It's also not checking that you can, say, decrypt things, since that would mean you needed the keys to scrub.
It really is better. The key difference to understand is that in ext4 any form of metadata corruption which can be automatically fixed requires you to take the filesystem off–line (to unmount it), and then run fsck. Meanwhile with zfs, any form of metadata corruption which can automatically be fixed is simply fixed right on the spot, transparently. In truth fsck is a wart, a kludge, a bag on the file system design.
The key thing to realize is that you can't, actually, automatically fix every problem, sometimes you have found a logic problem which results in an impossible outcome and you need someone to manually clean it up.
In a world without flaws, it would be great to never need that. But the thing about theory and practice is that in theory, they never differ, but in practice...
Earlier quoted context omitted.
> ask yourself if you've ever had highly parallel workloads that involve writing and seeking the same files at the same moment. Uhhhh, databases?
Databases don't involve using SEEK_HOLE to find gaps in a sparse file, usually, so it wouldn't come up here.