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

Five Years of Btrfs

markmcb.com

Post reply on HN
Print view View original

201–210 of 240 posts

Re: Five Years of Btrfs

#201

Post by cmurf »

Fnoord wrote: post #45
jbotz wrote: post #20

Earlier quoted context omitted.

As best I can tell, reports of data loss on btrfs are all from the early 20-teens; after about 2014 or so I can't find anyone who claims to have lost data due to a btrfs bug on an up-to-date system.

RAID5 on btrfs has a write hole last time I checked. Bug has been around forever, and was around in 2014 for sure. Phoronix has some thorough performance comparisons between Ext4fs, Btrfs, XFS, and ZFS.

The write-hole problem is a rare case, wherever it happens. https://lwn.net/Articles/665299/

On Btrfs, in case of bad parity being used to reconstruct a stripe, the resulting bad reconstruction is still subject to data checksumming, and will EIO. Corrupt data won't be sent to user space.

Re: Five Years of Btrfs

#202

Post by fulafel »

tjoff wrote: post #111
clSTophEjUdRanu wrote: post #73

Earlier quoted context omitted.

I really don't understand the insane hype around ZFS. You can't read any thread that touches on filesystems without the ZFS zealots coming out.

The hype is quite easy to understand. Snapshots and checksums are two complete game-changers. ZFS has them both. And there are no real alternatives in many cases. I've personally waited for BTRFS longer than a decade but my use-cases are yet to be considered stable (not something you really mess with in regard to filesystems). Honestly, as sure as I have been on the success of BTRFS I now consider BTRFS dead on arriv…

lvm and hence ext4 etc have had snapshots for ages.

Re: Five Years of Btrfs

#203

Post by packetlost »

cmurf wrote: post #194
packetlost wrote: post #160

Earlier quoted context omitted.

In my experience, btrfs is very fragile in power loss or kernel crash/panic scenarios. It very consistently causes soft lockups on file read/writes after power loss until you run a `brtfs check --repair` on it. My experience is mostly on Arch, so it's not a case where it's out of date and missing patches.

Sounds like hardware problems in the storage stack. Btrfs developers contributed the dm-log-writes target to the kernel, expressly for conducting power loss tests on file systems. All the file systems benefit from this work. https://www.kernel.org/doc/Documentation/device-mapper/log-w... And Btrfs is doing the right thing these days. I recently conducted system resource starvation tests where a compile process spun o…

100% was not a hardware problem. Works fine on other filesystems ️

Re: Five Years of Btrfs

#204

Post by TurningCanadian »

tjoff wrote: post #111
clSTophEjUdRanu wrote: post #73

Earlier quoted context omitted.

I really don't understand the insane hype around ZFS. You can't read any thread that touches on filesystems without the ZFS zealots coming out.

The hype is quite easy to understand. Snapshots and checksums are two complete game-changers. ZFS has them both. And there are no real alternatives in many cases. I've personally waited for BTRFS longer than a decade but my use-cases are yet to be considered stable (not something you really mess with in regard to filesystems). Honestly, as sure as I have been on the success of BTRFS I now consider BTRFS dead on arriv…

There were a bunch of btrfs raid56 patches last year. I think the known bugs have been addressed and is just that the wiki page hasn't been updated.

Re obsolete, are you referring to RAID1C3?

Re: Five Years of Btrfs

#205

Post by shanemhansen »

packetlost wrote: post #160
RX14 wrote: post #116

Earlier quoted context omitted.

