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

61–70 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#61

Post by Arbalest »

xoa wrote: post #25
zorkw4rg wrote: post #8

basically the reason I like my filesystems a few decades old and mature, I would not trust zfs or btrfs with anything critical.

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. Disc replication (soft raid 1)

Out of scope:

* Snapshotting

* Subvolumes

* Deduplication

As much as I love subvolumes and snapshotting, I feel like CoW probably adds too much complexity to make it (easily) reliable. Honestly I don't know why turning off CoW on BTRFS disables checksumming, so if anyone can shed some light as to why this is, feel free to point out that my requirements are far more complex than I think.

Re: ZFS on Linux: Unlistable and disappearing files

#62

Post by _emacsomancer_ »

ams6110 wrote: post #36
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…

It sounds like you are suggesting that checksums and other integrity features obviate the need to back up your important files.

Of course not. But using fss lacking these features the backups end up 'faithfully' (and uselessly) propogating bitrotted files.

Re: ZFS on Linux: Unlistable and disappearing files

#63

Post by Skunkleton »

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 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.

Re: ZFS on Linux: Unlistable and disappearing files

#64

Post by foepys »

snvzz wrote: post #34
aidenn0 wrote: post #13

Earlier quoted context omitted.

Are you still using ext2 then? Ext3 was 2001, and ZFS was 2005. JFS2 is only 19 years old so doesn't quite meet the "decades" requirement.

He's likely referring to XFS, which meets the requirement.

Considering that XFS is currently getting new features en masse, this doesn't sound logical. Except when they mean they are using a still maintained kernel before Linux 4.x.

Re: ZFS on Linux: Unlistable and disappearing files

#65

Post by ryao »

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.

The author is a fairly new contributor:

https://github.com/zfsonlinux/zfs/commits?author=sanjeevbage...

What do you suggest that we should have done?

Re: ZFS on Linux: Unlistable and disappearing files

#66

Post by gigatexal »

ryao wrote: post #44
antongribok wrote: post #42

Earlier quoted context omitted.

This is a good reminder for everyone that snapshots are not backups. Also, thank you for all of the hard work on ZoL!

You are welcome. I should clarify the snapshots remark. The problem with how this interacts with snapshots is that the snapshots containing orphaned files cannot be repaired by software without BPR. They can only be listed by software for deletion by the administrator. Also, for the dataset’s tip, the future tool to repair it can only put the orphaned files into a lost+found directory without the original file names.

Seriously you and the other maintainers are my heroes. Keep it up! And thanks for the awesome write up.

Re: ZFS on Linux: Unlistable and disappearing files

#67

Post by ryao »

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.

It took me less than 3 days for btrfs to fail me, but that was in the 2.6.33_rc4 days. Had it gone better, I might have become a btrfs developer rather than a ZFS developer. In hindsight, I am happy with how things turned out.

Re: ZFS on Linux: Unlistable and disappearing files

#68

Post by ryao »

clircle wrote: post #26
beedogs wrote: post #21

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

Is there a stable (loaded word, I know) versioning file system available for Linux?

Do you mean snapshotting filesystems? If you really meant snapshotting, that would be ZFS. If you really meant a versioning filesystem, Wikipedia claims NILFS is stable:

https://en.m.wikipedia.org/wiki/Versioning_file_system#Linux

Re: ZFS on Linux: Unlistable and disappearing files

#69

Post by static_noise »

simcop2387 wrote: post #53
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.

I believe the most recent issues I've seen documented with it are around the built in RAID5/6 implementation not being fully stable. I haven't used any of it myself so I can't comment on the rest of it. (I did use it on an external drive like 5-6 years ago and had issues that I know have been fixed, but haven't retried it).

They should have kept RAID behind yellow tape for years to come. There's just too many problems that can bite you once a physical disk fails and you really need that RAID to recover.

Re: ZFS on Linux: Unlistable and disappearing files

#70

Post by jclulow »

ryao wrote: post #65
jclulow wrote: post #56

Earlier quoted context omitted.

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.

The author is a fairly new contributor: https://github.com/zfsonlinux/zfs/commits?author=sanjeevbage... What do you suggest that we should have done?

I'm not sure, but I'm not deeply familiar with this part of the code. In general, I think it's good to be able to induce all of the failure cases for all of the error handling code that's being added.

This can be time-consuming work, but I would argue that this is the file system -- anything less is an unacceptable risk. This quote from my boss comes to mind:

Remember: you are (or should be!) always empowered as an engineer to take more time to test your work. -- http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-f...

Post reply on HN