Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS on Linux: Unlistable and disappearing files

github.com

Post reply on HN
Print view View original

71–80 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#71

Post by Arbalest »

beedogs wrote: post #59
Arbalest wrote: post #33

Earlier quoted context omitted.

A disaster for enterprise perhaps. I use only a subset of features (such as subvolumes and snapshots and a little RAID 1) and have never had problems. With the way some people talk about it, it sure sounds like it never worked at all.

You've never had problems? You're lucky. I guarantee you will. It took me less than a month to lose significant data with it, under normal usage patterns.

I've been using it for a good 5 years. OK, I had one time. When I removed a disk from a mirror, forced the remaining disk to operate writable as a single, then attempted to migrate it to single disk duplication, then shut it down before it finished migrating.

That's not a sane way to handle data really, I was playing around with unimportant stuff. If it was real data, I would have mounted it read only, and copied it away.

Re: ZFS on Linux: Unlistable and disappearing files

#72

Post by Arbalest »

Skunkleton wrote: post #63
beedogs wrote: post #59

Earlier quoted context omitted.

You've never had problems? You're lucky. I guarantee you will. It took me less than a month to lose significant data with it, under normal usage patterns.

I have not had good luck with BTRFS on systems running on battery. Its been solid on my workstation for a while though. Still, it is disappointing that it hasn't stabilized faster.

I run BTRFS on my laptop. Is yours an ultraportable? Mine is a fairly chunky system with a 100Wh battery, about 3 years old.

Re: ZFS on Linux: Unlistable and disappearing files

#73

Post by paulie_a »

Arbalest wrote: post #33
beedogs wrote: post #21

At least it's no btrfs. What a disaster that filesystem's been.

A disaster for enterprise perhaps. I use only a subset of features (such as subvolumes and snapshots and a little RAID 1) and have never had problems. With the way some people talk about it, it sure sounds like it never worked at all.

I would never trust btrfs for anything. You might as well just use /dev/null for storage

Re: ZFS on Linux: Unlistable and disappearing files

#74

Post by oarsinsync »

jclulow wrote: post #56
ryao wrote: post #54

Earlier quoted context omitted.

The bad patch passed review by developer(s) from other platforms. Matthew Ahrens was a reviewer. This was not merged based on unilateral review by the ZFSOnLinux developers. There was also nothing Linux specific about it. That said, bugs happen. We should be putting new test cases in place to help catch such regressions in the future. If we find more ways to harden the code add against regressions of this nature as w…

Reviewers will help catch bugs, but the engineer who writes the code and seeks to integrate it is ultimately responsible for sufficient testing to avoid issues like this one.

When multiple people have reviewed and approved, all of those people are jointly and equally responsible for any fallout. A reviewer needs to take their responsibility as seriously as the coder. If they don’t, it diminishes the value of having the code review.

The coder, the reviewers, the approvers, they’re all in this together. It’s unfortunate that this happened, but no single person should be held accountable when there’s a process in place designed to protect against individual mistakes.

It’s a shame that this skipped through still anyway, but that’s part of the nature of the resource limitation, especially with F/LOSS. There’s always a risk of this happening. The only way to reduce the risk is to contribute more resources. Blaming the coder is more likely to result in a reduction of resources, as less code gets done.

Re: ZFS on Linux: Unlistable and disappearing files

#75

Post by simcop2387 »

simcop2387 wrote: post #51
dmm wrote: post #19

Earlier quoted context omitted.

Debian Stable(jessie) is on 0.6.5.9 and Debian unstable(sid) is on 0.7.6 so they shouldn't be affected.

Debian stable is stretch, released in june 2017. It's on 0.7.5 currently.

correction, I hadn't updated my server in a while, stretch itself is on 0.6.5.9 also, but stretch-backports is on 0.7.6 (not sure when that happened exactly)

Re: ZFS on Linux: Unlistable and disappearing files

#76

Post by baq »

jclulow wrote: post #56
ryao wrote: post #54

Earlier quoted context omitted.

The bad patch passed review by developer(s) from other platforms. Matthew Ahrens was a reviewer. This was not merged based on unilateral review by the ZFSOnLinux developers. There was also nothing Linux specific about it. That said, bugs happen. We should be putting new test cases in place to help catch such regressions in the future. If we find more ways to harden the code add against regressions of this nature as w…

Reviewers will help catch bugs, but the engineer who writes the code and seeks to integrate it is ultimately responsible for sufficient testing to avoid issues like this one.

au contraire, engineers should not be testing their changes. tunnel vision is a real thing - you need to be seriously experienced to be able to sidestep that.

Re: ZFS on Linux: Unlistable and disappearing files

#77

Post by isnull »

beedogs wrote: post #21

At least it's no btrfs. What a disaster that filesystem's been.

i have been using btrfs in production for years now and it has never failed me, and i am doing hundreds of snapshots and send/receiving, i've reconfigured raids on the fly and went from 6 disk raid 10 of mixed size to raid 10 of same size. we have in some cases had many power failures with no data loss. We also have some set up using md raid and some using hardware raid...

when i hear people dogging btrfs it just speaks to their inexperience imo.

that said i know it's not perfect, but what is?

Re: ZFS on Linux: Unlistable and disappearing files

#79

Post by blattimwind »

Arbalest wrote: post #61
xoa wrote: post #25

Earlier quoted context omitted.

I have been running ZFS on macOS (OS X), illumos and Solaris for a good 7 years or so now. A major part of the reason I switched over fully, despite some warts, was that I experienced actual and significant data rot from stuff I was carrying forward under XFS (IRIX), HFS, etc. I don't consider my personal stuff to go back that long, but I still have things from 1993 or so that matter to me. I did a review around 2009…

I am still somewhat suprised there are still not relatively simple filesystems that don't do this. Make it the one feature it does and does properly. Adding enterprise features will just increase development time (and cost) and add bugs. Basically an online archival filesystem, that's how most people use their home computers. Requirements: 1. Checksumming on all files 2. Minimise assumptions of ram correctness 3. Dis…

> I don't know why turning off CoW on BTRFS disables checksumming

Because in-place updates means you need to journal data writes, otherwise you'll get checksum errors for aborted writes. (Which classic file systems don't catch)

The recent (~5 years old) batch of block-deduplicating backup tools (attic, bup, borg, restic etc.) would fit the bill to some extent, but all of them were/are more bug-laden than the file systems discussed so far.

Re: ZFS on Linux: Unlistable and disappearing files

#80

Post by jwilk »

exikyut wrote: post #17
ryao wrote: post #9

We are working on it. We know what patch introduced the regression and 0.7.8 is going out soon to revert it. Until then, users should downgrade to 0.7.6 if they have not already. The Gentoo and EPEL maintainers have pulled the affected releases from the repositories (technically masked on Gentoo). Ubuntu was never affected. The regression makes it so that creating a new file could fail with ENOSPC after which files c…

> We will likely have some way to recover the orphaned files (like ext4’s lost+found) and fix the directory sizes in the very near future. How should people behave right now? Will normal usage of production filesystems erase data, or will read/write activity leave the potentially-orphaned files in place? You've also mentioned snapshots being tricky in the thread. Should people stop creating snapshots in case orphaned…

> 8.23+ randomized the order (I don't quite understand why)

It's using inode order, which speeds up things significantly on some filesystems:

https://lists.gnu.org/archive/html/bug-gnulib/2014-02/msg000...

Post reply on HN