It seems a lot of people have these stories, and then people like me and OP who have had btrfs survive the most fucked up situations (I've had a btrfs nas built on "random drives I've had lying around" and abused it for 5 years and had 0 bugs at all). I'm not sure what causes it, but there seems to be an effect where btrfs loves you or hates you and few people with mixed experiences regarding data loss. One possible…

In my experience, btrfs is very fragile in power loss or kernel crash/panic scenarios. It very consistently causes soft lockups on file read/writes after power loss until you run a `brtfs check --repair` on it. My experience is mostly on Arch, so it's not a case where it's out of date and missing patches.

I ran btrfs on a laptop. 2 things.

Once I ended up with a bunch of zero length files (presumably metadata was written before content?).

I also, multiple times ended up with errors related to full drives despite by drive not being full. Deleting snapshots seemed to help.

Then I went to a zfs fs on root and never had another problem.

Re: Five Years of Btrfs

#206

Post by aidenn0 »

starfallg wrote: post #109
InTheArena wrote: post #31

I went on a quest a few years ago, thinking it would be good for the industry to standardize on a single next generation filesystem for UNIX. I started with ZFS on linux since that seemed to have the most vocal advocates. That lasted about a half year, until a bug in the code resulted in a completely corrupt disk, and I had to restore 4TB of data over a month from offside backups. That plus the licensing confusion ar…

Btrfs is the only FS I used that resulted in complete FS corruption losing nearly all data on disk, not once, but 3 times. After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.

ZFS is the only FS I used that resulted in complete FS corruption, losing nearly all data on disk (only once though).

Re: Five Years of Btrfs

#207

Post by mycall »

tjoff wrote: post #111
clSTophEjUdRanu wrote: post #73

Earlier quoted context omitted.

I really don't understand the insane hype around ZFS. You can't read any thread that touches on filesystems without the ZFS zealots coming out.

The hype is quite easy to understand. Snapshots and checksums are two complete game-changers. ZFS has them both. And there are no real alternatives in many cases. I've personally waited for BTRFS longer than a decade but my use-cases are yet to be considered stable (not something you really mess with in regard to filesystems). Honestly, as sure as I have been on the success of BTRFS I now consider BTRFS dead on arriv…

What warts do you speak of?

Re: Five Years of Btrfs

#208

Post by aidenn0 »

trasz wrote: post #57
loudmax wrote: post #38

Earlier quoted context omitted.

> I think its much more NIMBY then a license issue How do you propose that ZFS be brought into Linux? When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel. This was no accident. At the time, Sun was still pushing OpenSolaris which was losing ground to Linux. The ZFS on Linux project gets around this restriction by running…

On the other hand, choosing to use GPL would prevent it from being integrated anywhere else. You'd also lose the patent protection granted by CDDL.

Any license more liberal than the GPL would also be fine. For example: MIT/X11, 2-clause BSD, or Ruby's license.

Re: Five Years of Btrfs

#209

Post by aidenn0 »

cat199 wrote: post #132
nickik wrote: post #65

Earlier quoted context omitted.

> When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel This is simply totally false no matter how many times people repeat it. It pure FUD. Sun picked the licence because they had to allow linking with closed code for their products, going with the GPL was simply not viable given the situation with drivers on their platfor…

> Sun picked the licence because they had to allow linking with closed code for their products Wasn't Sun always the copyright holder? Licenses only apply to Licensees, not Licensors - or am I missing something (e.g. collaborators not needing to reassign copyright back to sun, etc)..

IIRC, Sun was not the copyright holder of everything in Solaris.

Re: Five Years of Btrfs

#210

Post by aidenn0 »

loudmax wrote: post #90
nickik wrote: post #65

Earlier quoted context omitted.

> When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel This is simply totally false no matter how many times people repeat it. It pure FUD. Sun picked the licence because they had to allow linking with closed code for their products, going with the GPL was simply not viable given the situation with drivers on their platfor…

Sun's motivation for choosing the CDDL is beside the point. Unless ZFS is released under a license that allows it to be redistributed under the GPL, ZFS cannot be legally built into Linux as a filesystem. If you have reason to believe that Linux developers can go ahead and simply integrate ZFS into Linux without worrying about the license, I'm sure lawyers from the FSF, IBM, Cannonical, etc would love to hear your ex…

> Sun's motivation for choosing the CDDL is beside the point.

GP made a claim to Sun's motivation, rebutting that claim seams reasonable.

Post reply on HN