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

131–140 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#131

Post by pnutjam »

krylon wrote: post #115
Mister_Snuggles wrote: post #100

Earlier quoted context omitted.

I use OpenSuse Tumbleweed with BTRFS on a laptop. This is nothing special - a 512GB SSD, no RAID, about 350GB of data and a bunch of snapshots. It was basically the out of the box configuration plus some snapper config to regularly snapshot /home. One day I shut it down and it wouldn’t boot - the BTRFS filesystem had gotten itself into a state where it would mount ok read-only but hang the system when mounting read/w…

Huh. I had that same problem on two machines running Tumbleweed a couple of months ago. In both cases, the only working approach I found was to wipe the root partition and install from scratch. /home was in a separate partition, so it was not a tragedy, but annoying nevertheless. This has never happened to me before, unless the underlying hardware was about to retire.

Tumbleweed is a rolling edge release. I get wonky desktops and other problems all the time when I update.

Re: ZFS on Linux: Unlistable and disappearing files

#132

Post by xxpor »

Conan_Kudo wrote: post #16
xxpor wrote: post #12

Earlier quoted context omitted.

The OP appears to speak German natively. In German they are much more hyphen happy than English. It's probably the most common error I see among German speakers typing English.

This. German merges words together as their modifier mechanism, whereas English just uses word order to indicate modification. Since it's technically _not_ illegal in English to hyphenate to do the same thing, German speakers tend to do this for English. It's a very hard habit for them to break. :)

One could argue that technically nothing's illegal in English, since there's no governing body, just what's in common use.

Kind of like civil vs common law too, now that I think about it :)

Re: ZFS on Linux: Unlistable and disappearing files

#134

Post by dcuthbertson »

rkagerer wrote: post #84
1024core wrote: post #57

Earlier quoted context omitted.

> also a good time to remind people that backups are not backups unless they're geographically diverse. ... and backups are not backups until you can reliably restore from them.

...and a DR plan isn't worth the paper it's written on unless you test it regularly (people leave, media gets corrupted... just like the military; do drills!)

Paper? You write on paper? My DR plan is in a file and backed up locally, and ... um ... oh oh.

Re: ZFS on Linux: Unlistable and disappearing files

#135

Post by iforgotpassword »

Annatar wrote: post #105
ryao wrote: post #44

Earlier quoted context omitted.

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.

lost+found is an incorrect approach for ZFS. If you feel you have to regress to what was 40 years ago and was a bad solution, then the misfeature causing it needs to be engineered instead of hacked together, or better yet not implemented at all. If you have to break from mainstream ZFS and regress that violently, it’s the wrong approach.

So what exactly is your suggestion? "lost+found is ugly so don't recover the files at all"? He said meta data is lost so I'm really curious to hear your elegant modern solution.

This is a tool that might be needed on a few systems that suffered from this relatively short loved bug and then never again after that, so your solution better not require ten times the effort.

Re: ZFS on Linux: Unlistable and disappearing files

#136

Post by ryao »

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…

In-place writes invalidate checksums. It is theoretically possible for an in-place filesystem to have data checksums, but maintaining them would require reading the entire block to regenerate the checksum on every write (I consider reads from cache to be reads). That largely defeats the purpose of doing operations in-place, which is to avoid that overhead. Maybe it would make more sense on btrfs (because it’s metadata structures can become horribly unbalanced) than it usually would on a convention in-place filesystem. However, the code would need to do gymnastics to achieve that without risking subtle reliability issues. That is something that I would not expect many filesystem developers to want to maintain. The btrfs codebase is complex enough (more so than ZFS despite having fewer features) without adding that.

By the way, partial writes from power failures are impossible to correct on in place filesystem designs without writing everything twice. CoW has performance penalties, but not so much as in-place designs when it comes to ensuring integrity. The complexity of doing CoW is also not that bad. It is how virtual memory works in every modern computer system, minus some rare embedded systems and ancient/unikernel designs that lack it. Doing CoW in storage is not a particularly strange thing.

Re: ZFS on Linux: Unlistable and disappearing files

#137

Post by lutorm »

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 feel similarly. I've had basically all my data on ZFS/ZoL for 8 years at this point and have not had any problems except occasional system lockups when scrubbing. This has not happened for the last year or so.

For a while it seemed like ZoL was working hard to catch up with the "official" ZFS feature set, but at this point I hope they take it slowly and carefully and really beat on new upgrades.

The more stable you are, the more important it becomes for a FS to not screw it up, since the consequences get larger with a larger user base...

Re: ZFS on Linux: Unlistable and disappearing files

#138

Post by Annatar »

barrkel wrote: post #113
Annatar wrote: post #103

Earlier quoted context omitted.

“This is a good reminder for everyone that snapshots are not backups.” Were this not ZFS, I would agree with you, however, since zfs rollback will revert to previous state and if the snapshot is on a redundant vdev, there is no difference between that and losing your backup due to a damaged tape. In fact, zfs snapshots are exactly how time machine on illumos based operating systems is implemented.

Backups have three characteristics: redundancy, versioning and distribution. ZFS only fulfils two. If ZFS is your backup target, then you're making more sense.

ZFS has distribution via zfs send subcommand.

Re: ZFS on Linux: Unlistable and disappearing files

#139

Post by Annatar »

barrkel wrote: post #112
Annatar wrote: post #105

Earlier quoted context omitted.

lost+found is an incorrect approach for ZFS. If you feel you have to regress to what was 40 years ago and was a bad solution, then the misfeature causing it needs to be engineered instead of hacked together, or better yet not implemented at all. If you have to break from mainstream ZFS and regress that violently, it’s the wrong approach.

Where do you suggest recovered file data (when metadata has been lost) should be put in the event of repair after a file system driver bug?

I suggest completely backing out the code in question and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. metadata are not files so they have no business going into lost+found.

Re: ZFS on Linux: Unlistable and disappearing files

#140

Post by Annatar »

iforgotpassword wrote: post #135
Annatar wrote: post #105

Earlier quoted context omitted.

lost+found is an incorrect approach for ZFS. If you feel you have to regress to what was 40 years ago and was a bad solution, then the misfeature causing it needs to be engineered instead of hacked together, or better yet not implemented at all. If you have to break from mainstream ZFS and regress that violently, it’s the wrong approach.

So what exactly is your suggestion? "lost+found is ugly so don't recover the files at all"? He said meta data is lost so I'm really curious to hear your elegant modern solution. This is a tool that might be needed on a few systems that suffered from this relatively short loved bug and then never again after that, so your solution better not require ten times the effort.

If it's a one time throwaway tool, then it doesn't need lost+found!
Post reply on HN