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

121–130 of 168 posts

Re: ZFS on Linux: Unlistable and disappearing files

#121

Post by Mister_Snuggles »

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.

We use Suse with BTRFS at work. I don't know of any instance where we lost data, but the weekly filesystem rebalance that runs during business hours and causes the machine to not respond to anything except pings is a little frustrating.

Re: ZFS on Linux: Unlistable and disappearing files

#122

Post by zzzcpan »

boomboomsubban wrote: post #39
ams6110 wrote: post #36

Earlier quoted context omitted.

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

They're part of the same process, you need the checksums to know your backup is reliable and to tell you when your main files become corrupt. Backups alone aren't enough either.

No, it doesn't work like that, backup is not redundancy. To detect a bad block you first need to read it, you can't just know when a file becomes corrupt. And reading every block is very expensive and doesn't provide predictable guarantees. Instead proper backup has built in redundancy to account for lost blocks and so does proper data storage. Checksums are not visible to users in neither case.

And backup has to be incremental to prevent disasters.

Re: ZFS on Linux: Unlistable and disappearing files

#123

Post by cat199 »

aidenn0 wrote: post #13
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.

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.

not parent, but -

ext3 is improved ext2 which is improved minix fs which is improved fat, and all use the 'traditional' static-map-of-blocks approach, with gradual incremental improvements on top of this.. so the general technology 'family' is decades old even if any one implementation is not..

zfs/btrfs are log-structured, which wasn't really feasible from a hardware/performance standpoint until much later (see also LFS), and so represent implementations from a later 'generation' of technologies

Re: ZFS on Linux: Unlistable and disappearing files

#124

Post by ryao »

herogreen wrote: post #4

Wow that's an old Kernel! https://linux.slashdot.org/story/16/01/31/0424221/linux-kern...

We used to support Linux 2.6.16, but support for that was dropped a long time ago. Then we had support for 2.6.26, but support was dropped for that too. 2.6.32 support will be maintained until at least 2020 if I recall correctly. I could see us maintaining it well past that too.

Re: ZFS on Linux: Unlistable and disappearing files

#125

Post by StaticRedux »

Annatar wrote: post #108
spindle wrote: post #78

Probably obvious, but hooray for open source software! What a fantastic response to the bug.

Since when is introducing a major regression into something as critical as a filing system a hooray for open source? Only on GNU/Linux... and nobody thinks twice about it or bats an eyelash; instead, the scrambling to contain the regression is greeted with a hooray. It’s mentality like this which makes me want to never touch a computer again.

Introducing major bugs happens in software all the time. Finding it, working out a solution, and fixing it quickly is a hooray for open source.

Re: ZFS on Linux: Unlistable and disappearing files

#126

Post by nurettin »

1024core wrote: post #57
walrus01 wrote: post #55

Earlier quoted context omitted.

also a good time to remind people that backups are not backups unless they're geographically diverse. back up to an off site location in case your (home|office) burns down or suffers some other total catastrophe.

> 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 they are not backups unless DD is somehow involved.

Re: ZFS on Linux: Unlistable and disappearing files

#127

Post by ryao »

cat199 wrote: post #123
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.

not parent, but - ext3 is improved ext2 which is improved minix fs which is improved fat, and all use the 'traditional' static-map-of-blocks approach, with gradual incremental improvements on top of this.. so the general technology 'family' is decades old even if any one implementation is not.. zfs/btrfs are log-structured, which wasn't really feasible from a hardware/performance standpoint until much later (see also…

ZFS and btrfs are not log structured, but CoW. There are some aspects of ZFS like ZIL and L2ARC that are essentially log structured, but the filesystem itself is not a log structured filesystem.

Using CoW in storage is an idea that occurred after in-place and log structured filesystems had been made as far as I know though.

Re: ZFS on Linux: Unlistable and disappearing files

#128

Post by aidenn0 »

cat199 wrote: post #123
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.

not parent, but - ext3 is improved ext2 which is improved minix fs which is improved fat, and all use the 'traditional' static-map-of-blocks approach, with gradual incremental improvements on top of this.. so the general technology 'family' is decades old even if any one implementation is not.. zfs/btrfs are log-structured, which wasn't really feasible from a hardware/performance standpoint until much later (see also…

I'll give you ext3, certainly as ext2 and ext3 share a codebase. They are wholly unrelated to FAT though, ext and minix both derive from the UFS/FFS branch of file system development which has little, if nothing in common with FAT filesystems.

[edit] The original 8-bit FAT and FFS were both implemented at about the same time, if you consider FFS's beginning to be when I-nodes were moved into cylinder groups. If you consider the Unix "FS" to be the beginning, then it predates FAT by a lot. In any event inode and cluster-chain systems have fairly significant differences.

Also, long-structured/CoW systems have been used as backends for databases for about 40 years now.

Re: ZFS on Linux: Unlistable and disappearing files

#129

Post by tetha »

spindle wrote: post #78

Probably obvious, but hooray for open source software! What a fantastic response to the bug.

Yep, this is one of the big reasons why I love the open source linux world. Something breaks -- and in this case, the initial situation looks quite terrifying. And then a whole bunch of people pile in with information, reproduction, systems they can use for testing, ways to handle this in production, ...

Re: ZFS on Linux: Unlistable and disappearing files

#130

Post by Skunkleton »

Arbalest wrote: post #72
Skunkleton wrote: post #63

Earlier quoted context omitted.

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.

In my experience BTRFS has issues when the disk is allowed to go into low power mode.
Post reply on HN