141–150 of 198 posts
I prefer just to have mirrors but its cool that it slowly coming, some people seem to really want this feature. ZFS has been amazing to me, I have zero complaints. I just wish it wouldn't have taken so long to come to /root on linux. Even still today you have to a lot of work unless you want to use the new support in Ubuntu. This license snafu is so terrible, open-source licenses excluding each other. Crazy. The worl…
Earlier quoted context omitted.
I've lost data in BTRFS setups each of the three times I've given it a try over the course of 6 or so years. Root drive just became unrecoverable. These are all single disk setups Meanwhile I've been running ZFS for close to the same time and have never lost anything. I get it's an anecdotal view point but that's a very hard reputation to rebuild for BTRFS.
I really just don't care about anecdotal data bits like this, especially when these attempts were tried probably 8+ years ago under who knows what conditions. How long ago did you give up btrfs, how long has it been, since your 6 years of trying it?
If the btrfs failed for you, you’ll remember and likely won’t try again. I had that experience with a now defunct hard drive maker. After the second replacement one failed I vowed never again.
They probably should rename it.
Earlier quoted context omitted.
Actually there's more! A new version of TrueNAS is in the works, it's called TrueNAS scale and it's going to be Linux-based (no more FreeBSD). I'm frankly happy, because TrueNAS is great as a NAS operating system but I really wanted to run containers where my storage is and having to run a VM adds a really unnecessary overhead (plus, it's another machine to manage)
Ah, so Linux is approaching feature parity with FreeBSD jails?
What do FreeBSD jails do that Linux can't? I know there's no single jail system call that you can call so you need to assemble the container "manually", but that's an implementation detail as far as I am concerned.
On the other hand, true network namespaces (VNET on FreeBSD) have been usable on Linux for longer than on FreeBSD.
It's a bit disingenuous to say that Linux is the one "approaching" feature parity when they're both missing features that the other has.
Earlier quoted context omitted.
ZFS RAID is the best RAID implementation in many respects. Hardware RAID is bad at actually fixing errors on disk (as opposed to just transparently correcting) and surfacing errors to the user. BTRFS is frequently not considered stable enough for production usage. ZFS has dozens of useful features besides RAID. Transparent compression, instant atomic snapshots, incremental snapshot sync, instant cloning of file syste…
>BTRFS is frequently not considered stable enough for production usage. I'm not sure this is still true, especially after Facebook deployed it on millions of servers. https://btrfs.wiki.kernel.org/index.php/Production_Users https://btrfs.wiki.kernel.org/index.php/Production_Users
For example, detecting corruption would be more important than never having any, so that you can get IO errors and immediately kill the server before it serves bad data.
Earlier quoted context omitted.
For my big media volume, which had existed for around 10 years, I use snapraid. Because of several things: * I can mix disk sizes * I can add new disks over time as needed * If something dies, up to the entire server, I can just stick any data disk in another system and read it I didn't want to become a zfs expert (and the learning curve seems steep!), and I didn't want to spend thousands of dollars on new gear (dedi…
UnRaid and Synology user here and I completely agree with all your points. The knowledge that at worst I will lose the data on just 1 disk (or 2 if I fail during a rebuild) is very calming. If not for UnRaid there is no way I could manage the size of the media volume I maintain (from a time, energy, and money perspective). I mean if you know ZFS well and trust yourself then more power to you but UnRaid and friends fi…
I prefer just to have mirrors but its cool that it slowly coming, some people seem to really want this feature. ZFS has been amazing to me, I have zero complaints. I just wish it wouldn't have taken so long to come to /root on linux. Even still today you have to a lot of work unless you want to use the new support in Ubuntu. This license snafu is so terrible, open-source licenses excluding each other. Crazy. The worl…
ZFS on root is super easy in NixOS. (And I agree with your licensing point.)
I still haven't played around with Nix, but I know I should.
Earlier quoted context omitted.
Simplicity. There's a lot of complexity in ZFS I'd rather not depend on, and because it does so many things it's a big investment and liability to switch to. While I understand why it would be useful in a corporate setting, for personal use I've found the combination of LUKS+LVM+SnapRAID to work well and don't see the benefit of switching to ZFS. Two of those are core Linux features, and SnapRAID has been rock solid,…
What about if you were just starting today, with 0 knowledge about basically anything related to storage and how to do it right? That's my case, I'm learning before setting up a cheap home lab and a NAS, and I'm wondering if biting into ZFS is just the best option that I have given today's ecosystem.
Looking back, the lessons that come to mind are:
- Always have 2 backups (not counting the primary copy), at least 1 "cold" (inaccessible without human intervention) and at least 1 offsite. Backup frequently and retain old backups. With backups, bad decisions are reversible.
- With btrfs or zfs, using a collection of 2-disk mirrors was useful because it provided flexibility (to expand the array, just add another pair of disks) and seemed to have better performance than a single disk. Try to pair disks from different manufacturing batches though. I saw two disks from the same batch and _used in the same mirror_ fail in the same month, which was disconcerting.
- The only data corruption I had to deal with was from RAM that started off good and went bad after a couple years.
- Standardizing on btrfs or zfs from the beginning would have allowed backup by sending snapshots, which would have been a lot easier than cobbling together a solution using rsync.
- Scrub on a regular schedule. Set up monitoring software to notify you of the outcome of each scrub and of any SMART errors.
this might sound like a troll comment but its coming from someone with almost zero experience with raid. What is the purpose of ZFS in 2021 if we have hardware RAID and linux software RAID? BTRFS does RAID too. Why would people choose ZFS in 2021 if both Oracle and Open Source users have 2 competing ZFS? are they interoperable?
Today's many-TB hard drives use mind-boggling engineering to shrink data fluctuations down almost to the size of individual atoms (not quite there yet, but making progress (!)), while higher I/O speeds push the onboard processors' ECC mechanisms almost beyond breaking point.
This basically means that the likelihood of HDDs returning uncaught bit errors has gone from a maybe-once-in-a-lifetime event (with very large magnetic flux sizes on disk in the 80s) to something that individual power users using disks with great-looking SMART output should generally expect to see every few months or years+.
My rule of thumb is that any storage device over maybe 250GB-500GB in size needs to be redundant. If you can shove that much data into one place, the odds that something significant will be hiding somewhere in that data easily go beyond 100% once you go past that size range, IMO.
this might sound like a troll comment but its coming from someone with almost zero experience with raid. What is the purpose of ZFS in 2021 if we have hardware RAID and linux software RAID? BTRFS does RAID too. Why would people choose ZFS in 2021 if both Oracle and Open Source users have 2 competing ZFS? are they interoperable?
No matter what happens, people will seemingly forever declare BTRFS is not as stable and not as safe. There's a status page that details what BTRFS thinks of itself[1], and I doubt any of the many people docking BTRFS have read or know or care what that page says. There is one issue still being worked out to completion, a "write hole" problem, involving two separate failures, an unplanned/power-loss shut-down, follow…
Look here is the problem. The BTRFS people declared multiple time that it is stable. For a few years it was repeatably 'BTRFS' is stable now if you use it in such an such a away.
But then it destroyed a drive.
Then it a few years later and now it was actually stable.
But then it destroyed data again.
I know what they are saying about themselves but unfortunately the project has simply lost credibility with a lot of people. File system should be developed to be stable first and then slowly add features never being unstable. They shouldn't still regularly destroy peoples data after years of years of development.
While at the same time ZFS has been basically stable since early days, many developers at Sun switched their root drives to ZFS before it was even officially released. It never had years and years of routine instability.
> Few other file systems seem to face anywhere near as much criticism,
Where few file system claimed they were stable for years while routinely losing data. The file system has one job first and foremost, don't destroy users data.
This is not a conspiracy, this is simply the reality that tons of people have lost data because BTRFS repeatably claimed stability when it wasn't.
Its now another couple years later, likely this wouldn't happen again. But that after all these years they still haven't managed to get RAID 5/6 fully working doesn't exactly scream confidence. So me and I assume many others simply have lost confidence in the project and the approach they take to the development.
Earlier quoted context omitted.
No matter what happens, people will seemingly forever declare BTRFS is not as stable and not as safe. There's a status page that details what BTRFS thinks of itself[1], and I doubt any of the many people docking BTRFS have read or know or care what that page says. There is one issue still being worked out to completion, a "write hole" problem, involving two separate failures, an unplanned/power-loss shut-down, follow…
I've lost data in BTRFS setups each of the three times I've given it a try over the course of 6 or so years. Root drive just became unrecoverable. These are all single disk setups Meanwhile I've been running ZFS for close to the same time and have never lost anything. I get it's an anecdotal view point but that's a very hard reputation to rebuild for BTRFS.